¿Qué es el Defect Life Cycle?
El defect life cycle (ciclo de vida de defectos o bug life cycle) describe el viaje de un defecto desde el descubrimiento hasta la resolución y cierre. Entender este ciclo asegura tracking eficiente de bugs, comunicación clara y resolución oportuna.
Etapas del Defect Life Cycle
1. New (Nuevo)
Descripción: Defecto reportado por tester, aún no revisado. Acciones: Tester registra defecto con detalles (pasos, screenshots, severidad).
2. Assigned (Asignado)
Descripción: Defecto triaged y asignado a desarrollador. Acciones: Manager/Lead revisa, asigna a desarrollador apropiado.
3. Open (Abierto)
Descripción: Desarrollador comienza a investigar/corregir. Acciones: Desarrollador confirma defecto, inicia trabajo.
4. Fixed (Corregido)
Descripción: Desarrollador completa corrección, listo para verificación. Acciones: Cambios de código implementados, pusheados a entorno de prueba.
5. Retest (Re-testeo)
Descripción: Tester verifica corrección. Acciones: Tester ejecuta casos de prueba para confirmar resolución.
6. Verified/Closed (Verificado/Cerrado)
Descripción: Corrección confirmada, defecto cerrado. Acciones: Tester confirma resolución, actualiza estado a cerrado.
Caminos Alternativos
Rejected (Rechazado)
Descripción: Defecto considerado inválido (no es un bug, funciona según diseño).
Deferred (Diferido)
Descripción: Defecto válido pospuesto a release futuro.
Reopened (Reabierto)
Descripción: Corrección no resolvió issue o introdujo regresión.
Workflow del Defect Life Cycle
[New] → [Assigned] → [Open] → [Fixed] → [Retest] → [Verified] → [Closed]
↓ ↓ ↓ ↑ ↓
[Rejected] [Deferred] [Reopened]──┘ [Reopened]
Atributos de Defecto
| Campo | Descripción | Ejemplo |
|---|---|---|
| ID | Identificador único | BUG-1234 |
| Title | Resumen breve | “Login falla con credenciales válidas” |
| Description | Explicación detallada | Pasos para reproducir, esperado vs actual |
| Severity | Impacto en sistema | Critical, High, Medium, Low |
| Priority | Urgencia de corrección | P1, P2, P3, P4 |
| Status | Estado actual | New, Open, Fixed, Closed |
| Assigned To | Desarrollador responsable | john.doe@company.com |
| Reporter | Quién lo encontró | qa.tester@company.com |
Severity vs Priority
| Severity | Priority | Ejemplo |
|---|---|---|
| Critical | P1 | Procesamiento de pagos roto - corregir inmediatamente |
| High | P1 | Datos de usuario expuestos - riesgo de seguridad |
| Medium | P2 | Búsqueda retorna resultados incorrectos |
| Low | P3 | Issue cosmético de UI |
| Critical | P2 | Crash en caso edge raro (afecta < 1% usuarios) |
| Low | P1 | CEO presenta mañana, corrección cosmética necesaria |
Severity = Impacto técnico Priority = Urgencia del negocio
Mejores Prácticas
1. Escribir Reportes Claros de Defectos
Mal Reporte:
Título: Login no funciona
Descripción: Intenté hacer login y falló.
Buen Reporte:
Título: Login falla con error "Invalid credentials" para usuarios válidos
Descripción:
Al intentar hacer login con credenciales válidas, el sistema retorna
error "Invalid credentials" y no autentica al usuario.
Pasos para Reproducir:
1. Navegar a https://app.example.com/login
2. Ingresar username: test@example.com
3. Ingresar password: ValidPass123!
4. Hacer clic en botón "Login"
Resultado Esperado:
Usuario autenticado y redirigido a dashboard.
Resultado Actual:
Mensaje de error "Invalid credentials" mostrado.
Login falla a pesar de credenciales correctas.
Entorno:
- Browser: Chrome 118.0
- OS: Windows 11
- Servidor: Staging (v2.3.1)
Info Adicional:
- Issue comenzó después de deployment el 2025-10-01
- Afecta todas las cuentas de prueba
- Console muestra error 401 desde /api/auth/login
- Screenshot adjunto: login-error.png
2. Usar Definiciones Consistentes de Severity/Priority
Niveles de Severity:
- Critical (S1): Crash del sistema, pérdida de datos, brecha de seguridad
- High (S2): Feature mayor rota, funcionalidad significativa impactada
- Medium (S3): Feature parcialmente funcionando, workaround disponible
- Low (S4): Issue menor, cosmético, sin impacto funcional
Niveles de Priority:
- P1: Corregir inmediatamente (bloqueador)
- P2: Corregir en sprint actual
- P3: Corregir en siguiente sprint
- P4: Corregir cuando haya tiempo (backlog)
3. Proceso de Defect Triage
Daily Triage Meeting (15-30 min):
- Revisar nuevos defectos
- Validar reproducibilidad
- Asignar severity y priority
- Asignar a desarrollador
- Establecer fecha objetivo de resolución
4. Trackear Métricas de Defectos
| Métrica | Descripción |
|---|---|
| Open Defects | Total de bugs sin resolver |
| Defect Age | Días desde reporte |
| Mean Time to Resolve | Tiempo promedio de corrección |
| Reopened Rate | % de defectos reabiertos |
| Defect Density | Bugs por feature/módulo |
Errores Comunes
❌ Descripciones vagas: “No funciona” - proporcionar pasos específicos
❌ Sin reproducibilidad: No se puede reproducir = no se puede corregir
❌ Severity incorrecta: “Typo en footer” marcado como Critical
❌ Defectos duplicados: Verificar bugs existentes antes de reportar
❌ Sin regression testing: Corrección verificada pero features relacionadas no testeadas
Conclusión
Un defect life cycle bien definido asegura que los bugs se rastreen sistemáticamente desde el descubrimiento hasta el cierre. Procesos claros, comunicación consistente y seguimiento disciplinado resultan en resolución más rápida, mejor calidad y mejor colaboración del equipo.
Puntos Clave:
- Estandarizar workflow: Definir etapas y transiciones claras
- Escribir reportes detallados: Pasos, screenshots, detalles de entorno
- Distinguir severity vs priority: Impacto técnico vs urgencia de negocio
- Triage regular: Revisión diaria de nuevos defectos
- Trackear métricas: Monitorear tiempo de resolución, densidad de defectos
- Conducir RCA: Aprender de defectos críticos para prevenir recurrencia