El ciclo de vida de defectos es el proceso estructurado que gobierna cómo cada bug reportado avanza desde el descubrimiento inicial hasta el cierre final. Según investigación citada por SmartBear, los equipos que siguen un proceso formal de gestión de defectos resuelven bugs hasta un 45% más rápido que los equipos con tracking ad-hoc. El currículo ISTQB Foundation Level dedica una sección completa a la gestión de defectos, definiéndola como una de las competencias centrales de cualquier profesional QA certificado. Un lifecycle bien definido garantiza que ningún bug se pierda en el backlog, que la severidad y prioridad se asignen correctamente, y que la verificación siempre se realice antes del cierre.
“Uno de los errores más comunes que veo en equipos de QA es saltarse la etapa de Retest — cerrar un bug antes de verificar la corrección. Suena básico, pero esto causa escapes de regresión en funcionalidades críticas. El ciclo de vida del defecto no es burocracia; es el proceso mínimo que mantiene visible la calidad.” — Yuri Kan, Senior QA Lead
TL;DR — El defect life cycle tiene 6 etapas: New → Assigned → Open → Fixed → Retest → Closed. Los equipos con proceso formal resuelven bugs hasta 45% más rápido (SmartBear). Severidad = impacto técnico; Prioridad = urgencia de negocio. Siempre verificar correcciones — saltarse Retest causa regresiones.
¿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. El Glosario ISTQB define un defecto como “una imperfección o deficiencia en un producto de trabajo que no cumple sus requisitos o especificaciones”.
Dominar el ciclo de vida de defectos es fundamental para todo ingeniero de QA. Complementa este conocimiento aprendiendo a crear reportes de bugs que los desarrolladores aman. Integrar el tracking de defectos con testing continuo en DevOps acelera la resolución. Una estrategia de automatización efectiva reduce la densidad de defectos desde el inicio.
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
Preguntas Frecuentes
¿Cuáles son las principales etapas del ciclo de vida de defectos? Las etapas principales son: New (bug reportado), Assigned (asignado a desarrollador), Open (desarrollador trabajando), Fixed (corrección implementada), Retest (tester verifica), Closed (corrección confirmada). Caminos alternativos incluyen Rejected, Deferred y Reopened.
¿Cuál es la diferencia entre severidad y prioridad de un defecto? La severidad es el impacto técnico del defecto (Critical/High/Medium/Low). La prioridad es la urgencia de negocio para corregirlo (P1-P4). Un bug cosmético puede ser P1 si el CEO hace una demo mañana; un crash crítico que afecta al 0.1% puede ser P2.
¿Qué herramientas se usan para tracking de defectos? Herramientas populares incluyen Jira (estándar enterprise), GitHub Issues (integrado con código), Azure DevOps (ecosistema Microsoft), Linear (moderno y rápido) y Bugzilla (open-source).
¿Cómo define el ISTQB un defecto? Según el Glosario ISTQB, un defecto es una imperfección o deficiencia en un producto de trabajo que no cumple sus requisitos. El ISTQB distingue entre defectos (fallas en el código) y fallos (comportamiento incorrecto observable).
Fuentes: Glosario ISTQB · SmartBear
Ver También
- Reportes de Bugs que los Desarrolladores Aman - Escribir reportes efectivos de defectos
- Testing Continuo en DevOps - Integrar tracking de defectos en CI/CD
- Estrategia de Automatización de Pruebas - Reducir defectos con automatización
- Cypress en Profundidad - Detectar defectos temprano con pruebas E2E
- BDD: De Requisitos a Automatización - Prevenir defectos con especificaciones claras
