No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Aprende todo un fin de semana sin pagar una suscripci贸n 馃敟

Aprende todo un fin de semana sin pagar una suscripci贸n 馃敟

Reg铆strate

Comienza en:

0D
11H
36M
54S

Principios del testing moderno

6/29
Recursos
  • Nuestra prioridad es mejorar el negocio: El producto que se va a entregar al cliente permitir谩 hacer funcionar el negocio. Si en alg煤n momento no quieres hacerlo, est谩s poniendo en riesgo ese negocio porque si el producto no se vende o no es aceptado la empresa puede cerrar o puedes perder el trabajo.
  • Nosotros aceleramos el equipo y usamos modelos como Lean Thinking y Teor铆a de las Restricciones para ayudar a identificar, priorizar y mitigar cuellos de botella en el sistema: Cuando queremos hacer algo, lo queremos hacer perfecto y eso puede ser demasiado. Deber铆as construir en base a procesos cortos para poder encontrar los defectos de una manera m谩s r谩pida.
  • Nosotros somos la fuerza para la mejora continua, ayudando al equipo a adaptarse y optimizar para tener 茅xito, en lugar de proporcionar una red de seguridad para detectar fallas: El cliente puede entender que el producto se va a liberar por fases, es importante que nosotros enfoquemos nuestras pruebas en cada una de esas fases. No tiene que ser todo al inicio y al final, debe haber una distribuci贸n que nos permita manejar el riesgo del software
  • Nos preocupamos profundamente acerca de la cultura de calidad en nuestro equipo, y asesoramos, lideramos y nutrimos el equipo para llevarlos a una cultura de calidad m谩s madura: Al inicio los testers eran personas desarrollando software y un d铆a con tantos defectos y trabajo, separaron los roles para que as铆 hubiese una persona dedicada a realizar las pruebas. El tester puede hacer recomendaciones de herramientas, mejorar el proceso o volverse un coach.
  • Nosotros creemos que el cliente es el 煤nico capaz de juzgar y evaluar la calidad de nuestro producto: Si el cliente esta satisfecho con lo entregado y cumple las expectativas entonces has alcanzado la calidad deseada.
  • Nosotros usamos datos de manera extensa y profunda para entender los casos de uso del cliente y entonces cerrar huecos entre hip贸tesis del producto e impacto del negocio.
  • Expandimos las habilidades de testing y el conocimiento en todo el equipo; entendemos que esto reduce o elimina la necesidad de una especialista dedicado al testing.

El tester debe dominar varias areas necesita entender y tener toda la visi贸n del producto y negocio. Saber sobre herramientas que optimicen el trabajo.o

Aportes 110

Preguntas 5

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

Curso de Appium y Selenium porfa

Lean Thinking: es un sistema enfocado en la creaci贸n de valor para el cliente, a trav茅s de la persistente b煤squeda y eliminaci贸n de desperdicio, as铆 como tambi茅n la mejora continua, el respeto hacia las personas, el trabajo en equipo y abordar desaf铆os.

Theory of Constraints: en una organizaci贸n siempre habr谩n restricciones (maquinaria, procesos, pol铆ticas, personas鈥), en las cuales debemos enfocarnos y atacarlos de la sigueinte manera:

  1. Identificar el cuello de botella
  2. Explotarlo, llev谩ndolo a su m谩xima capacidad.
  3. Subordinar todo lo dem谩s con el fin de solucionar el cuello de botella.
  4. Elevar la capacidad con m谩s maquinaria, personas, etc.
  5. Iterar: siempre habr谩n m谩s restricciones. Se debe evitar la inercia.

Apuntes:

Principios del testing moderno

Los principios creados por Allan Page y Brenn Jensen es acerca del testing moderno, que es la evoluci贸n natural del testing 谩gil. Ve铆an la necesidad de que el tester y el desarrollador evolucionen en su perspectiva, ambos hacen software y entregan al mismo cliente, por lo tanto deben trabajar m谩s como un equipo y no como entidades separadas. El tester deber铆a enfocarse en la calidad del sowftware, el desarrollador deber铆a enfocarse a desarrollar la soluci贸n. El tester va a ayudar al desarrollador a utilizar las mejores herramientas, a entender los procesos de pruebas, a mejorar la calidad de su desarrollo.

Los 7 principios del testing moderno

鈥淟os testers podemos comenzar a pasar de ser los due帽os de las pruebas o la calidad, a ser los embajadores de la calidad del producto鈥.

  1. Nuesta prioridad es mejorar el negocio.
  2. Nosotros aceleramos al equipo, usamos modelos como Lean Thinking y Teor铆a de las Restricciones para ayudar a identificar, mitigar, priorizar y mitigar cuellos de botella en el sistema.
  3. Somos la fuerza para la mejora continua, ayudando al equipo a adaptarse y optimizar para tener 茅xito, en lugar de proporcionar una red de seguridad para detectar fallas.
  4. Nos preocupamos profundamente acerca de la cultura de calidad en el equipo, y asesoramos, lideramos y nutrimos al equipo para llevarlos a una cultura de calidad m谩s madura.
  5. Nosotros creemos que le cliente es el 煤nico capaz de juzgar y evaluar la calidad de nuestro producto.
  6. Nosotros usamos datos de manera extensa y profunda para entender los casos de usos del cliente y entonces cerrar huecos entre hip贸tesis del producto e impacto del negocio.
  7. Expandimos las habilidades de testing y el conocimiento en todo el equipo; entendemos que esto reduce o elimina la necesidad de un especialista dedicado al testing.

