En un equipo de scrum hay probadores de automatización y probadores manuales, así como desarrolladores de front-end y mid de base de datos. Mientras que los evaluadores de automatización desde el comienzo del sprint comienzan a crear pruebas para automatizar la interfaz de usuario, las pruebas manuales generalmente esperan a que se implemente el código, mientras crean largos planes de prueba que cubrirán todos los casos de prueba para el trabajo realizado. Luego, esperan a que se implemente el código, y solo entonces comienzan a probar y a poner sus resultados en el software de prueba central. Esto crea una sobrecarga de prueba masiva que termina en historias que no se realizan. Además, a veces, a pesar del breve desarrollo, las pruebas pueden tardar varios días en completarse.
¿Cuáles son sus sugerencias para adaptar los probadores manuales, manteniendo la calidad del software en el entorno de preproducción?
Cuanto antes los desarrolladores puedan enviar el código a los evaluadores, menor será el riesgo de que se retrase el sprint.
Hay una serie de cosas que el equipo puede hacer para ayudar con esto.
Minimiza el tamaño de las historias. Cuanto más pequeños sean, antes en el sprint se completarán las historias y antes podrán comenzar los probadores manuales.
Planifique con cuidado. Concéntrese en la reunión de planificación en qué orden de las historias mantendrá ocupados a los probadores manuales. ¿Quizás hay ciertas historias que requieren muchas más pruebas que otras? Estas historias deben trabajarse primero y, si es posible, dividirse para que se entreguen antes.
Trabaje en cada historia por turnos y decida qué es práctico desarrollar y probar en el sprint. Puede ser que algunas combinaciones de historias simplemente no sean prácticas, especialmente si todas son de prueba manual.
Intenta salir de la sesión de planificación del sprint con una idea de lo que se hará y cuándo. Por supuesto, esto no será perfecto, ya que sucederán cosas inesperadas una vez que el trabajo haya comenzado. Pero encontrará que hay un valor real en dedicar tiempo durante la planificación para minimizar estos problemas.
En el mediano/largo plazo, es posible que desee considerar la posibilidad de que los probadores manuales se entrenen para aprender a realizar pruebas automatizadas. Esto le dará más flexibilidad y le permitirá generar pruebas de regresión más automatizadas. También ayudaría si los desarrolladores estuvieran dispuestos a ayudar con las pruebas. Esto le permitiría reducir el tiempo transcurrido para la prueba manual.
Finalmente, si todavía tiene el problema de las historias incompletas al final del sprint (ya que no se han probado), entonces el equipo debería comenzar a aportar menos puntos de historia al sprint. Es mejor que el equipo trabaje en una cantidad realista de puntos de la historia que tenerlos continuamente sin completar algunas historias.
dqm
Barnaby dorado