Un flujo de defectos es indispensable para el buen funcionamiento de un proyecto. Con ellos logramos que el defecto siga los pasos adecuados y podamos organizarnos de una manera más sencilla.
¿Cómo hago un flujo de defectos?
Muy sencillo, existen herramientas de Test Management como XRay o Zephyr (para Jira), Redmine, Testlink, ALM Octane, que nos pueden ayudar a la hora de crear un ciclo para nuestro proyecto (jamas uséis excel o similar, por favor).
Lo primero que tenemos que hacer es comprobar como tenemos organizado el proyecto, cuanta gente lo compone y cuáles son sus roles, a partir de ahí, podemos empezar a crear nuestro flujo de defectos.
¿Qué estados debe de tener mi flujo de defectos?
Un flujo tiene que tener 5 estados básicos: “Abierto”, “Asignado”, “En Desarrollo”, “Disponible” y “Finalizado”.
A partir de esos estados se pueden implementar todos los necesarios para nuestro proyecto y nuestras necesidades, por ejemplo, si solo tenemos un tester y un equipo de desarrollo, con este flujo estaríamos cubiertos, pero si hacemos también pruebas de validación por un equipo de UAT, se nos queda corto y deberíamos de introducir más estados, como el de “validado UAT”, “Aceptado QA” o “disponible UAT”, por ejemplo.
¿Me ayudará a ganar tiempo un flujo de defectos?
Depende, si se satura con demasiados estados y validaciones, puede ser que las personas que forman tu equipo o equipos de trabajo no se acuerden de todos y acabe siendo un cuello de botella, por ello hay que ser lo más óptimo posible, buscar la sencillez sin perder ningún paso.
Si tu flujo es óptimo, sin duda ganaras tiempo a la hora de tener organizada tu lista de defectos y el correspondiente backlog, y de una sentada podrás ver como se está desarrollando su finalización y si la calidad está mejorando. Si se ven menos “abiertos” eso es que tu software crea menos fallos, si hay cantidad de abiertos pero son iguales o menores que los “finalizados”, eso quiere decir que tu equipo está generando muchos bugs pero son muy rápidos corrigiendo. Cada uno puede sacar sus conclusiones y estadísticas, basándose en los estados.
Un flujo de defectos se tiene que crear entre todos, nadie puede imponerlo y cada jefe de equipo tiene que aportar los estados en los que se sentirán cómodos. Por lo tanto, mi recomendación es que se junten los jefes de equipo de desarrollo, de QA, de UAT y si hubiera más, cada cabeza visible del mismo.
Basándome en mi experiencia profesional os puedo poner unos ejemplos de flujos de defectos que han funcionado muy bien en varios de los proyectos en los que he trabajado:
FLUJO 1:
- NUEVO: este estado (también puede ser borrador) podría utilizarse para que el tester edite los datos del mismo antes de pasarlo al siguiente estado donde se bloquearía la edición.
- ABIERTO: El tester abre el bug oficialmente y lo deja en el backlog para pasarlo al equipo de desarrollo o si hay una persona responsable del producto, lo ponga el en el mismo.
- ASIGNADO: El defecto está asignado al desarrollador y es consciente de ello, lo tiene en su backlog personal y empezará a solucionarlo en breve.
- EN DESARROLLO: El defecto se está solucionando por parte del desarrollador.
- TERMINADO DESARROLLO: El defecto está preparado para probarlo, está asignado al tester.
- VALIDADO QA: El defecto ya ha sido validado por QA y puede probarlo UAT.
- VALIDADO UAT: El defecto está validado por QA y listo para cerrarse.
- FINALIZADO O CERRADO: El defecto está solucionado y se cierra para dejarlo a tipo de historial.
FLUJO 2:
- ABIERTO: El defecto está abierto y listo para validar.
- ACEPTADO: El bug es aceptado y pasará al desarrollador.
- EN DESARROLLO: El desarrollador realiza la solución del bug.
- TERMINADO DESARROLLO: El tester puede validarlo.
- OK QA: El tester ha dado su OK y está listo para validarlo.
- OK UAT: El defecto ha pasado la segunda validación y está listo para cerrarse.
- CERRADO: El defecto se cierra y queda como historial.
FLUJO 3:
- ABIERTO: El defecto está abierto y listo para validar.
- EN DESARROLLO: El desarrollador realiza la solución del bug.
- TERMINADO DESARROLLO: El tester puede validarlo.
- OK QA: El tester ha dado su OK y está listo para validarlo.
- CERRADO: El defecto se cierra y queda como historial.
Como veis, cada uno de los flujos es válido para diferentes situaciones y proyectos, dependiendo de las personas que componen los equipos y de la cantidad de pasos que queramos aportar. Lo fundamental es que en estos flujos exista la figura del desarrollador y del tester.
Desde mi punto de vista, depende del proyecto y como tengan en cuenta la Calidad en el mismo, pero el Tester es la única persona que debería de cerrar un defecto, al fin y al cabo, nosotros somos los que nos dedicamos a ello.
0 Comentarios