En donde estoy trabajando actualmente son muy abiertos a los cambios positivos, a las mejoras y a obtener mayor productividad, sin embargo hace falta quien tenga conocimientos y visi贸n amplia para tener en cuenta todo el espectro que conlleva el desarrollo de nuestros productos, por lo que, al capacitarme con este tipo de cursos espero ser yo quien involucre en un futuro no muy lejano las mejores estrategias de an谩lisis de calidad y productividad al desarrollo. 隆Me emociona aprender algo que s铆 voy a utilizar! 馃槂

鈥淓l cliente es el 煤nico capaz de juzgar y evaluar la calidad de nuestro producto鈥. Pero c贸mo encaja lo que dec铆a Steve Jobs sobre como 茅l creaba sus productos?. Seg煤n 茅l
"Algunas personas dicen: 鈥淥frezca a los clientes lo que quieren鈥. Pero ese no es mi enfoque. Nuestro trabajo es descubrir qu茅 van a querer antes de hacerlo. Creo que Henry Ford dijo una vez: 鈥淪i hubiera preguntado a los clientes qu茅 quer铆an, me habr铆an dicho: 鈥樎n caballo m谩s r谩pido!鈥欌. La gente no sabe lo que quiere hasta que se lo ense帽as. Es por eso que nunca conf铆o en la investigaci贸n de mercado. Nuestra tarea es leer cosas que a煤n no est谩n en la p谩gina."

Curso de Selenium por favor 鈥

Necesitariamos Cursos de pruebas de rendimiento usando JMeter como herramienta para mejorar la arquitectura de la aplicaci贸n.

  • la evoluci贸n del testing moderno es la evoluci贸n del testing 谩gil
    el tester y el desarrollador deben trabajar mas como un equipo
  • el tester debe enfocarse en la calidad el producto
  • el desarrollador enfocarse en desarrollar la aplicaci贸n
    los 7 principios del Testing moderno
  1. nuestra prioridad mejorar el negocio
  2. buscamos modelos Lean Thinking priorizar y mitigar cuellos de botella en el sistema (crear m贸dulos de forma 谩gil)
  3. para la mejora continua hay que adaptarse y optimizar
  4. Nos preocupamos profundamente acerca de la cultura de calidad (el tester tiene que hacer recomendaci贸n de herramientas), la calidad es prioridad numero 1
  5. Quien define la calidad es el usuario final (el cliente), el cliente es el 煤nico capaz de juzgar y evaluar
  6. la falta de de datos de prueba, Nosotros usamos datos de manera extensa y profunda
  7. Expandir las habilidades del testing a todo los compa帽eros, debemos entender y conocer toda la necesidad del producto

El tester debe enfocarse en la calidad
el desarrollador debe enfocarse en el desarrollo
pero deben de trabajar en conjunto para obtener un buen producto

7 Principios del testing moderno:

  1. Nuestra prioridad es mejorar el negocio
  2. Nosotros aceleramos al equipo, usamos modelos como Lean Thinking y Teor铆as de las Restricciones para ayudar a identificar, priorizar y mitigar cuellos de botella en el sistema.
  3. Somos la fuerza para la mejora continua, ayudando al equipo a adaptarse y optimizar para tener 茅xito, en lugar de proporcionar una red de seguridad para detectar fallas.
  4. Nos preocupamos profundamente acerca de la cultura de calidad en el equipo, y asesoramos, lideramos y nutrimos el equipo para llevarlos a una cultura de calidad m谩s madura.
  5. Nosotros creemos que el cliente es el 煤nico capaz de juzgar y evaluar la calidad de nuestro producto.
  6. Nosotros usamos datos de manera extensa y profunda para entender los casos de uso del cliente y entonces cerrar huecos entre hip贸tesis del producto e impacto del negocio.
  7. Expandir las habilidades de testing y el conocimiento en todo el equipo; entendemos que esto reduce o elimina la necesidad de un especialista dedicado al testing.

Todo el equipo son responsables de la calidad del producto.

Si se siente mucho la separaci贸n entre desarrolladores y tester. Los defectos rara vez son bien recibidos y noto que siempre se busca un culpable鈥 lo cu谩l reduce el tiempo de soluci贸n de dichos defectos.

La teor铆a de las restricciones es una metodolog铆a que busca la mejora continua. identificando las restricciones o limitaciones encontradas en un sistema que lo hacen lento.

El m茅todo primero busca identificar las restricciones que son denominadas cuellos de botella. Luego se debe actuar sobre ellas para lograr la mejora. De manera que se pueda aumentar la capacidad del sistema o lograr que no se produzcan fallas.

