¿En qué etapa de Agile (SCRUM) debemos comenzar a crear pruebas de automatización?

9

Un poco de historia mía: soy probador manual durante casi 2 años en un entorno ágil usando SCRUM (sprints de 1-2 semanas). Así que quiero introducir pruebas de automatización en mi trabajo usando Selenium WebDriver (con Java).

Mi pregunta es cuándo debería probar la funcionalidad manualmente y cuándo debería convertirla para pruebas de automatización.

He estado leyendo y obteniendo diferentes enfoques, como:

Cuando se inicia un nuevo sprint, convierta las historias de usuario en scripts automatizados del sprint anterior, O;
Convierte las historias de los usuarios dentro del mismo sprint.

Cualquier consejo / s sería muy apreciado. Gracias de antemano.

— Arrendajo
fuente

44

No publique la misma pregunta en dos sitios de intercambio de pila diferentes. Por favor, elimine uno de ellos.

— R Sahu

2

Cruz publicado en sqa.stackexchange.com/questions/27017/… .

— R Sahu

13

La automatización de pruebas (y todas las demás pruebas) deberían ser parte de la definición de hecho . Esto con el fin de hacer un producto potencialmente enviable. ¿Se puede enviar si no fue probado?

Las pruebas también deben ser un enfoque de equipo completo, por lo que la automatización de pruebas no es responsabilidad de los evaluadores. Comience a pensar en las pruebas lo antes posible en el proceso.

La automatización de pruebas es muy importante en Agile porque:

La agilidad organizacional está limitada por la agilidad técnica

En otras palabras, cuando se demora en hacer cambios en su producto, no importa cómo estructurar sus equipos, su organización o qué marco adopta, será lento para responder a los cambios.

https://less.works/less/technical-excellence/index.html

Si pospone la prueba hasta otra iteración, siempre se quedará atrás. Haciendo más difícil cambiar la dirección del producto, ya que es más difícil refactorizar y proteger el comportamiento externo del producto. Tener pruebas manuales repetitivas es clave para reducir la velocidad, ¡automatízalo!

Muchos probadores le dirán que no debe comenzar las pruebas de extremo a extremo hasta que la interfaz del producto se haya estabilizado. No espere, en su lugar, haga un buen uso de PageObjects y asegúrese de que sus pruebas sean mantenibles y que sea responsabilidad del desarrollador crearlas y corregirlas.

— Niels van Reijmersdal
fuente

No estoy de acuerdo con el primer "debería". La definición de hecho es algo que el equipo Scrum necesita resolver por sí mismo. Si el equipo considera importante la prueba automatizada, la incluirán como parte de su definición. Sin embargo, el proceso en sí no dice que deben hacerlo, o incluso que deberían hacerlo. Es algo que depende completamente del equipo, y no hay una respuesta correcta, incorrecta o preferida.

— Aroth

@aroth Estoy de acuerdo con usted, pero en casi todos los casos construye un producto de software más grande que desea agregar pruebas al DoD. Por lo tanto, creo que es bueno decirle a la gente que deberías, al menos pensar seriamente en ello. Como probador, creo que las pruebas al final por un equipo separado son los primeros pasos para Wagile. Pero sí, hay situaciones o casos en los que las pruebas podrían no ser necesarias.

— Niels van Reijmersdal

2

La clave es que no marca una historia completa a menos que haya escrito pruebas automatizadas para esa historia.

Así que 1 parece estar fuera, ya que está escribiendo pruebas para una tarea completada en un sprint anterior. ¿Qué pasa si las pruebas fallan?

— Ewan
fuente

Entonces, si en la primera semana de un nuevo sprint no hay una historia de usuario de ese sprint en un estado en el que se pueda probar la regresión, ¿sugieres que el OP se vaya a casa y no haga nada? No me parece muy eficiente ;-)

— Doc Brown

El probador debería usar esa primera semana para cuestionar la especificación "hmmmm como usuario, esperaría música de fondo en mi página web ...", encontrar errores en historias incompletas y generalmente causar problemas. Los desarrolladores pueden decir que no pueden comenzar hasta que se escriban los planes de prueba

— Ewan

