Recientemente agregué un probador de control de calidad a nuestro nuevo equipo de Scrum. El probador viene con mucha experiencia en pruebas automatizadas y es capaz de crear secuencias de comandos, codificación ligera, etc. Utilizará herramientas de automatización, como Selenium, para ayudar con el proceso de control de calidad. Sin embargo, no tengo claro dónde trazar la línea en sus responsabilidades. Además, ¿cómo incorporo el control de calidad en la pizarra?
1) Rol y Responsabilidades
2) Control de calidad en la pizarra de Scrum
En mi experiencia, el personal de control de calidad generalmente maneja las pruebas de aceptación y del sistema, por lo que creo que este sería un buen lugar para comenzar. Esto incluye pruebas tanto manuales como automatizadas del sistema frente a los requisitos (funcionales y no funcionales). Dada la forma en que describe los antecedentes del individuo, parece que este es un conjunto apropiado de responsabilidades para él. Por eso, sí, sería la persona que decide si y cuándo se realiza un requisito implementado.
Personalmente, involucraría a un especialista en control de calidad en cada fase del ciclo de vida, desde los requisitos hasta el lanzamiento. Esto significaría revisar sus requisitos para garantizar que sean buenos requisitos y proporcionar una exposición temprana para crear casos de prueba a partir de diseños (con énfasis en la capacidad de prueba y la correlación de las decisiones de diseño con los requisitos), documentación (especialmente la que se envía al cliente). ), código y pruebas, y paquetes de material publicados.
También podría participar en la medición de la calidad del producto mediante el uso de medidas y métricas adecuadas. Estos incluirían complejidad ciclomática, cobertura de prueba, complejidad de Halstead , defectos, líneas de código, etc. Luego podría informar sobre estos para cada iteración, identificando módulos que son de alta complejidad (lo que indica que una posible refactorización está en orden), tienen una baja cobertura de prueba (lo que indica que tal vez se necesitan más pruebas unitarias o de integración) y densidad de defectos. Dado que también tiene algo de experiencia con la escritura de código, podría mirar la base del código, comprenderlo y comentar sobre su estado de una manera apropiada para audiencias técnicas y no técnicas, incluso si él es No se está desarrollando activamente.
Otras tareas variarían y dependerían del equipo, el proyecto, el cronograma y la carga de trabajo del individuo. Debe asegurarse de que realmente pueda realizar sus tareas en el transcurso de una semana normal, ya que trabajar horas extra generalmente se considera un antipatrón en la comunidad ágil.
En cuanto a la gestión del control de calidad en su sistema de seguimiento de proyectos, depende de lo que su equipo se sienta cómodo haciendo. En algo como Kanban , cuando un desarrollador siente que la función está implementada y probada por el desarrollador, se trasladaría a control de calidad. Sin embargo, puede optar por mantener solo una acumulación de productos, una acumulación de sprints y un conjunto de elementos completados. En ese caso, permanecería en la acumulación de sprint hasta que el control de calidad lo llame "hecho", momento en el que se mueve a completado y obtienes tus puntos. Puede haber algún otro sistema desarrollado por su equipo que funcione mejor, siempre y cuando tenga sentido para su forma de trabajar y no interfiera con el trabajo de todos.
La respuesta de Clayton estuvo cerca. Sin embargo, iría más allá y diría que cualquier equipo que excluya el control de calidad del equipo, o que trate a los especialistas de control de calidad como ciudadanos de segunda clase dentro del equipo Scrum, ha perdido por completo el punto de la metodología Scrum y cómo funcionan las prácticas ágiles como XP. .
Los conceptos centrales detrás de cualquier metodología ágil se reducen a la visibilidad y la comunicación continua . Si los miembros de su equipo de control de calidad no están trabajando junto con los desarrolladores, termina con un código que se tira por la borda en algún momento del proceso.
Incluso si tiene un equipo en el que los miembros individuales no son multifuncionales, el equipo en su conjunto debería serlo. El control de calidad debe participar activamente en cada paso. Por ejemplo:
Una vez que haya reconocido que QA es parte del equipo, necesita que las tareas de QA sean tan visibles como el resto del trabajo en el proyecto. Ningún trabajo invisible, ¡nunca!
Si realiza un seguimiento de las tareas de sprint en un tablero Kanban, también debe realizar un seguimiento del control de calidad en el tablero. Si requiere su propia columna es un detalle de implementación que el equipo puede determinar por sí mismo y refinar a través de retrospectivas. Muchos equipos encuentran un carril o columna de natación separada para el control de calidad que agrega valor, pero ciertamente no es un requisito .
Todo lo demás en la pregunta original es un proceso para que el equipo en su conjunto (incluidos los miembros de control de calidad) lo defina, y lo perfeccione continuamente, por sí mismo. Siempre que haya una "definición de hecho" que todo el equipo haya acordado, los detalles de implementación realmente no importan.
Los equipos Scrum están formados por miembros multifuncionales. Es peligroso categorizar a una persona como la persona de control de calidad (o DBA, o experto en seguridad, etc.). Debe esforzarse por integrar a esta persona en el equipo para que pueda compartir su experiencia con otros como miembro del equipo, no como un recurso especializado. .
Todo el equipo es responsable de determinar un nivel aceptable de cobertura de código, qué tipo de prueba se realiza y qué ayuda a contribuir a la definición oficial de hecho. Deje que el equipo determine cómo mostrar el esfuerzo de prueba en la pizarra. Deberían estar usando sus radiadores de información para su propio beneficio.
En mi experiencia, funciona mejor tener miembros de control de calidad como observadores del equipo SCRUM, pero no como miembros. Un buen equipo SCRUM suele ser pequeño (3-4 miembros, pero 2 también es común) y bastante intercambiable (es decir, Bill se está atrasando en su historia de usuario, que es una prioridad más alta que la mía, así que dejaré de hacer la mía y lo ayudaré ). Además, no es justo pedirles a los miembros de control de calidad que escriban historias de desarrollo. En mi experiencia, lo que funciona mejor es tener equipos de QA SCRUM separados que trabajen 1 sprint detrás del equipo de desarrollo. Sin embargo, eso requiere un compromiso con la calidad del desarrollo, ya que el código debe ser lo suficientemente sólido como para que llamar a los desarrolladores para corregir errores no sea muy común. Descubrí que lo que funciona mejor es crear que cada desarrollador cree una página wiki para su historia de usuario y describa sus pruebas (con suerte automatizadas, su impacto en las pruebas de cobertura y Find Bugs). Este wiki es parte de "hecho hecho" y se revisa en la revisión de código.
Si no realiza pruebas durante el sprint, hará que su equipo retroceda para corregir errores en lugar de concentrarse en el siguiente sprint. Es imperativo que los equipos de scrum tengan un recurso de control de calidad y que las pruebas comiencen durante el sprint y lo antes posible. No es scrum si todavía tiene pruebas y corrección de errores después de que finaliza el sprint.
Sr. Hinsh - Martin Hinshelwood