La teor铆a de la restricci贸n hace uso de diferentes herramientas para lograr un proceso de mejora continua. Utilizando la relaci贸n l贸gica de causa y efecto para entender como operan los procesos y encontrar la forma de mejorarlos.

  1. Nuestra prioridad es mejorar el negocio
    El producto que se va a entregar al cliente es lo que permite funcionar al negocio. Si en alg煤n momento no quieres hacerlo, est谩s poniendo en riesgo ese negocio porque si el producto no se vende o no es aceptado la empresa puede cerrar o puedes perder el trabajo.
    2. Nosotros aceleramos el equipo y usamos modelos como Lean Thinking y Teor铆a de las Restricciones para ayudar a identificar, priorizar y mitigar cuellos de botella en el sistema.
    Cuando queremos hacer algo, lo queremos hacer perfecto y eso puede ser demasiado. Deber铆as construir en base a procesos cortos para poder encontrar los defectos de una manera m谩s r谩pida.
    3. Nosotros somos la fuerza para la mejora continua, ayudando al equipo a adaptarse y optimizar para tener 茅xito, en lugar de proporcionar una red de seguridad para detectar fallas.
    El cliente puede entender que el producto se va a liberar por fases, es importante que nosotros enfoquemos nuestras pruebas en cada una de esas fases. No tiene que ser todo al inicio y al final, debe haber una distribuci贸n que nos permita manejar el riesgo del software
    4. Nos preocupamos profundamente acerca de la cultura de calidad en nuestro equipo, y asesoramos, lideramos y nutrimos el equipo para llevarlos a una cultura de calidad m谩s madura.
    Al inicio los testers eran personas desarrollando software y un d铆a con tantos defectos y trabajo, separaron los roles y as铆 hubiese una persona dedicada a realizar las pruebas. El tester puede hacer recomendaciones de herramientas, mejorar el proceso o volverse un coach.
    5. Nosotros creemos que el cliente es el 煤nico capaz de juzgar y evaluar la calidad de nuestro producto
    Si el cliente esta satisfecho con lo entregado y cumple las expectativas entonces has alcanzado la calidad deseada.
    6. Nosotros usamos datos de manera extensa y profunda para entender los casos de uso del cliente y entonces cerrar huecos entre hip贸tesis del producto e impacto del negocio.
    7. Expandimos las habilidades de testing y el conocimiento en todo el equipo; entendemos que esto reduce o elimina la necesidad de una especialista dedicado al testing.

Hi! I was a manual tester many years ago, this area has been improved so much. There are seven specialties: Manual Tester, Automation Tester, Security Tester, Data Science Tester, SDET (Software Development Engineer in Test), DevOps (Development and operations), QA Engineer, QE.
Actually, I want to learn more about it and get back soon to work.

Pronto entrare a una empresa como QA tester, este curso me esta ayudando a empaparme del tema antes de entrar a laborar.

Es interesante y de gran responsabilidad comprender que el tester debe estar en todas las 谩reas del negocio, pens茅 que estaba limitado a las pruebas y algo de documentaci贸n.

Es bueno recalcar que el camino del tester es fundamental para las empresas, aunque hay muchas que no dependen de un tester por que consume recursos y que las pruebas las lleven a cabo el desarrollador, a simple vista del desarrollador no puede encontrar errores f谩cilmente para esto se necesita un especialista en calidad de software y es necesario llevar a cabo herramientas para realizar las pruebas mas efectivas como selenium java, que me gustar铆a que se dictara en esta plataforma platzi.

a lo que le hace falta aplicar muchas normas de calidad, es a sitios donde atascan de publicidad, banners, etc, por 茅tica, no deber铆an de subir esas p谩ginas y quiz谩 no deber铆an estar permitidas en la red comercial p煤blica, o bajo propio riesgo del usuario, pero nisiquiera el proveedor del servidor deber铆a de permitir que ah铆 se hospeden.

Theodore Levitt llamaba a esta nueva forma de ver el desarrollo, la perspectiva 4C, en su articulo sobre "la miopia del marketing mix" describe el error que en ese entonces los directivos comet铆an, enfocarse s贸lo en un Producto, para ver en qu茅 Plaza venderlo, y a qu茅 Precio sacando una Promoci贸n, era algo que llevaba a muchas organizaciones a caer tarde o temprano.

Que es el modelo de Lean Thinking ?

la evoluci贸n del testing moderno es la evoluci贸n del testing 谩gil
el tester y el desarrollador deben trabajar mas como un equipo
el tester debe enfocarse en la calidad el producto
el desarrollador enfocarse en desarrollar la aplicaci贸n

Muchos de estos principios casi todos, lo realizan donde trabajo actualmente, pero ahora entiendo mucho m谩s el valor de cada uno y que podria llegar aportar a la empresa cliente y hasta yo como desarrollador.

testing modernos aun no hacemos ni el testing agil o normal.

  1. Tests show the presence of defects
    It means that the tests can show that problems EXIST, but not that problems DO NOT EXIST.
    The main purpose of conducting a test is to detect defects. Working on the premise that every product contains defects of some kind, a test that reveals the errors is generally better than one that does not. All tests must therefore be designed to reveal as many errors as possible.
  2. Thorough testing is impossible
    Comprehensive testing attempts to cover all possible combinations of data in the software, in order to ensure that no situation can arise after testing the software has been released. Except in very simple applications, the number of possible data combinations is too high, it is more effective and efficient for test engineers to focus on functionalities according to risks and priorities.
  3. Early testing.
    A product (including documents, such as the product specification) can be tested as soon as it has been created. ISTQB recommends testing a product as soon as possible, correcting errors as quickly as possible. Studies have shown that bugs identified late in the development process generally cost more to resolve.
    For example: an error found in the specifications can be quite easy to fix. However, if that bug is carried over to software coding, once discovered the bug can be very costly and time consuming.
  4. Grouping of Defects
    Studies suggest that problems in a piece of software tend to cluster around a limited set of modules or areas. Once these areas have been identified, efficient test administrators are able to focus testing on sensitive areas, while continuing to search for bugs in the remaining software modules. It reminds me of 80/20.
  5. The 鈥淧esticide鈥 paradox
    Like overuse of a pesticide, a set of tests that are used repeatedly in the pesticide will decrease its effectiveness. Using a variety of tests and techniques you will expose a number of defects across the different areas of the product.
  6. The test is context dependent
    The same tests should not apply across the board. Different software products have different requirements, functions, and purposes. A test designed to be performed on a website, for example, may be less effective when applied to an intranet application. A test designed for a credit card payment method can be unnecessarily rigorous if done in a discussion forum.
    In general, the greater the probability and impact of damage from failed software, the greater the investment in software testing.
  7. The fallacy of absence of errors
    Stating that a test has not discovered any bugs is not the same as stating that the software is 鈥渂ug free.鈥 In order to ensure that proper software testing procedures are carried out in all situations, testers should assume that all software contains some (albeit disguised) bugs.

