Con el tiempo, las pruebas manuales se han adaptado a metodologías ágiles como Scrum. Originalmente, los testers trabajaban "al final del sprint", probando el resultado de todo el trabajo. Esto a menudo llevaba a situaciones de emergencia y pruebas insuficientes (historia).
El problema principal es la falta de tiempo para las pruebas, los frecuentes cambios en los requisitos y las tareas que no llegan a los testers durante el sprint. Los testers se sienten presionados, lo que disminuye la calidad (problema).
La solución es integrar a los testers en el equipo desde el principio del sprint: participar en reuniones, planificar casos de prueba a medida que surgen nuevas tareas, organizar retrospectivas y stand-ups diarios juntos, así como fomentar la transparencia del estado de los artefactos de prueba (solución).
Características clave:
¿Se puede comenzar a probar solo después de completar todas las tareas del sprint?
No, el tester debe involucrarse desde los primeros días del sprint y, si es posible, probar la funcionalidad que aún no está completamente terminada.
¿Se deben corregir todos los errores en el sprint actual?
No necesariamente, los errores críticos sí, los no críticos pueden trasladarse al backlog externo y corregirse en el siguiente sprint.
¿Es necesario realizar pruebas manuales en Scrum si hay automatización?
Sí, las pruebas manuales son críticas para verificar nuevas funcionalidades y requisitos no formalizados, así como para pruebas exploratorias.
El tester no participó en la planificación y no tuvo acceso a las nuevas historias de tareas hasta el final del sprint. Como resultado, las pruebas se escribieron apresuradamente y algunos errores se trasladaron a los siguientes sprints.
Pros:
Contras:
El tester se unió al equipo desde los primeros días del sprint, participó en reuniones, vio las tareas que surgían de antemano y planificó las pruebas paralelamente al desarrollo.
Pros:
Contras: