De acuerdo con la filosofía ágil, es importante que el equipo trabaje en conjunto para lograr el objetivo fijado al comienzo de una iteración. Con eso en mente, sé que los desarrolladores y analistas pueden ayudar al control de calidad al final de una iteración para asegurarse de que todas las pruebas se completen a tiempo.
¿Cómo puede el control de calidad ayudar al equipo al comienzo de un sprint si no se completaron historias y los planes de prueba están listos?
(Somos un equipo de 5-6 personas con 1 control de calidad y estamos en sprints de 3 semanas, por lo que el tiempo muerto puede ser largo para el control de calidad)
El control de calidad (QA) es una parte integral del proceso de entrega ágil. Pasar las pruebas es a menudo una parte formal de la definición de hecho, y el desarrollo basado en pruebas (TDD) es una práctica común que se originó con la programación extrema y ha sido ampliamente adoptada por otros marcos ágiles.
Los especialistas en control de calidad de un equipo multifuncional tienen varias formas de contribuir desde el primer día de un Sprint:
Si bien todos los ejemplos anteriores se aplican con mayor fuerza a los proyectos de software, el mismo concepto general se puede transferir en gran medida a los proyectos de fabricación o procesos comerciales. Todos en el equipo tienen algo que aportar, y los mejores equipos nunca "lanzan algo por encima del muro" a otros miembros del equipo; el trabajo siempre debe ser colaborativo.
En algunos equipos, los evaluadores se encargan de implementar las pruebas de aceptación automatizadas mientras los programadores trabajan en la implementación de las nuevas funciones. En otros casos, comienzan a preparar datos de prueba o scripts de prueba que se utilizarán una vez que se incluyan las nuevas historias en la compilación.
A veces, es posible que los programadores no sepan exactamente cuál será el impacto de la nueva característica. Los evaluadores pueden ayudar realizando pruebas exploratorias, simulando la nueva funcionalidad o escenarios similares para brindar retroalimentación anticipada a los programadores. O pueden hablar con los usuarios comerciales para obtener más aclaraciones sobre sus expectativas u obtener ideas sobre cómo probar casos difíciles.
Pero más allá de todo eso, los probadores también podrían considerar retomar tareas de desarrollo y aumentar sus habilidades lateralmente en otras áreas de especialización. Una buena manera de hacerlo es, como se menciona en otra respuesta, emparejarse con programadores.
Yo tuve este problema también. Una gran cosa que hicimos fue poner un límite WIP estricto para los desarrolladores. Esto obligó a terminar las historias antes en el sprint antes de pasar a otra. Esto significa que el control de calidad puede comenzar a probar antes en el sprint para evitar un cuello de botella gigante hacia el final del sprint.
fadaphunk