En la teor铆a de las restricciones es importante tener en cuenta que es lo que hace que la empresa o el producto en nuestro caso, no funcione correctamente o que presente fallas en la calidad, para esto seg煤n la teor铆a, es importante :

  1. identificar la restricci贸n (Lo que no nos permite llegar a la meta)
  2. explotar la restricci贸n, es decir garantizar que la restricci贸n siempre este en funcionamiento
  3. subordinar todo a la restricci贸n, se deben sincronizar los procesos al ritmo que trabaje la restricci贸n
  4. Elevar la restricci贸n, aumentar la capacidad de las restricciones
  5. Evaluar si hay una nueva restricci贸n, suele ocurrir que al mejorar una restricci贸n aparezca otra, por eso es necesario volver al paso 1

Todo esto con el fin de estar en el proceso de mejora continua

<h4>Principios del testing moderno</h4>

El tester deber铆a de enfocarse en la calidad del producto, del proceso.

El desarrollador deber铆a enfocarse en desarrollar la aplicaci贸n.

Entonces el tester ayudar谩 al desarrollador con las mejores herramientas de desarrollo.

<h5>7 principios del testing moderno</h5>

Los testers podemos comenzar a pasar de ser los due帽os de las pruebas o la calidad, a ser los embajadores de la calidad del producto.

  1. Nuestra prioridad es mejorar el negocio.
  2. Nosotros aceleramos al equipo, usamos modelos como Lean Thinking y Teor铆a de las Restricciones para ayudar a identificar, priorizar y mitigar cuellos de botella en el sistema.
  3. Somos la fuerza para la mejora continua, ayudando al equipo a adaptarse y optimizar para tener 茅xito, en lugar de proporcionar una red de seguridad para detectar fallas.
  4. Nos preocupamos profundamente acerca de la historia de calidad en el equipo, y asesoramos, lideramos y nutrimos el equipo para llevarlos a una cultura de calidad m谩s madura.
  5. Nosotros creemos que el cliente es el 煤nico capaz de juzgar y evaluar la calidad de nuestro producto.
  6. Nostros usamos datos de manera extensa y profunda para entender los casos de uso del cliente y entonces cerrar huecos entre hip贸tesis del producto e impacto del negocio.
  7. Expandimos las habilidades de testing y el conocimiento en todo el equipo; entendemos que esto reduce o elimina la necesidad de un especialista dedicado al testing.
  • Nuestra prioridad es mejorar el negocio
    El producto que se va a entregar al cliente es lo que permite funcionar al negocio. Si en alg煤n momento no quieres hacerlo, est谩s poniendo en riesgo ese negocio porque si el producto no se vende o no es aceptado la empresa puede cerrar o puedes perder el trabajo.

  • Nosotros aceleramos el equipo y usamos modelos como Lean Thinking y Teor铆a de las Restricciones para ayudar a identificar, priorizar y mitigar cuellos de botella en el sistema.
    Cuando queremos hacer algo, lo queremos hacer perfecto y eso puede ser demasiado. Deber铆as construir en base a procesos cortos para poder encontrar los defectos de una manera m谩s r谩pida.

  • Nosotros somos la fuerza para la mejora continua, ayudando al equipo a adaptarse y optimizar para tener 茅xito, en lugar de proporcionar una red de seguridad para detectar fallas.
    El cliente puede entender que el producto se va a liberar por fases, es importante que nosotros enfoquemos nuestras pruebas en cada una de esas fases. No tiene que ser todo al inicio y al final, debe haber una distribuci贸n que nos permita manejar el riesgo del software

  • Nos preocupamos profundamente acerca de la cultura de calidad en nuestro equipo, y asesoramos, lideramos y nutrimos el equipo para llevarlos a una cultura de calidad m谩s madura.
    Al inicio los testers eran personas desarrollando software y un d铆a con tantos defectos y trabajo, separaron los roles y as铆 hubiese una persona dedicada a realizar las pruebas. El tester puede hacer recomendaciones de herramientas, mejorar el proceso o volverse un coach.

  • Nosotros creemos que el cliente es el 煤nico capaz de juzgar y evaluar la calidad de nuestro producto
    Si el cliente esta satisfecho con lo entregado y cumple las expectativas entonces has alcanzado la calidad deseada.

  • Nosotros usamos datos de manera extensa y profunda para entender los casos de uso del cliente y entonces cerrar huecos entre hip贸tesis del producto e impacto del negocio.

  • Expandimos las habilidades de testing y el conocimiento en todo el equipo; entendemos que esto reduce o elimina la necesidad de una especialista dedicado al testing.

El tester debe dominar varias areas necesita entender y tener toda la visi贸n del producto y negocio. Saber sobre herramientas que optimicen el trabajo.

curso de appium por favor!!!

