Ciclo de Vida de un Incidente

El flujo más típico de los incidentes (o bugs) es el que se representa en el siguiente esquema. Considera que en rojo aparecen las acciones que hace el tester y en azul aparecen las acciones que hace el desarrollador. Luego verás en las cajas las distintas situaciones en las que se encuentra un bug, las cuales son:

• Nuevo: un bug recién creado por un tester.
• Asignado: un bug que un desarrollador decidió corregir.
• Resuelto: un bug que un desarrollador corrigió y está esperando que un tester verifique que quedó correctamente corregido.
• Cerrado: un bug que ya fue resuelto y verificado por un tester, con lo cual ya no hay más para hacer.

Puede pasar que el desarrollador no entienda el incidente y necesite más información. Por eso también veremos que hay bugs que aparecerán como “Se necesita más información”.

Para evitar esto ver el repartido “Escribiendo Reportes de Error Efectivos”. Si llegase a suceder, el tester debe proveer más información y así el desarrollador podrá corregirlo.

También hay situaciones en las que un tester reporta un bug que quizá no era un bug, sino que el tester había entendido mal cómo debería funcionar el software, esperaba otra cosa, y por eso reportó el bug. En ese caso el desarrollador pasará el bug a “Resuelto” con una nota indicando que eso no era un error. El tester ahí deberá aceptar el comentario y cerrar el incidente, a menos que considere que sí es un error, con lo cual podría reabrirlo y continuar “discutiendo” con el desarrollador.

Realmente todos estos tipos de interacción serían muy complicados de seguir si no fuese porque contamos con herramientas que nos ayudan a ordenar nuestro trabajo.