@DocBrown: en la primera semana de un nuevo sprint, el probador tiene una increíble cantidad de trabajo por hacer. Deben comprender qué están construyendo los desarrolladores trabajando con el propietario del producto y los desarrolladores. Deben trabajar con el desarrollador para asegurarse de que el código sea comprobable. Pueden comenzar a trabajar en un plan de prueba automatizado. Incluso pueden comenzar a escribir algunas pruebas. Si tiene un marco de prueba adecuado donde sus pruebas se escriben en un alto nivel de abstracción, puede escribirlas antes de que el código esté listo.

— Bryan Oakley

1

Idealmente, debe escribir pruebas automatizadas en el mismo sprint en el que se escribe el código. El código no debe considerarse "hecho" hasta que se hayan escrito las pruebas automáticas, y debe llevar el código a un estado "hecho" al final de un sprint.

Debe comenzar el proceso el primer día del sprint trabajando con el desarrollador para comprender el código y ayudarlo a comprender sus necesidades como probador. Por ejemplo, si está creando páginas web, puede ayudarlos a comprender la necesidad de agregar identificadores únicos para cada elemento de la página con el que necesita interactuar.

Recuerde que en scrum, su trabajo no es escribir exámenes. Su trabajo es trabajar con el equipo para completar los objetivos del sprint. Eso significa comunicación y colaboración, lo que debería suceder muy temprano en el sprint. Puede comenzar a trabajar en diseños de prueba y planes de prueba mucho antes de que el código esté listo para ser probado.

— Bryan Oakley
fuente

0

Si va a realizar una prueba automáticamente, también puede crear las pruebas por adelantado. Esto lo ayudará a definir qué comportamiento espera y lo estimulará a pensar como un cliente, al final debería hacer que su software sea más útil. Y se beneficiará de la prueba inmediatamente mientras implementa la funcionalidad.

— Martin Maat
fuente

1

Eso no funciona con herramientas de prueba de IU como Selenium. Necesita una IU funcional y estable para poder crear las pruebas.

— Doc Brown

@DocBrown: No creo que sea necesariamente cierto. Si me da una especificación para una nueva página web, puedo comenzar (¡y quizás terminar!) Escribiendo pruebas automatizadas antes de que se escriba la página. Simplemente necesita colaborar con el desarrollador para que ambos acuerden cuál es la estructura de la página, cuáles son los identificadores de los elementos, etc.

— Bryan Oakley

0

Puede hacerlo, pero normalmente desea orientar las pruebas de regresión con pruebas de automatización. Eso significaría que haría manual hasta que esté seguro de que es lo suficientemente sólido como para ser una prueba de regresión. Esto puede estar en el medio de un sprint para alguna funcionalidad y puede estar en un sprint futuro para otra funcionalidad.

— chucho
fuente

0

Como se indicó en otra respuesta , cuando se realiza la prueba debe ser parte de la definición de hecho . Sin embargo, no estoy de acuerdo con algo de esa respuesta, por lo que quería ampliar con las experiencias que he encontrado.

En un entorno verdaderamente ágil, todos pueden hacer todo. No habría alguien 100% dedicado a las pruebas, también desarrollarías habilidades para ayudar con el trabajo básico de la interfaz de usuario u otra cosa. Sin embargo, rara vez vivimos en un mundo ideal.

Lo que recomendaría sería hacer un enfoque híbrido. Para su definición de Hecho, yo diría que las pruebas manuales deberían ser parte del Sprint en el que está codificado el trabajo. Usted sabe que funciona, y cualquier error puede ser reportado inmediatamente, posiblemente reparado, antes de que el Sprint termine para que pueda planificar el próximo uno. Al centrarse en las pruebas manuales, se familiariza con lo que se supone que debe hacer el código. Al comienzo del próximo Sprint, cuando no tengas tanto que hacer, puedes configurar tus pruebas automatizadas que pueden ejecutarse como parte del proceso de construcción para evitar errores de regresión.

— krillgar
fuente

Nunca he visto un sprint donde ya no había mucho que hacer en los objetivos actuales del sprint en el primer día. Escribir pruebas automatizadas requiere colaboración y planificación, y eso debe comenzar en la primera hora del primer día del sprint.

— Bryan Oakley