鈥淓l Tester pasa a tener una visi贸n general de la empresa y adem谩s dominar temas t茅cnicos asociados a cada una de las 谩reas: Desarrollo, dise帽o, documentaci贸n, an谩lisis de requerimiento, documentaci贸n t茅cnica que se entrega al final al usuario como gu铆as de ayuda etc. El rol del Tester es: Acompa帽ar en todo el proceso y la pol铆tica la CALIDAD del producto鈥. Esto define la responsabilidad e importancia de los tester. Amando este curso!!!

Yo creo que para que estos principios se apliquen tiene que ver con la cultura de la organizaci贸n. Por ejemplo el principio que dice que 鈥淟os testers comparten estrategias y conocimiento relacionado al testing para que se dependa menos de un especialista鈥. Esto depende de todos, de la cultura, si es una cultura abierta entonces va a funcionar, si no, pues no

Yo no he trabajado tanto en la parte de desarrollo de Software comercial, pero si en la parte de software para la industria manufacturera, es decir, PLC y esas cosas. Y en efecto, nada de esto se hace. Las 煤nicas pruebas que se hacen de manera exhaustiva es el funcionamiento de la parte f铆sica, m谩s no de la parte de programaci贸n.

Est谩 demasiado cargada esa web. No permite agregar ni realizar nada. 鈥淐urso de Selenium porfa鈥

Por el minuto 7 dice que quien eval煤a la calidad de nuestro producto es el usuario final, nuestro cliente.
Pero cliente y usuario final son distintos por ejemplo desde el UX.

Es mi imaginaci贸n o efectivamente son lo mismo?

El tester debe dominar varias 谩reas, necesita entender y tener toda la visi贸n del producto y negocio. Saber sobre herramientas que optimicen el trabajo. Si el cliente esta satisfecho con lo entregado y cumple las expectativas entonces has alcanzado la calidad deseada.

El principio que m谩s me llam贸 la atenci贸n es el uso extenso y profundo de datos de prueba, yo he intentado hacer mockups de datos pero la verdad siempre me faltan opciones, uno tiende a hacer mockups con los valores m谩s comunes y no recuerda incluir los casos extremos o poco comunes.

tambien de SonarQube

Muy buena clase para poder implementarlo en mi trabajo.

Donde trabajo si bien no tenemos implementado los 7 principios, si tenemos la pr谩ctica de realizar pruebas a cada cosa que vamos a implementar, d谩ndo garant铆a de los criterios de aceptaci贸n, para que el resultado final sea el esperado por negocio, que en nuestro caso es nuestro cliente final

En d贸nde trabajo a煤n no est谩 implementando todo este proceso.

Genial!, Mi objetivo es pasar de Funcional a Automatizar, No olvidemos el Ingles! jeje

El desarrollo y prueba de soft. involucra humanos. Por lo tanto la psicolog铆a tiene efectos importantes.

1.5.1 Psicolog铆a Humana y el Proceso de Prueba

La identificaci贸n de defectos en una prueba, como una revisi贸n de requisitos, refinamiento de US o identificaci贸n de fallos durante la ejecuci贸n de una prueba din谩mica, puede ser percibida como una CR脥TICA al producto y a su autor.

El sesgo de confirmaci贸n puede dificultar la aceptaci贸n de info q este en desacuerdo con las creencias actuales EJ; los dev, esperan q su c贸digo est茅 bien. tienen un sesgo de confirmaci贸n, q hace dif铆cil aceptar q el c贸digo sea incorrecto.

Otros sesgos cognitivos pueden dificultar q las personas acepten la info producida por la P. Asimismo un rasgo humano es com煤n culpar al portador de malas noticias. y la info de prueba a menudo tiene malas noticias

Por eso las personas perciben el proceso de pruebas como una actividad destructiva, a pesar de que contribuye al avance y calidad del producto

Para reducir estas percepciones, la info de fallos y D deber ser comunicada de manera constructiva. De esta manera se podr谩 reducir las tensiones entre testers, analistas, DEV, clientes y dise帽adores. Esto aplica para Pruebas dinamicas y estaticas.

Los testers y jefes de P deben tener buenas competencias interpersonales para comunicar eficazmente los D, fallos ,avance , resultados de P y riesgos, y para construir relaciones positivas con sus compa帽eros de trabajo.

Formas de comunicarse de forma adecuada. Ejem:

  • Comenzar una colaboraci贸n en lugar de batalla. recordar que el objetivo com煤n es lograr S de mejor calidad
  • Enfatizar los beneficios de la P. ej: los autores mejoran su trabajo y competencias. ahorra tiempo/dinero a la org.
  • Comunicar el resultado de P. de manera neutral y centrada. sin criticar al dev. Redactar informes de defecto objetivos y fundamentados en hechos y revisar los hallazgos.
  • Tratar de entender c贸mo se siente la otra persona y sus razones, en caso de reaccionar negativamente a la info.
  • Confirmar que el interlocutor entendi贸 lo que se dijo y viceversa.

Definir claramente el objetivo de P, tiene importantes implicaciones psicol贸gicas. las personas tienden a alinear sus planes/comportamientos con los objetivos del equipo, direcci贸n y otros implicados. los tester deben tener estos objetivos sin sesgo personal.

7 - Expandimos las habilidades de testing y el conocimiento en todo el equipo; Entendemos que esto reduce o elimina la necesidad de un especialista dedicado al testing.

  • El tester necesita expandir su conocimiento hacia el negocio.

6 - Nosotros usamos datos de una manera extensa y profunda para entender los casos de uso del cliente y entonces cerrar huecos entre hip贸tesis del producto e impacto del negocio.

  • Una falta de vision general e inclusive pensamiento lateral puede hacer que la cantidad de datos no sea la optima para realizar la prueba.

