Lo que en principio puede parecer una afirmación bastante lógica no siempre es así. En muchas ocasiones son los propios desarrolladores o jefes de proyectos los que, “alegremente”, cierran defectos que no han sido verificados por testing. Un defecto marcado como “Arreglado” (Fixed-Ready to test), debe de ser siempre verificado por el equipo de testing. Si el defecto es “rechazado” por no ser considerado un defecto, el tester deberá de pedir más información sobre el defecto para así realmente verificar que no se trata de un defecto y estar de acuerdo con la decisión. Si el defecto es rechazado por ser considerado “duplicado”, el tester deberá verificar que efectivamente el defecto existe y que efectivamente está duplicado. En muchos proyectos los desarrolladores tienden a esconder los defectos refugiándose en que el defecto está duplicado.
El tester que normalmente encuentra un defecto lo retesteará, pero si el defecto viene de una persona ajena al equipo de pruebas entonces el tester deberá de evaluar e intentar reproducir el defecto. Un defecto no debe ser cerrado si no ha sido revisado por el equipo de testing.
¿Como podemos evitar esta situación? Es importante definir apropiadamente el ciclo de vida de un defecto. Debe de ser añadido como un proceso más a nuestra estrategia de pruebas. Por ejemplo, todo defecto, como mínimo, pasa por los siguientes estados:
- Abierto
- Asignado
- Arreglado
- Listo para ser testeado
- Cerrado
A estos estados debemos añadir unos sub-estados:
- Rechazado, una vez se ha encontrado el defecto es revisado. Si no se considera un defecto, pasaría al estado de “Rechazado”.
- Reabierto, este sub-estado ocurre cuando se testea un defecto y todavía no está debidamente arreglado.
Como había comentado anteriormente, estos estados son sólo un ejemplo…dependiendo de las necesidades de vuestra empresa este ciclo de vida variará. Adjunto un ejemplo de los diferentes estados en los que puede estar un defecto:
Me gustaría destacar el trabajo ( muchas veces arduo) que el equipo de calidad tiene que hacer para que el equipo de desarrollo CONOZCA el ciclo de vida de un defecto. Ahi van a algunos ejemplos:
1. Defecto cerrado como “No Defecto” con el siguiente comentario: “arreglado con la version del software x” o “arreglado en intro time”
2. Defecto cerrado como “No reproducible” con el siguiente comentario: “Imposible reproducir con la ultima versión de software”
En mi empresa resolvemos ese problema teniendo un campo que se llama “Verified” o verificado. Es un combo box que dice si o no. El estado de este combo box por defecto es verified = no, entonces a lo largo del ciclo de vida del defecto permanece así. Una vez que el defecto pasa a estado FIXED el tester debe comprobar que no sucede más ese problema, de ser así se pasa a verified = yes y sino se reabre el defecto pasando a estado REOPEN.
Afinando un poco más y si el DTS lo permite, podemos limitar los permisos para editar el campo “Status” por grupo de usuarios (QA, DEV) y por el propio estado actual. Así, únicamente un usuario que esté en el grupo QA podría cerrar un defecto y además, en determinados estados de la transición podrían lanzarse por ejemplo avisos al desarrollador y/o reporter.