6 min lectura • Guide 632 of 877
Creando Reportes de Bugs Efectivos
Los reportes de bugs efectivos contienen la información que los desarrolladores necesitan para reproducir, entender y corregir problemas rápidamente. Las funcionalidades de bug tracking de GitScrum ayudan a los equipos a estandarizar reportes de bugs, asegurar captura consistente de información y agilizar el camino desde el reporte hasta la resolución.
Estructura del Reporte de Bug
Componentes Esenciales
TEMPLATE DE REPORTE DE BUG:
┌─────────────────────────────────────────────────────────────┐
│ TÍTULO: [Acción] causa [Problema] en [Área] │
│ Ejemplo: "Hacer clic en 'Guardar' causa pérdida de datos │
│ en perfil" │
├─────────────────────────────────────────────────────────────┤
│ │
│ SEVERIDAD: 🔴 Crítico / 🟠 Alto / 🟡 Medio / 🟢 Bajo │
│ │
│ ENTORNO: │
│ • Navegador/Dispositivo: Chrome 120, Windows 11 │
│ • Versión de App: 2.4.1 │
│ • Tipo de Cuenta: Usuario premium │
│ │
│ PASOS PARA REPRODUCIR: │
│ 1. Navegar a Settings > Profile │
│ 2. Cambiar nombre de display a "Test User" │
│ 3. Hacer clic en botón "Guardar" │
│ 4. Observar mensaje de error │
│ │
│ COMPORTAMIENTO ESPERADO: │
│ El perfil debería guardarse y mostrar mensaje de éxito │
│ │
│ COMPORTAMIENTO ACTUAL: │
│ Aparece error "Guardado falló", los cambios se pierden │
│ │
│ ADJUNTOS: │
│ • [Screenshot del error] │
│ • [Log de consola] │
│ • [Captura de network request] │
└─────────────────────────────────────────────────────────────┘
Guías de Severidad
NIVELES DE SEVERIDAD DE BUG:
┌─────────────────────────────────────────────────────────────┐
│ NIVEL │ CRITERIO │ RESPUESTA │
├───────────┼─────────────────────────────┼───────────────────┤
│ 🔴 Crítico│ • App inutilizable │ Corregir inmediato│
│ │ • Pérdida de datos │ Release mismo día │
│ │ • Vulnerabilidad seguridad │ │
├───────────┼─────────────────────────────┼───────────────────┤
│ 🟠 Alto │ • Feature mayor rota │ Corregir este │
│ │ • Workaround difícil │ sprint │
│ │ • Muchos usuarios afectados │ Cola de prioridad │
├───────────┼─────────────────────────────┼───────────────────┤
│ 🟡 Medio │ • Feature degradada │ Programar en │
│ │ • Existe workaround │ sprint próximo │
│ │ • Algunos usuarios afectados│ │
├───────────┼─────────────────────────────┼───────────────────┤
│ 🟢 Bajo │ • Inconveniencia menor │ Backlog │
│ │ • Problema cosmético │ Corregir cuando │
│ │ • Ocurrencia rara │ sea posible │
└─────────────────────────────────────────────────────────────┘
Reportes de Bug de Calidad
Pasos de Reproducción
BUENOS PASOS DE REPRODUCCIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ✅ BUENO: │
│ 1. Iniciar sesión como usuario "test@example.com" │
│ 2. Navegar a Dashboard > Reportes │
│ 3. Seleccionar rango de fechas: 1 Ene - 31 Ene, 2024 │
│ 4. Hacer clic en "Generar Reporte" │
│ 5. Esperar que cargue el reporte (aprox 5 segundos) │
│ 6. Hacer clic en "Exportar PDF" │
│ Resultado: Aparece error "Exportación falló" │
│ │
│ ❌ MALO: │
│ "La exportación PDF no funciona" │
│ │
│ ❌ TAMBIÉN MALO: │
│ "Ve a reportes e intenta exportar" │
│ │
│ TIPS: │
│ • Sé específico sobre las acciones │
│ • Incluye cualquier dato requerido │
│ • Nota el timing si es relevante │
│ • Menciona si es intermitente │
└─────────────────────────────────────────────────────────────┘
Evidencia de Soporte
ADJUNTOS ÚTILES:
┌─────────────────────────────────────────────────────────────┐
│ TIPO │ CUÁNDO INCLUIR │
├───────────────────┼────────────────────────────────────────┤
│ Screenshot │ Bugs visuales, mensajes de error │
│ Grabación video │ Interacciones complejas, timing issues │
│ Logs de consola │ Errores JavaScript, warnings │
│ Captura network │ Fallas de API, requests lentos │
│ Logs de error │ Problemas server-side │
│ Archivo HAR │ Trace completo de network │
│ Datos de muestra │ Bugs específicos de datos │
└───────────────────────────────────────────────────────────────┘
EN GITSCRUM:
• Arrastra y suelta adjuntos a la tarea
• Enlaza a grabaciones de pantalla
• Pega imágenes directamente en descripción
• Adjunta archivos de log
Flujo de Trabajo de Bugs
Ciclo de Vida del Bug
FLUJO DE TRABAJO DE ESTADO DE BUG:
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ Nuevo │→ │ Triage │→ │Corrigie│→ │ Testing│→ │ Cerrado│
└────────┘ └────────┘ └────────┘ └────────┘ └────────┘
│ │ │ │ │
│ │ │ │ │
↓ ↓ ↓ ↓ ↓
Enviado Priorizado Asignado Verificado Released
y asignado desarrollad fix funciona
TRANSICIONES POSIBLES:
• Triage → Cerrado (No es bug / Won't fix / Duplicado)
• Testing → Corrigiendo (Fix no funcionó, reabrir)
• Cualquiera → Cerrado (Won't fix con explicación)
Proceso de Triage de Bugs
CHECKLIST DE REUNIÓN DE TRIAGE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PARA CADA NUEVO BUG: │
│ │
│ 1. VALIDAR │
│ □ ¿Es reproducible? │
│ □ ¿Es duplicado? │
│ □ ¿Es realmente un bug (no feature request)? │
│ │
│ 2. EVALUAR │
│ □ ¿Cuál es la severidad? │
│ □ ¿Cuántos usuarios afectados? │
│ □ ¿Hay workaround? │
│ │
│ 3. PRIORIZAR │
│ □ ¿Dónde encaja en backlog? │
│ □ ¿Debe interrumpir trabajo actual? │
│ □ ¿En qué sprint programar? │
│ │
│ 4. ASIGNAR │
│ □ ¿Quién tiene contexto? │
│ □ ¿Quién tiene capacidad? │
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas
Para Reportes de Bug
- Un bug por reporte — No agrupar problemas no relacionados
- Título descriptivo — Incluir acción, problema y área
- Evidencia visual — Screenshots valen mil palabras
- Contexto del entorno — Navegador, versión, tipo de cuenta
- Verificar antes de reportar — Asegurar que es reproducible
Errores Comunes
ERRORES EN REPORTES DE BUG:
✗ "No funciona" (sin detalles)
✗ Múltiples bugs en un ticket
✗ Sin pasos de reproducción
✗ Asumir que es obvio
✗ No incluir información de entorno
✗ Reportar bugs ya corregidos
✗ Título vago como "Error en página"
✗ No verificar si es duplicado