5 - Nosotros creemos que el cliente es el 煤nico capaz de juzgar y evaluar la calidad de nuestro producto.
El cliente es quien decide si cumple o no cumple la calidad esperada.

  1. Nos preocupamos profundamente acerca de la cultura de calidad en el equipo, y asesoramos, lideramos y nutrimos el equipo para llevarlos a una cultura de calidad m谩s ardua.
  • Pasar de ser solamente testers a desarrollar una cultura de calidad que sobrepase lo esperado.

Principios del testing moderno:

  1. Nuestra prioridad es mejorar el negocio.
  • El hacer, ejecutar y actuar de manera resposable y encaminada a la consecusi贸n de objetivos hara sustentable el negocio.
  1. Nosotros aceleramos al equipo, usamos modelos como Lean thinking y teoria de las restricciones para ayudar a identificar, priorizar y mitigar cuellos de botella en el sistema.
  • construir en base a procesos cortos que te permitan encontrar de una manera m谩s rapida los defectos.
  • creando modulos en vez de piezas grandes.
  • facilitando la deteccion de errores de dise帽o.
  1. Somos la fuerza para la mejora continua, ayudando al equipo a adaptarse y optimizar para tener exito, en lugar de proporcionar una red de seguridad para detectar fallas.
  • adaptarse a la liberaci贸n de software por etapas para realizar la mejor validaci贸n del modulo en especifico.

no creo implementarlos en mi trabajo

Estos 7 principios algunos en mi empresa se est谩 llevando, otros no se llevan y otros hay que corregirlos.

Es muy importante los principios del tester me gustaria aportar todo este conocimiento en la empresa con la finalidad de entregar un buen producto y obtener la satisfacci贸n del cliente .

Empec茅 a trabajar como Tester Manual este a帽o y me gustar铆a aportar mas en mi equipo, no solo quiero dedicarme a encontrar bugs y mejoras, quiero involucrarme mas con el proyecto

Excelentes principios

Creo que el testing y el desarrollador deben estar constantemente comunicados para poder seguir un mismo hilo para poder finalizar de forma correcta el proyecto

Si dejan realizar esos principios en el 谩rea, es de notar que se debe mejorar en la optimizaci贸n de pruebas con ayuda de automatizaci贸n.

No siempre ya que como se menciona durante este capitulo, generalmente s presenta una ruptura de comunicaci贸n entre el Desarrollador y el analista.

creo que cada uno de estos principios van muy de la mano con la metodolog铆a de trabajo Scrum, y la verdad en mi empresa los implementan, me parece super importante entender muy bien la necesidad del cliente y qu茅 es en s铆 lo que se busca con la aplicaci贸n o desarrollo que se est谩 haciendo, para saber que pruebas deben realizarse

Si se logra implementar estos principios.

un curso de selenium con mas ejemplos practicos de testing por favor

Yo utilizo las buenas practicas de Damn Vulnerable Web App (DVWA) al crear aplicaciones Web, es muy recomendable, ademas de que aprendes sobre seguridad inform谩tica.

yo aun me encuentro estudiando y en mi carrera esta la materia pruebas de software, lo curioso es que ya la lleve pero no recuerdo a ver visto en clase los 7 principios, as铆 que agradezco esta informaci贸n e investigare mas.

Los 7 principios del testing moderno engloban aquello que en ia industria tiene las funciones del aseguramiento de la calidad que tiene facultad en cada area o departamento y cuya finalidad es abonar que el producto cumpla con las expectativas del cliente

Los principios son elementales en las pruebas de calidad del software, hay que entender que DEV y QA , no deben trabajar separados sino siempre en pro del objetivo y de la mejora del negocio es lo primordial.

Lean thinking: est谩 enfocado en la creaci贸n de valor para el cliente que permite mejorar el proceso con menos costo, tiempo y de alta calidad

El testing moderno vino revolucionar la calidad de software debido a que al llevar a cabo pruebas en cada fase del proceso la carga de trabajo y el tema econ贸mico mejora

La segmentaci贸n de las pruebas es la etapa m谩s determinante ya que es donde se pueden definir los diferentes elementos a probar.

La estrategia y herramientas en este punto, tienen much铆sima relevancia, ya que se deben utilizar acorde a la segmentaci贸n de las diferentes pruebas.

Ya sea de forma global o de manera espec铆fica.

Con respecto al testing moderno, agradezco mucho el permitirnos conocer acerca de este, personalmente no conoc铆a los principios y me parece que es un tema interesante, de hecho considero que actualmente se requiere con urgencia aplicarlos, puesto que muchas personas basan su trabajo en ejecutar pruebas, en diligenciar formularios con los resultados obtenidos, reportar bugs en herramientas o capturar evidencias, no existe una conciencia absoluta de la importancia que tiene el trabajo que realizamos
Muchas personas se convierten en tester por la necesidad de ganar dinero, se dedican a ejecutar casos, pero no proponen mejoras para el proceso. Existen empresas donde se exige que los tester se certifiquen, pero no les permiten participar en los procesos generando ideas y adquiriendo conocimiento que permita enriquecer su labor.
El testing moderno me atrevo a decir que es una mirada amplia a la evoluci贸n tecnolog铆a, donde el conocimiento se vuelve diverso, donde las habilidades van m谩s all谩 de ejecutar pruebas funcionales manuales, est谩 el inter茅s por adquirir habilidades, explotar herramientas , metodolog铆as y por supuesto compartir todo lo aprendido.

