Respuesta.

El ciclo de vida de un bug es el proceso que sigue cada defecto encontrado: desde su detección hasta su cierre. En TI, el ciclo de vida de un bug se ha formalizado para acelerar el procesamiento de defectos, minimizar riesgos y aumentar la transparencia en el trabajo.

Historia de la cuestión:

Los primeros sistemas de seguimiento de bugs solo permitían registrar errores. A medida que se complicó el software, surgió la necesidad de un seguimiento estructurado de los estados de los bugs y la descripción de todas las etapas de su procesamiento.

Problema:

Sin etapas formales, los defectos pueden perderse, "quedarse atascados", y permanecer abiertos, incluso si han sido solucionados. También pueden surgir malentendidos entre QA y desarrolladores debido a la falta de claridad sobre quién debe hacer qué.

Solución:

La estandarización de las etapas (por ejemplo: New, Open, Assign, In Progress, Fixed, Retest, Closed, Reopened) y la descripción de las acciones en cada etapa ayudan a organizar el proceso de manejo de defectos y hacerlo transparente.

Características clave:

Transiciones estándar entre etapas
Interacción de diferentes roles (QA, Dev, Lead)
Flexibilidad en la configuración del rastreador específico (Jira, Redmine, etc.)

Preguntas engañosas.

¿Se puede cerrar un bug si ha sido reproducido por el tester, pero no por el programador?

No, el bug debe ser aprobado por ambas partes y ser reproducible según los pasos escritos en el informe del bug.

¿Qué hacer si se recibe una respuesta 'Won't Fix' para el bug?

El QA debe aclarar la razón del rechazo. Si la razón está argumentada (baja criticidad, coincidencia con los requisitos), el bug se puede cerrar con un comentario.

¿Está obligado el QA a recrear el bug si el problema vuelve a aparecer después de su cierre?

No, se debe cambiar el estado del bug a "Reopened" y añadir nuevos detalles para la reproducción.

Errores comunes y anti-patrones

Cierre de bugs sin verificar la solución (retest)
Estados excesivos que dificultan el trabajo del equipo
Ignorar la comunicación al cambiar de estados

Ejemplo de la vida real

Caso negativo

La empresa solo utilizaba la funcionalidad básica del registro de bugs. Después de corregir un defecto, el desarrollador lo marcaba como resuelto, el tester no realizaba pruebas nuevamente, y los bugs regresaban al lanzamiento.

Ventajas:

Retroalimentación rápida entre QA y Dev.

Desventajas:

Muchos bugs no corregidos.
Reversiones aparecen en el lanzamiento.

Caso positivo

El equipo implementó un ciclo de vida de bug estándar con retesteo obligatorio y descripción de las razones del cierre antes del lanzamiento.