Tenemos tres equipos contribuyendo al mismo producto. Actualmente, las pruebas de nuestro sistema automatizado están siendo escritas por dos personas de control de calidad que ven lo que se ha terminado en las revisiones y luego escriben las pruebas apropiadas.
Eso ha estado funcionando bien, pero ahora estamos avanzando hacia la implementación continua y debemos asegurarnos de que las pruebas del sistema se escriban durante el Sprint para que podamos ejecutar inmediatamente las pruebas de regresión. Dado que ninguno de los equipos posee completamente la función en este momento, no tenemos claro quién debería ser responsable de las pruebas del sistema.
La Guía Scrum establece que un equipo Scrum debe tener todas las habilidades necesarias para entregar un incremento de producto.
La idea es que un equipo tome una o más funciones y las implemente por completo al final de un sprint. Los equipos de Scrum son dueños de las funciones en las que están trabajando y esto incluirá la prueba y la implementación del sistema.
Cuando tiene varios equipos de Scrum trabajando en el mismo producto, una práctica común es que cada equipo trabaje en un tema de función (por ejemplo, un equipo podría estar trabajando en funciones de seguridad y otro podría estar trabajando en funciones de personalización).
Independientemente de cómo se divida el trabajo entre los equipos, el enfoque es el mismo. Cada equipo asume toda la responsabilidad por la entrega de una característica hasta que sea potencialmente liberable .
En su situación, le sugiero que considere:
También es posible que desee reconsiderar la forma en que realiza sus pruebas automatizadas. Muchos probadores automáticos con los que he trabajado comenzarán las pruebas al mismo tiempo que comienza el desarrollo. No esperan a que termine el desarrollo para comenzar a crear las pruebas automatizadas.
Un enfoque común es que los desarrolladores produzcan rápidamente un lanzamiento de código auxiliar que imite la función que están a punto de desarrollar. Luego, los evaluadores comienzan inmediatamente a escribir una prueba. Una vez que los desarrolladores han terminado el desarrollo, intercambian el código auxiliar y lo reemplazan con el código real.
Mucho depende de su marco escalado, pero en general la respuesta será que cada equipo Scrum individual es responsable de probar su propio trabajo. Por ejemplo, al usar Nexus :
Los Equipos Scrum son responsables de desarrollar Incrementos de software potencialmente liberable, según lo prescrito en Scrum. [Nota: un incremento completo debe abarcar la definición completa de Listo, incluida la prueba del incremento. ]
El equipo de integración de Nexus se hace cargo de cualquier problema de integración. Es responsable de la integración exitosa de todo el trabajo de todos los equipos Scrum en un Nexus. La integración incluye resolver cualquier restricción técnica y no técnica entre equipos que pueda impedir la capacidad de un Nexus para ofrecer un Incremento Integrado constante. [NB: Probar los incrementos de cada equipo Scrum para ellos no es una función entre equipos que pertenezca al equipo Nexus. El enfoque adecuado de un Nexus es la integración entre equipos. ]
En Nexus, puede haber miembros del equipo Nexus que se encarguen de probar la integración del trabajo entre equipos. Sin embargo, la suposición es que cada equipo de Scrum está entregando un trabajo probado y funcional para ser integrado en el incremento de Nexus.
Si está tratando de reducir costos o tomar algún tipo de atajo operativo al externalizar las actividades de prueba, no está siguiendo un enfoque Scrum escalado. Ni siquiera está siguiendo las mejores prácticas ágiles en ese momento. En su lugar, está dando un paso atrás desde los equipos integrados y multifuncionales hacia un enfoque en cascada más tradicional donde el desarrollo y el control de calidad son funciones separadas y secuenciales.
No hagas eso.
¿Quién debe ser responsable de escribir las pruebas automatizadas?
El desarrollador que escribe el código. y preferiblemente , antes de que se escriba el código de producción.
Llámame fanático de TDD si quieres, pero he podido medir la diferencia en la cobertura de prueba entre el código que escribí TDD y cuando escribí las pruebas después de que el código estaba terminado. La cobertura de sucursales es mejor en ~20 % en mi investigación ciertamente no científica (con un tamaño de muestra admitido de 1 desarrollador).
andreas
Federico Wendt