Hoy voy a revisar el ciclo de la vida de los defectos. Las erratas o incidencias son uno de los puntos más importantes dentro del proceso de Testing y el aseguramiento de la calidad. Por ello es relevante realizar un correcto flujo del ciclo de vida de los defectos. ¿Conoces cuáles son los estados por lo que puede pasar un defecto? En función de las circunstancias y características del mismo, un defecto puede tomar una trayectoria u otra. A continuación, te cuento cuáles son esos estados y algunos detalles que debes tener en cuenta sobre cada uno.
Índice de contenidos
Estados del ciclo de vida de los defectos
En primer lugar, te muestro este diagrama, en el que se pueden diferenciar los distintos estados más utilizados en la gestión de defectos y los flujos que suelen realizar para actualizar su estado hasta llegar a un estado final. Aunque, en todo momento, en función de la empresa u organización, puedes adaptar estas iteraciones en función de las necesidades.
A continuación, voy a revisar cada uno de los estados y sus características, según mi experiencia en testing.
Abierto, el estado original
Una vez localizado una falla o errata, es necesario registrarla siempre como defecto dentro de la herramienta utilizada internamente en la empresa u organización. Es frecuente, registrar una serie de valores asociados. Por ejemplo: motivo del defecto, donde se ha localizado, el número de casos bloqueados a los que afecta dicha incidencia, evidencias registradas en la ejecución, datos usados, prioridad y criticidad. Para más información, consulta el siguiente post: Testing: La importancia del registro de defectos y de su corrección.
En corrección, estado del ciclo de vida de los defectos
Una vez dado de alta el defecto, se debe asignar al equipo o persona responsable de la resolución del mismo. El defecto estará en este estado hasta que se marque en Solucionado o Rechazado (o Cancelado). En el propio defecto se debe almacenar la fecha de alta y la fecha en la que se cambia su estado a «solucionado o rechazado». De esta forma, se puede hacer un seguimiento de los tiempos de los distintos equipos. Es vital, tener una política ágil de resolución de defectos que permita avanzar rápidamente con el nivel de pruebas, y en definitiva, con la entrega del producto.
Re-asignado (casi un estado)
En algunas ocasiones, es necesario cambiar la asignación del defecto y volver a ponerlo en corrección. No siempre se considera como un estado en sí, pero puede pasar por este estado transitorio mientras la nueva persona asignada empieza con la revisión del defecto. Normalmente, porque no se ha identificado en una primera ocasión, de forma correcta quién o qué equipo debe resolver el defecto. Aunque no es lo frecuente, también forma parte del ciclo de vida de los defectos y se debe tener en cuenta para el analisis de los datos.
Re-abierto
Otras veces, tal como el defecto está solucionado y vas a verificar su correcta resolución, te encuentras con que el defecto sigue existiendo o no está correctamente aplicada la corrección. Por tanto, volvemos a poner el defecto «en corrección». Es importante medir el número de reaperturas para saber cuan eficientes son los equipos de desarrollo, pues no asegurar la correcta resolución de incidencias, provoca dinámicas de re-trabajo que ocasionan perdidas de tiempo. En este sentido, es relevante formar a los equipos de desarrollo en la importancia de asegurar la correcta solución aplicada, como veremos en el siguiente punto.
Puedes consultar algunas métricas interesantes en el post: Los 10 KPI más utilizados en Testing.
Resuelto o Solucionado
Una vez que el desarrollador ha aplicado la corrección y ha verificado que la solución aplicada es la adecuada (esto último, qué a veces se olvida) debe marcar el defecto como Solucionado. La forma más correcta de evidenciar esa solución (como comentaba hace unos segundos) es aportando una serie de datos a la corrección del defecto:
- El motivo del KO: Error de maquetación, literales, error de regresión, error de software, error de datos, etc. En función de la organización se definen los que serán necesarios.
- El sistema donde se presenta el KO: Si dentro de la organización tenemos impacto entre distintas áreas, se debe determinar quién provoca el KO.
- Explicación de la solución aplicada.
- Evidencias de la resolución: Documentos o capturas de pantalla donde se visualice la comprobación del resultado satisfactorio.
Rechazado, estado del ciclo de vida de los defectos
Hay ocasiones que el defecto detectado es un falso positivo. Realmente no es un defecto, aunque a simple vista parezca que sí. Esto ocurre, por ejemplo, porque no está especificado en los requisitos o hay alguna ambigüedad en los requerimientos. En otras palabras, no es un defecto que cumpla con la documentación formal. En otras ocasiones, no se entiende el flujo de la prueba y no se ejecuta el caso de forma correcta, con lo que el «supuesto KO» no aplica. Este estado suele ser un estado final.
Cerrado
Una vez se verifica que el defecto se ha resuelto, desde el Equipo de Testing, se debe marcar como cerrado. De igual forma, como en el estado «Solucionado», se deben aportar evidencias de que la solución se ha aplicado de forma correcta y ya no existe el defecto sobre el software.
Actualización de estados "on the fly", respetando el ciclo de vida de los defectos
Es primordial que la actualización del estado de los defectos se realice sobre la marcha. Tanto si utilizamos un simple excel, como si utilizamos cualquier herramienta para este cometido: mantis o Xray, por ejemplo. Por ello, se debe evangelizar a los equipos (desde los desarrolladores, hasta los líderes) para que la foto del listado de defectos sea la real en cualquier momento que se consulte.
En este sentido, se debe pasar todos los estados por los que verdaderamente pase un defecto. En muchas ocasiones, estas tareas se consideran como una perdida de tiempo. Sin embargo, es importante registrar la información para obtener datos reales del ciclo de vida de los defectos. Si se hace de forma correcta, podemos analizar los puntos débiles de los procesos de desarrollo y con ello hacer una propuesta de las mejoras a implementar en nuestros equipos, y en definitiva en la empresa u organización.
Herramienta con sistema de notificaciones
En último lugar, me gustaría destacar la importancia de utilizar una herramienta que ofrezca la posibilidad de recibir notificaciones. De esta forma, podrás estar al tanto de cuando se te asigna un nuevo defecto, si eres desarrollador. O se te informará de la resolución de defectos si eres un tester. Si, además, te configuras un buen sistema de filtros en el correo electrónico, tendrás prácticamente un «secretario» que te avisará de los próximos pasos a seguir en la resolución y verificación de corrección de defectos.
Conclusión: Respeta el ciclo de vida de los defectos
Se debe realizar una correcta gestión de incidencias, respetando el ciclo de vida de los defectos. Gracias a ello, podemos implantar metodologías mejora continua en nuestra organización que nos permitan optimizar nuestros tiempos y resultados. En este sentido, es vital una formación de los equipos para que asimilen la importancia de seguir procedimientos de documentación de defectos, aunque sea de forma ágil.
¿Tu cómo efectúas la gestión de defectos? ¿Hay, en tu organización, un flujo particular en el ciclo de vida de los defectos? Déjame tu comentario y hablamos sobre el tema. O si lo prefieres suscríbete al blog.
Quizás te puede interesar
