El Ciclo de Vida del Bug
Cada bug sigue un ciclo de vida desde el descubrimiento hasta la resolucion. Entender este ciclo te ayuda a rastrear bugs efectivamente y asegurar que nada se escape.
Estados Estandar
New
Bug reportado por QA. No ha sido revisado ni asignado.
Open (Assigned)
Bug revisado, aceptado como valido y asignado a un desarrollador.
In Progress
Desarrollador esta trabajando activamente en la correccion.
Fixed (Ready for QA)
Desarrollador implemento la correccion y la desplego al entorno de test.
Verified (QA Passed)
QA confirmo que la correccion resuelve el issue original.
Closed
Bug resuelto y correccion desplegada a produccion.
Reopened
Verificacion de QA fallo — la correccion no resuelve el issue o el bug reaparece.
Estados Especiales
Duplicate
El mismo bug ya fue reportado. Vincular al original.
Cannot Reproduce
El bug no puede recrearse siguiendo los pasos reportados.
Won’t Fix
El bug es valido pero se decide conscientemente no corregirlo.
Razones: Costo excede impacto, feature se deprecara, riesgo de nuevos bugs.
Deferred
Bug valido pero correccion pospuesta a release futuro.
Invalid (Not a Bug)
El comportamiento reportado es por diseno.
Flujo del Ciclo de Vida
Roles en Cada Etapa
| Etapa | Rol QA | Rol Developer | Rol PM |
|---|---|---|---|
| New | Crear reporte detallado | — | — |
| Triage | Explicar, clarificar | Evaluar complejidad | Priorizar |
| Open | Monitorear | Aceptar asignacion | Rastrear progreso |
| In Progress | Disponible para preguntas | Implementar fix | Remover bloqueantes |
| Fixed | Verificar fix | Explicar cambios | — |
| Verified | Confirmar resolucion | — | Planear despliegue |
| Closed | Actualizar test cases | — | Reportar a stakeholders |
| Reopened | Explicar por que fallo el fix | Re-analizar | Ajustar prioridades |
Ejercicio: Rastrea Estos Viajes de Bugs
Para cada escenario, describe la ruta completa del ciclo de vida.
- QA reporta un crash. Developer descubre que es causado por el mismo issue que bug #234 que ya se esta corrigiendo.
- QA reporta carga lenta. Developer descubre que solo pasa con una extension de browser especifica.
- QA reporta issue de alineacion UI. PO dice que corregirlo retrasaria el release 2 dias.
- QA reporta bug de formato de datos. Developer lo corrige. QA verifica que el issue original esta corregido pero descubre que el fix introdujo un nuevo bug.
Solucion
Escenario 1: New → Duplicate (vinculado a #234). Cerrar con nota.
Escenario 2: New → Cannot Reproduce → (QA provee info de extension) → Reopened → Open → In Progress → Fixed → Verified → Closed. O: New → Invalid (si la extension no es soportada).
Escenario 3: New → Open → Deferred (target: release v3.2).
Escenario 4: New → Open → In Progress → Fixed → Reopened (QA nota: “Issue original corregido, pero fix introdujo regresion”). El developer recibe el bug reopened Y #567 se crea como bug nuevo separado.
Mejores Practicas
- Siempre explicar cambios de estado — nunca cambiar estado sin comentario
- Vincular bugs relacionados — duplicados, regresiones y issues relacionados
- Re-verificar despues de reopen — verificar tanto el issue original como la regresion
- Rastrear bugs deferred — revisar al inicio de cada planificacion de release
- Cerrar pronto — no dejar bugs verificados colgando
Puntos Clave
- Ciclo de vida: New → Open → In Progress → Fixed → Verified → Closed
- Rutas especiales: Duplicate, Cannot Reproduce, Won’t Fix, Deferred, Invalid
- Bugs reopened regresan a In Progress — siempre explicar por que fallo el fix
- QA verifica fixes; Product Owner decide prioridad y aplazamiento
- Cada cambio de estado debe incluir comentario explicativo