Cómo Usar GitScrum para Tracking y Resolución de Bugs
Rastrea, prioriza y resuelve bugs efectivamente usando GitScrum. Crea flujos claros desde descubrimiento de bug hasta fix verificado.
6 min de lectura
El tracking efectivo de bugs requiere más que una simple lista—necesita flujos de triage, sistemas de prioridad y rutas de resolución claras. Los flujos personalizables, etiquetas de severidad e integración Git de GitScrum crean un sistema completo de tracking de bugs que conecta issues reportados con fixes de código y resoluciones verificadas.
Niveles de Severidad de Bugs
| Severidad | Impacto | Tiempo de Respuesta | Ejemplos |
|---|---|---|---|
| Crítico | Sistema caído, pérdida de datos | Inmediato | Login roto, pago falla |
| Alto | Feature mayor rota | 24 horas | Export falla, dashboard vacío |
| Medio | Feature degradada | 1 semana | Performance lento, glitch UI |
| Bajo | Issue menor | Backlog | Typo, issue cosmético |
Flujo de Tracking de Bugs
CICLO DE VIDA DEL BUG EN GITSCRUM
1. NUEVO BUG REPORTADO
┌─────────────────────────────────────────────────┐
│ Fuentes: │
│ ├── Tickets de soporte al cliente │
│ ├── Testing interno │
│ ├── Monitoreo automatizado │
│ ├── Feedback de usuarios │
│ └── Testing de QA │
│ │
│ Estado Inicial: [Nuevo] │
└─────────────────────────────────────────────────┘
│
▼
2. TRIAGE (dentro de 24h)
┌─────────────────────────────────────────────────┐
│ Acciones: │
│ ├── Verificar reproducibilidad │
│ ├── Asignar nivel de severidad │
│ ├── Verificar duplicados │
│ ├── Agregar etiquetas y asignado │
│ └── Establecer prioridad │
│ │
│ Estado: [Triageado] │
└─────────────────────────────────────────────────┘
│
▼
3. INVESTIGACIÓN
┌─────────────────────────────────────────────────┐
│ Acciones del desarrollador: │
│ ├── Reproducir localmente │
│ ├── Identificar causa raíz │
│ ├── Estimar esfuerzo de fix │
│ └── Documentar hallazgos │
│ │
│ Estado: [En Progreso] │
└─────────────────────────────────────────────────┘
│
▼
4. IMPLEMENTACIÓN DE FIX
┌─────────────────────────────────────────────────┐
│ ├── Fix de código con tests │
│ ├── Code review │
│ ├── Merge a main │
│ └── Deploy a staging │
│ │
│ Estado: [En Revisión] │
└─────────────────────────────────────────────────┘
│
▼
5. VERIFICACIÓN
┌─────────────────────────────────────────────────┐
│ ├── QA verifica fix en staging │
│ ├── Reportador original confirma │
│ └── Deploy a producción │
│ │
│ Estado: [Verificado] │
└─────────────────────────────────────────────────┘
│
▼
6. CERRADO
┌─────────────────────────────────────────────────┐
│ ├── Notificar stakeholders │
│ ├── Actualizar documentación si es necesario │
│ └── Considerar medidas de prevención │
│ │
│ Estado: [Cerrado] │
└─────────────────────────────────────────────────┘
Plantilla de Reporte de Bug
ESTRUCTURA DE REPORTE DE BUG
┌─────────────────────────────────────────────────┐
│ Título: [Componente] Descripción breve │
│ Ejemplo: [Checkout] Pago falla para PayPal │
│ │
│ Etiquetas: [bug] [severity-high] [payments] │
│ │
│ SEVERIDAD: Alta │
│ PRIORIDAD: P1 │
│ REPORTADOR: @username │
│ AMBIENTE: Producción │
│ │
│ RESUMEN: │
│ Una oración describiendo el issue. │
│ │
│ PASOS PARA REPRODUCIR: │
│ 1. Navegar a checkout │
│ 2. Seleccionar PayPal como método de pago │
│ 3. Click "Completar Orden" │
│ 4. Observar error │
│ │
│ COMPORTAMIENTO ESPERADO: │
│ Orden completa y confirmación se muestra. │
│ │
│ COMPORTAMIENTO ACTUAL: │
│ Mensaje error: "Procesamiento de pago falló" │
│ Orden no creada, usuario atascado en checkout │
│ │
│ FRECUENCIA: │
│ 100% reproducible │
│ │
│ USUARIOS AFECTADOS: │
│ Todos los usuarios seleccionando PayPal (~15%) │
│ │
│ NAVEGADOR/DISPOSITIVO: │
│ Chrome 120, macOS 14 │
│ (confirmado también en Safari, Firefox) │
│ │
│ LOGS DE ERROR: │
│
│
│ PayPalAPIError: Invalid token format │
│ at processPayment (payment.service.ts:145) │
│ `` │
│ │
│ CAPTURAS/VIDEO: │
│ [adjunto] │
│ │
│ WORKAROUND: │
│ Usuarios pueden usar tarjeta de crédito │
└─────────────────────────────────────────────────┘
### Configuración del Tablero de Bugs
TABLERO DE TRACKING DE BUGS
Columnas: ┌────────┬─────────┬───────────┬────────┬──────────┐ │ Nuevo │Triageado│En Progreso│Revisión│Verificado│ ├────────┼─────────┼───────────┼────────┼──────────┤ │ [BUG] │ [BUG] │ [BUG] │ [BUG] │ [BUG] │ │ [BUG] │ [BUG] │ [BUG] │ │ │ │ [BUG] │ │ │ │ │ └────────┴─────────┴───────────┴────────┴──────────┘
Swimlanes por Severidad: ┌─────────────────────────────────────────────────┐ │ 🔴 Crítico (0 en Nuevo - objetivo) │ │ ├── BUG-234: Timeout de sistema... │ ├─────────────────────────────────────────────────┤ │ 🟠 Alto (responder < 24h) │ │ ├── BUG-456: Pago falla... │ │ ├── BUG-457: Export roto... │ ├─────────────────────────────────────────────────┤ │ 🟡 Medio (responder < 1 semana) │ │ ├── BUG-567: Búsqueda lenta... │ ├─────────────────────────────────────────────────┤ │ 🟢 Bajo (backlog) │ │ ├── BUG-678: Typo en... │ └─────────────────────────────────────────────────┘
Etiquetas: ├── [severity-critical] ├── [severity-high] ├── [severity-medium] ├── [severity-low] ├── [regression] ├── [customer-reported] └── [needs-info]
### Dashboard de Métricas de Bugs
MÉTRICAS DE SALUD DE BUGS
ESTADO ACTUAL: ┌─────────────────────────────────────────────────┐ │ Bugs Abiertos por Severidad: │ │ Críticos: 0 (objetivo: 0) ✓ │ │ Altos: 4 (objetivo: <5) ✓ │ │ Medios: 18 (objetivo: <25) ✓ │ │ Bajos: 45 (objetivo: <100) ✓ │ └─────────────────────────────────────────────────┘
VELOCIDAD DE RESOLUCIÓN: ┌─────────────────────────────────────────────────┐ │ Severidad Tiempo Prom SLA Estado │ │ ────────────────────────────────────────── │ │ Crítico 4 horas 8h ✓ Cumpliendo │ │ Alto 2 días 3d ✓ Cumpliendo │ │ Medio 8 días 14d ✓ Cumpliendo │ │ Bajo 21 días 30d ✓ Cumpliendo │ └─────────────────────────────────────────────────┘
TENDENCIAS: ┌─────────────────────────────────────────────────┐ │ Esta Semana: │ │ Nuevos bugs: 12 │ │ Bugs arreglados: 15 │ │ Cambio neto: -3 (mejorando) │ └─────────────────────────────────────────────────┘
## Mejores Prácticas
1. **Triage rápido** dentro de 24 horas
2. **Reportes de bug completos** con toda la info necesaria
3. **Etiquetas consistentes** para priorización
4. **Verificación obligatoria** antes de cerrar
5. **Métricas de tracking** para mejora continua
6. **Root cause analysis** para bugs recurrentes
7. **Celebrar zero bugs críticos** como logro de equipo
## Anti-Patrones
✗ Bugs sin información de reproducción ✗ Sin proceso de triage ✗ Severidades no consistentes ✗ Cerrar sin verificación ✗ Ignorar bugs de baja severidad indefinidamente ✗ No rastrear métricas de bugs
``