muy buen tema el de principios del testing moderno, actualmente en la empresa donde estoy son muy abiertos los PO,lideres tecnicos y en general todo el equipo de desarrollo a las mejoras que se encuentran desde el equipo QA en las pruebas que se realizan sobre los entregables

Como usuario de un taller de colision al manejar diferentes plataformas de compa帽铆as de seguros no esta bien que cuando se cargan los repuestos este proceso requiera demasiado tiempo ya que los nombres de las piezas varian de acuerdo a cada plataforma y si el repuesto es buscado como esta el catalogo del vehiculo en muchas ocasiones no se encuentra por que cada aseguradora maneja un nombre diferente.

Excelente Explicacion.

si no hay buenas practicas que incluyen hacer pruebas desde la perspectiva del desarrollo, el tester tiene que pasar no solamente encontrar defectos si no tambi茅n
de hacer recomendaciones de herramientas mejorar el proceso volverte un couch,
las empresas que mejor logran una escalabilidad, tanto en el crecimiento de sus equipo, como mantienen la calidad de sus productos, ellos desde sus inicios desde sus pol铆ticas se establecen que la calidad es numero 1, en
facebook por ejemplo lo que hacen es tener en cada una de sus areas de trabajo conceptos y mejores practicas para
que no se les olvide como es hacer un buen producto, y entonces el tester paso
de ser alguien que tenia que conocer de cuestiones muy tecnicas, a tener una mejor visi贸n de todo el producto de toda la empresa y ademas dominar temas t茅cnicos asociados a cada una de las areas, no solo desarrollo, si no tambi茅n dise帽o, documentaci贸n, an谩lisis de requerimientos,
documentaci贸n t茅cnica que se entrega al final al usuario, entonces el rol del
tester es acompa帽ar en todo el proceso y la pol铆tica, la calidad del producto

estos principios los compartir茅 con mi equipo de trabajo son muy claros.

Varios de los principios los aplique, pero con el que m谩s me identifique es el cuarto. Debido a la visi贸nn general que tenia de los productos, muchas veces hacia el papel de analista de negocio y me volv铆a juez y parte.

Me gustan estos principios, creo que los voy a implementar.

Veo que muchos de los principios se pueden aplicar en mi trabajo.
El ejemplo m谩s claro es el del test de datos, se present贸 una ocasi贸n en que la longitud de caracteres no era suficiente para almacenar el nombre que se requer铆a guardar.

Tengo una duda.
Mintras buscaba en la web encontre 7 principios de Testing de acuerdo al libro de ISTQB. Estos son diferentes a los presentados en el curso.

Cu谩les deberia de aprender?

  1. Las pruebas muestran la presencia de defectos
    Significa que las pruebas pueden demostrar que EXISTEN problemas, pero no que los problemas NO EXISTEN.
    El objetivo principal de llevar a cabo una prueba es para detectar defectos. Trabajando bajo la premisa de que cada producto contiene defectos de alg煤n tipo, una prueba que revela los errores es generalmente mejor que una que no lo hace. Todas las pruebas por lo tanto, deben ser dise帽ados para revelar tantos errores como sea posible.
  2. Las pruebas exhaustivas son imposibles

Las pruebas exhaustivas tratan de cubrir todas las combinaciones posibles de datos en el software, a fin de garantizar que ninguna situaci贸n puede surgir, una vez probado el software se ha liberado. Excepto en aplicaciones muy simples, el n煤mero de combinaciones posibles de datos es demasiado alta, es m谩s eficaz y eficiente que los ingenieros de pruebas se centren en las funcionalidades de acuerdo a riesgos y prioridades.

  1. Pruebas tempranas.
    Un producto (incluyendo los documentos, tales como la especificaci贸n del producto) se puede probar tan pronto como se ha creado. ISTQB recomienda probar un producto tan pronto como sea posible, corregir los errores m谩s r谩pidamente posible. Los estudios han demostrado que los errores identificados al final del proceso de desarrollo por lo general cuestan m谩s para resolver.
    Por ejemplo: un error encontrado en las especificaciones puede ser bastante sencillo de solucionar. Sin embargo, si ese error se transfiere a la codificaci贸n de software, una vez descubierto el error puede ser muy costoso y consume tiempo.

  2. Agrupamiento de Defectos
    Los estudios sugieren que los problemas en un elemento de software tienden a agruparse en torno a un conjunto limitado de m贸dulos o 谩reas. Una vez que estas 谩reas han sido identificadas, los administradores eficientes de prueba son capaces de enfocar las pruebas en las zonas sensibles, mientras que siguen buscando a los errores en los m贸dulos de software restantes. Me recuerda al 80/20.

  3. La paradoja del "Pesticida"
    Al igual que el sobre uso de un pesticida, un conjunto de pruebas que se utilizan repetidamente en el disminuir谩 en su eficacia. Usando una variedad de pruebas y t茅cnicas expondr谩 una serie de defectos a trav茅s de las diferentes 谩reas del producto.

  4. La prueba es dependiente del contexto
    Las mismas pruebas no se deben aplicar en todos los 谩mbitos. Distintos productos de software tienen diferentes requisitos, funciones y prop贸sitos. Una prueba dise帽ada para realizarse en un sitio web, por ejemplo, puede ser menos eficaz cuando se aplica a una aplicaci贸n de intranet. Una prueba dise帽ada para una forma de pago con tarjeta de cr茅dito puede ser innecesariamente rigurosa si se realiza en un foro de discusi贸n.
    En general, cuanto mayor es la probabilidad y el impacto de los da帽os causados 鈥嬧媝or el software fallado, mayor es la inversi贸n en la realizaci贸n de pruebas de software.

  5. La falacia de ausencia de errores
    Declarar que una prueba no ha descubierto ning煤n error no es lo mismo que declarar que el software es 鈥渓ibre de errores鈥. Con el fin de garantizar que los procedimientos adecuados de software de prueba se lleva a cabo en todas las situaciones, los evaluadores deben asumir que todo el software contiene algunos (aunque disimulada) errores.

