5 min lectura • Guide 414 of 877
Proceso de Triage de Bugs
El triage de bugs determina qué bugs corregir y cuándo. Un buen triage prioriza basándose en impacto, no en quién gritó más fuerte. Un mal triage deja que bugs críticos languidezcan mientras issues triviales se corrigen. Esta guía cubre triage de bugs efectivo para equipos de desarrollo.
Niveles de Severidad
La clasificación consistente de severidad elimina ambigüedad y asegura respuestas apropiadas.
| Severidad | Descripción | Respuesta |
|---|---|---|
| Crítica | Sistema caído, pérdida de datos | Inmediata |
| Alta | Feature mayor rota | Este sprint |
| Media | Feature degradada | Pronto |
| Baja | Issue menor | Cuando haya tiempo |
Proceso de Triage
Manejando Bugs
El proceso estructurado asegura que cada bug reciba la evaluación correcta y llegue al destino apropiado.
PROCESO DE TRIAGE DE BUGS
═════════════════════════
PASO 1: VALIDAR
─────────────────────────────────────
¿Es un bug real?
├── ¿Puede reproducirse?
├── ¿Es comportamiento esperado?
├── ¿Es duplicado?
├── ¿Sigue siendo relevante?
├── ¿Suficiente info para investigar?
└── Filtrar ruido
Acciones:
├── Válido → Continuar triage
├── Duplicado → Cerrar, vincular original
├── No es bug → Cerrar con explicación
├── Necesita info → Solicitar detalles
└── Disposición clara
PASO 2: EVALUAR SEVERIDAD
─────────────────────────────────────
CRÍTICO:
├── Sistema inutilizable
├── Pérdida o corrupción de datos
├── Vulnerabilidad de seguridad
├── Todos los usuarios afectados
└── Dejar todo
ALTO:
├── Feature mayor rota
├── Usuarios significativos afectados
├── No existe workaround
├── Impacto de negocio significativo
└── Fix prioritario
MEDIO:
├── Feature degradada
├── Workaround existe
├── Algunos usuarios afectados
├── Molesto pero manejable
└── Programar pronto
BAJO:
├── Issue cosmético
├── Caso edge raro
├── Inconveniencia menor
├── Bueno arreglar algún día
└── Backlog
PASO 3: PRIORIZAR
─────────────────────────────────────
Factores:
├── Severidad (de arriba)
├── Impacto usuario (cuántos afectados)
├── Impacto negocio (revenue, reputación)
├── Esfuerzo para arreglar (¿quick win?)
├── Dependencias
└── Evaluación balanceada
PASO 4: ASIGNAR
─────────────────────────────────────
├── Añadir al sprint/backlog apropiado
├── Asignar a desarrollador (opcional)
├── Establecer timeline objetivo
├── Comunicar al reporter
└── Rastreado y visible
Reunión de Triage
Ejecutando Triage
Las reuniones de triage efectivas son cortas, enfocadas y producen decisiones claras.
REUNIÓN DE TRIAGE
═════════════════
FRECUENCIA:
─────────────────────────────────────
├── Diario: Alto volumen de bugs
├── 2-3x/semana: Volumen medio
├── Semanal: Bajo volumen
├── Según necesidad: Bugs críticos
└── Ritmo regular
PARTICIPANTES:
─────────────────────────────────────
├── Product Owner: Prioridad de negocio
├── Tech Lead: Evaluación técnica
├── QA Lead: Reproducción y severidad
├── Soporte (opcional): Impacto usuario
└── Mantener grupo pequeño
DURACIÓN:
─────────────────────────────────────
├── 15-30 minutos máximo
├── Decisiones rápidas
├── Investigación fuera de reunión
└── No resolver bugs en reunión
FORMATO:
─────────────────────────────────────
├── Revisar cola de bugs nuevos
├── Por cada bug: validar, severidad, acción
├── Asignar responsables
├── Actualizar estado
└── Comunicar resultados
Herramientas en GitScrum
Configuración para Triage
GitScrum proporciona funcionalidades específicas para facilitar el proceso de triage.
SETUP DE GITSCRUM PARA TRIAGE
═════════════════════════════
ETIQUETAS:
├── bug:critico (rojo)
├── bug:alto (naranja)
├── bug:medio (amarillo)
├── bug:bajo (verde)
├── needs-triage (gris)
└── needs-info (azul)
COLUMNAS DE TABLERO:
├── Nuevo (sin revisar)
├── Triaged (pendiente asignación)
├── En Progreso
├── En Revisión
└── Cerrado
FILTROS GUARDADOS:
├── "Bugs Sin Triage"
├── "Bugs Críticos Abiertos"
├── "Mis Bugs Asignados"
├── "Bugs Esta Semana"
└── Acceso rápido
Métricas de Triage
KPIs para Seguimiento
Las métricas ayudan a identificar cuellos de botella y mejorar el proceso continuamente.
MÉTRICAS DE TRIAGE
══════════════════
Velocidad:
├── Tiempo promedio sin triage
├── Bugs triaged por sesión
├── Backlog de bugs pendientes
└── Meta: < 24h sin triage
Calidad:
├── Bugs reabiertos
├── Escalaciones incorrectas
├── Bugs reasignados
└── Meta: < 5% correcciones
Tendencias:
├── Bugs reportados por semana
├── Bugs cerrados por semana
├── Ratio entrada/salida
└── Meta: Salida >= Entrada
Mejores Prácticas
Para Triage Efectivo
- Hacer triage regularmente — No dejar acumular
- Mantener sesiones cortas — 15-30 minutos máximo
- Decidir rápido — Evitar parálisis de análisis
- Documentar decisiones — Para referencia futura
- Comunicar resultados — Transparencia con reporters
Anti-Patrones
EVITAR ESTOS:
✗ Triage esporádico
✗ Una persona decide todo
✗ Resolver bugs en reunión de triage
✗ Todos los bugs son "críticos"
✗ No comunicar decisiones
✗ Ignorar bugs viejos
✗ Análisis excesivo