Respecto al ciclo de vida del software. Los libros le ponen mucho inter茅s a todo menos el mantenimiento del software. Es decir, no se enfocan en que se debe priorizar el atributo de calidad de mantenibilidad. Esto lo digo debido a que este atributo directamente afecta a la etapa mantenimiento en la cu谩l es la larga y cara del software por lo que si se diera una mayor relevancia ser铆a m谩s f谩cil darle mantenimiento y ahorrar tiempo y dinero a futuro.

En el 煤ltimo p谩rrafo Blanca, te falta una tilde y signos de puntuaci贸n.

Expandimos las habilidades de testing y el conocimiento en todo el equipo; entendemos que esto reduce o elimina la necesidad de una especialista dedicado al testing.

Esto no implicaria que hubiese menos trabajo para un tester en un futuro?

Quiero hacer este curso como pre谩mbulo para hacer el curso de pruebas con Jest e implementarlo en la aplicaci贸n de react native que desarrollo en la empresa para la que trabajo. Me gusta mucho el enfoque de expandirlo a la cultura empresarial.

Considero que es muy importante tener claridad de los procesos que se debe realizar como tester en una empresa, pero cuando se tiene que realizar tantas tareas a la vez se puede perder el foco de la calidad en el desarrollo, siempre y cuando se cuente con los recursos, se podr铆a implementar en cualquier empresa.

El tester es la voz del cliente y de las buenas pr谩cticas. Lo que queremos darle al consumidor final y lo que agilice el trabajo en equipo es sobre lo que debemos trabajar.

Sin duda, ser tester conlleva una gran responsabilidad ya que por lo visto necesita conocimiento global de las 谩reas que involucra el desarrollo de un proyecto.

El tester debe enfocarse en la calidad del producto, del proceso, del software en general.

Estos principios dejan claro que testing no solo es ejecutar sw y comprobar resultados, sino un proceso que nos ayuda a evaluar la calidad del sw y reducir riesgos de fallos en producci贸n.

Yo encantado de implementarlo, pero es dificil lograrlo, cuanto nuestra mentalidad dominante es hacer siempre lo menos posible.

Este tema es muy interesante e importante, rescato los siguientes puntos

  • Lo importante es el negocio (cliente), define prioridades, alcance y calidad deseada
  • Hay que tener una distribuci贸n que permita manejar el riesgo del software
  • Se debe de contar con una extensa cantidad de datos de prueba

Pienso que en M茅xico es complicado llevar acabo los 7 principios ya que estos principios van basados a un organigrama de proyecto en d贸nde hay especialistas en cada 谩rea, aqu铆 en M茅xico generalmente la gente que desarolla o gestiona un proyecto tiene que encargarse de la parte de la calidad. Ya que muchas empresas buscan disminu铆r costos de RECURSOS HUMANOS teniendo un recurso que sepa de varias cosas. Aun que si se pueden tomar estos principios como algo ut贸pico y un est谩ndar al que deber铆amos de llegar como Pa铆s. Es por eso que si no hay alguien especializado en testing es importante que todo el equipo este involucrado para hacer el mejor trabajo posible.

Ser铆a muy bueno que se especificaran las pruebas a nivel de entregables que se tienen que hacer en cada etapa del desarollo ya que no he visto que ustedes compartan un recursro para ello. Espero en futuras clases lo haya, ya que a final de cuenta la calidad se puede estandarizar en un proceso adaptable para diferentes proyectos.

En algunos lugares por 鈥渇alta de presupuesto y tiempo鈥, no es posible aplicar todo los principios, dado que estamos limitados por las reglas o normas que exigen o aceptan las empresas.

Claramente si una empresa no permite que estos principios no se ejecuten apuntan a, minimo, dos cosas: la mediocridad y que el tester no pueda trabajar c贸modo y por ende se vaya a otra empresa.
Son principios que de ser ejecutados correctamente lograremos avanzar como equipo y como organizaci贸n en general.

Yo trabaje en una empresa que instalaba infraestructura, y que tenia muchos clientes pero poco personal. Era imposible tratar de fomentar una cultura de calidad cuando siempre hab铆a mucho trabajo y hab铆a que estar aprendiendo constantemente sobre muchos temas (redes, servidores, netoworking) siendo 2 especialistas t茅cnicos, pero cuando no hab铆a ninguna inversi贸n en certificaciones o capacitaciones.

El tester juega en muchas formas un rol de facilitador para alcanzar la mejora continua.

El tester representa un herramienta fundamental al momento de desarrollar un software, verificando que el programa tenga un numero muy bajo de errores.

El tester es m谩s importante de lo que se cree

Muy buena clase.

Me encanta 鉂わ笍

Esta sesi贸n me golpea como teste xd Tengo conocimiento en casos de prueba y automatizaci贸n, me falta un largo y dif铆cil camino para llegar a ser un l铆der y un tutor que influya en la calidad de todas las etapas鈥

En realidad tengo experiencia en el mundo de pruebas y lo que m谩s agradecen los clientes y los contratistas es que uno siga todo los principios explicados en el presente video.