Un bug report bien escrito es el puente entre QA y desarrollo. Los bug reports deficientes conducen a idas y vueltas, pérdida de tiempo y frustración. Los excelentes bug reports logran que los bugs se corrijan rápidamente, mejoran la colaboración del equipo y ganan el respeto por el equipo de QA. En esta guía completa, exploraremos cómo escribir bug reports que los desarrolladores realmente aman.

Introducción: Por Qué Importan los Bug Reports

El Costo de los Bug Reports Deficientes

Los bug reports malos causan:

  • Tiempo desperdiciado: Desarrolladores pasando horas intentando reproducir problemas
  • Correcciones retrasadas: Bugs devueltos a QA para más información
  • Fricción del equipo: Frustración entre QA y desarrollo
  • Bugs perdidos: Reportes poco claros son despriorizados o cerrados
  • Confianza reducida: El equipo de QA pierde credibilidad

El Valor de los Excelentes Bug Reports

Los grandes bug reports entregan:

  • Correcciones rápidas: Los desarrolladores pueden entender y corregir el problema inmediatamente
  • Estimaciones precisas: Los reportes claros permiten una mejor planificación
  • Colaboración del equipo: Respeto mutuo entre QA y desarrollo
  • Mejora de calidad: Ideas sobre patrones y causas raíz
  • Reputación profesional: QA visto como socios de calidad, no guardianes

Perspectiva del Desarrollador

Lo que los desarrolladores quieren en un bug report:

  1. “¿Puedo reproducir esto?”
  2. “¿Qué está mal exactamente?”
  3. “¿Qué debería pasar en su lugar?”
  4. “¿Esto es crítico o puede esperar?”
  5. “¿Tengo toda la información que necesito?”

Lo que frustra a los desarrolladores:

  • “No funciona” (¿Qué no funciona? ¿Dónde? ¿Cómo?)
  • “La página está rota” (¿Qué página? ¿Qué está roto en ella?)
  • “A veces el botón falla” (¿Cuándo? ¿Bajo qué condiciones?)
  • Faltan pasos para reproducir
  • Sin capturas de pantalla o evidencia
  • No puede reproducir en su entorno

Anatomía del Bug Report Perfecto

Componentes Esenciales

Cada bug report debe incluir:

  1. Resumen/Título — Descripción de una línea
  2. Entorno — Dónde ocurre el bug
  3. Precondiciones — Configuración requerida
  4. Pasos para Reproducir — Acciones exactas para activar el bug
  5. Resultado Esperado — Qué debería pasar
  6. Resultado Real — Qué realmente pasa
  7. Severidad/Prioridad — Evaluación de impacto
  8. Adjuntos — Capturas de pantalla, videos, logs

Componentes Opcionales Pero Valiosos

  1. Frecuencia — Con qué frecuencia ocurre
  2. Solución Temporal — Solución temporal si existe
  3. Notas Adicionales — Contexto, bugs relacionados
  4. Datos de Prueba — Datos específicos utilizados
  5. Impacto del Usuario — Quién está afectado y cómo

Componente 1: Resumen/Título

Títulos Malos

- ❌ "Problema de login"
- ❌ "Bug en checkout"
- ❌ "Error en la página"
- ❌ "No funciona"
- ❌ "Problema con búsqueda"

Por qué son malos:

  • Demasiado vagos
  • No indican severidad
  • Múltiples bugs podrían coincidir
  • No se indica acción

Títulos Buenos

- ✅ "Botón de login no responde después de ingresar formato de email inválido"
- ✅ "Checkout falla con error 500 al aplicar código promocional expirado"
- ✅ "Búsqueda de productos no devuelve resultados para consultas con caracteres especiales"
- ✅ "Página de perfil de usuario muestra recuento de pedidos incorrecto para usuarios premium"

Lo que los hace buenos:

  • Específico: Componente/función exacta afectada
  • Orientado a la acción: Describe qué falla
  • Condición: Cuándo falla
  • Escaneable: El desarrollador puede entender rápidamente el problema

Fórmula del Título

[Componente/Página] + [Acción/Comportamiento] + [Condición/Contexto]

Ejemplos:
"Carrito de compras" + "elimina artículos" + "cuando el usuario cierra sesión"
"Restablecer contraseña" + "email no enviado" + "para usuarios con caracteres especiales en email"
"Dashboard" + "muestra métricas incorrectas" + "después del cambio de zona horaria"

Mejores Prácticas del Título

  1. Mantenlo bajo 80 caracteres (si es posible)
  2. Comienza con el componente afectado (fácil de escanear en listas)
  3. Usa voz activa (“Botón no responde” no “Botón está sin respuesta”)
  4. Evita palabras redundantes (“bug”, “problema”, “issue” — está implícito)
  5. Incluye códigos de error si aplica (“API devuelve error 404”)

Ejemplos Antes/Después:

- ❌ Antes: "Problema con pago"
- ✅ Después: "Procesamiento de pago falla con error timeout para pedidos >$1000"

- ❌ Antes: "Búsqueda rota"
- ✅ Después: "Autocompletado de búsqueda no muestra sugerencias para consultas <3 caracteres"

- ❌ Antes: "Problema de email"
- ✅ Después: "Email de confirmación de pedido contiene nombres de productos incorrectos"

Componente 2: Detalles del Entorno

Qué Incluir

Información de la Aplicación:

  • Versión de aplicación/número de build
  • Entorno (dev, staging, producción)
  • URL o endpoint

Navegador/Dispositivo:

  • Nombre de navegador y versión
  • Sistema Operativo y versión
  • Resolución de pantalla (para bugs de UI)
  • Modelo de dispositivo (para móvil)

Cuenta de Usuario:

  • Rol/permisos de usuario
  • Tipo de cuenta (gratis/premium/admin)
  • Antigüedad de cuenta o estados especiales

Red/Conexión:

  • Tipo de red (WiFi, 4G, 3G)
  • Estado de VPN (si es relevante)

Plantilla de Entorno

Entorno:
- Aplicación: App Web E-commerce v3.5.2 (Build #456)
- URL: https://staging.example.com
- Navegador: Chrome 120.0.6099.109
- SO: macOS Sonoma 14.2.1
- Resolución de Pantalla: 1920x1080
- Cuenta de Usuario: test-premium@example.com (Usuario Premium, creado 2025-09-01)
- Red: WiFi

Entorno de Bug Report Móvil:

Entorno:
- Aplicación: App Mobile Banking v2.3.0 (Build #234)
- Dispositivo: iPhone 14 Pro
- Versión iOS: 17.2
- Tamaño de Pantalla: 6.1" (2556×1179)
- Cuenta de Usuario: testuser@bank.com (Cuentas Checking + Savings)
- Red: 4G LTE
- Adicional: Face ID habilitado, Touch ID deshabilitado

Entorno de Bug Report API:

Entorno:
- API: Payment Gateway API v2.1
- Endpoint: POST /api/v2/payments
- Entorno: Staging (https://api-staging.example.com)
- API Key: pk_test_xxx (modo test)
- Herramienta de Request: Postman v10.19
- Timestamp: 2025-10-01 14:35:22 UTC

Por Qué Importa el Entorno

Diferentes comportamientos ocurren en diferentes entornos:

Ejemplo: El bug solo aparece en:
- Safari (no Chrome/Firefox) → Específico del navegador
- Producción (no staging) → Problema de datos o configuración
- Móvil (no desktop) → Problema de diseño responsivo
- Cuentas premium (no gratis) → Problema de permisos o feature flag

Componente 3: Precondiciones

¿Qué Son las Precondiciones?

Precondiciones son el estado requerido del sistema/datos antes de reproducir el bug.

Cuándo Incluir Precondiciones

Incluir cuando el bug requiere:

  • Estado específico de usuario (logueado, rol específico)
  • Datos específicos (artículos en carrito, métodos de pago guardados)
  • Configuraciones específicas (notificaciones habilitadas, modo oscuro)
  • Timing específico (durante horas de trabajo, después de medianoche)

Ejemplos de Precondiciones

Ejemplo 1: Bug de Checkout E-commerce

Precondiciones:
- Usuario logueado con cuenta premium
- Carrito de compras contiene 3 artículos (total >$100)
- Usuario tiene 2 métodos de pago guardados
- Código promocional activo "SAVE20" en sistema
- Dirección de envío del usuario está en California, USA

Ejemplo 2: Bug de Transacción Bancaria

Precondiciones:
- Usuario tiene cuenta Checking con balance $500
- Usuario tiene cuenta Savings con balance $1,000
- Usuario tiene tarjeta de débito activa vinculada a Checking
- Sin transacciones pendientes
- Cuenta en buen estado (sin holds/freezes)

Ejemplo 3: Bug de Notificación

Precondiciones:
- Usuario registrado hace >30 días
- Usuario tiene notificaciones por email habilitadas
- Usuario optó por emails promocionales
- Usuario no ha abierto la app en los últimos 7 días
- Sistema tiene job de email batch programado para 9 AM UTC

Error Común: Mezclar Precondiciones con Pasos

❌ Incorrecto:
Precondiciones: Click en botón de login

✅ Correcto:
Precondiciones: Cuenta de usuario existe con email test@example.com

Pasos para Reproducir:
1. Click en botón de login
2. ...

Recuerda: Precondiciones = estado antes de que comience la prueba; Pasos = acciones para activar el bug.

Componente 4: Pasos para Reproducir

La Regla de Oro

Si un desarrollador no puede reproducir el bug desde tus pasos, el bug no se corregirá.

Plantilla de Pasos para Reproducir

Pasos para Reproducir:
1. [Primera acción con detalles exactos]
2. [Segunda acción con detalles exactos]
3. [Tercera acción con detalles exactos]
...
N. [Acción final que activa el bug]

Mejores Prácticas para los Pasos

1. Sé Exacto y Específico

- ❌ Malo: "Ir a checkout"
- ✅ Bueno: "Click en botón 'Proceder al Checkout' en la parte inferior de la página del carrito"

- ❌ Malo: "Ingresar email"
- ✅ Bueno: "Ingresar email: 'test@example.com' en el campo 'Dirección de Email'"

- ❌ Malo: "Buscar algo"
- ✅ Bueno: "Escribir 'auriculares inalámbricos' en la barra de búsqueda y presionar Enter"

2. Numera Tus Pasos

✅ Bueno:
1. Navegar a https://example.com/login
2. Ingresar email: "user@test.com"
3. Ingresar contraseña: "Test123!"
4. Click en botón "Iniciar Sesión"
5. Observar mensaje de error

3. Incluye Datos Exactos

- ❌ Malo: "Ingresar una cantidad grande"
- ✅ Bueno: "Ingresar cantidad: 999999.99"

- ❌ Malo: "Subir una imagen"
- ✅ Bueno: "Subir imagen: 'test-image.png' (5MB, 3000x2000px)"

- ❌ Malo: "Seleccionar una fecha"
- ✅ Bueno: "Seleccionar fecha: 29 de febrero de 2024 desde el selector de fecha"

4. Una Acción Por Paso

❌ Malo:
1. Login e ir a configuración y cambiar email

✅ Bueno:
1. Click en botón "Login"
2. Ingresar credenciales y enviar
3. Navegar a página de Configuración
4. Click en opción "Cambiar Email"

5. Especifica Timing/Esperas Cuando Sea Relevante

Ejemplo:
3. Click en botón "Enviar Pedido"
4. Esperar a que cargue la página de confirmación (usualmente 2-3 segundos)
5. Observar: Mensaje de error aparece en lugar de confirmación

6. Incluye Detalles de Navegación

- ❌ Malo: "Ir al perfil"
- ✅ Bueno: "Click en avatar de usuario en esquina superior derecha → Seleccionar 'Mi Perfil' del dropdown"

- ❌ Malo: "Abrir configuración"
- ✅ Bueno: "Navegar a Configuración vía menú lateral (3er ítem desde arriba)"

Ejemplos del Mundo Real

Ejemplo 1: Bug de Checkout

Pasos para Reproducir:
1. Navegar a https://store.example.com
2. Agregar "Mouse Inalámbrico" al carrito (Product ID: WM-001)
3. Agregar "Cable USB" al carrito (Product ID: USB-C-003)
4. Click en ícono del carrito de compras (esquina superior derecha)
5. Verificar que el carrito muestra 2 artículos
6. Click en "Proceder al Checkout"
7. En página de checkout, ingresar código promocional: "SAVE20" en campo de código de descuento
8. Click en botón "Aplicar" al lado del campo de código promocional
9. Observar descuento aplicado: Total del carrito cambia de $45.00 a $36.00
10. Click en "Continuar al Pago"
11. Seleccionar "Tarjeta de Crédito" como método de pago
12. Ingresar detalles de tarjeta de prueba:
    - Número de Tarjeta: 4242 4242 4242 4242
    - Exp: 12/25
    - CVV: 123
13. Click en botón "Realizar Pedido"
14. Observar que aparece error

Ejemplo 2: Bug de Búsqueda

Pasos para Reproducir:
1. Navegar a https://example.com
2. Asegurar que no está logueado (usar ventana incógnito)
3. Click en barra de búsqueda en la parte superior de la página
4. Escribir: "O'Reilly" (incluir apóstrofo)
5. Presionar Enter o click en ícono de Búsqueda
6. Observar: No se encontraron resultados (Esperado: Libros de O'Reilly)

Consultas de búsqueda alternativas que también fallan:
- "Jack & Jill"
- "AT&T"
- Cualquier consulta que contenga caracteres especiales: ' " & < >

Ejemplo 3: Bug Dependiente del Timing

Pasos para Reproducir:
1. Login como usuario: admin@example.com
2. Navegar a Reportes → Generar Reporte Mensual
3. Seleccionar rango de fechas: 1-30 de septiembre, 2025
4. Click en botón "Generar Reporte"
5. INMEDIATAMENTE (dentro de 2 segundos) click en botón de retroceso del navegador
6. Navegar hacia adelante a página de Reportes nuevamente
7. Observar: Reporte muestra como "En Progreso" pero nunca completa

Nota: El bug NO ocurre si esperas 5+ segundos antes de clickear retroceso.

Pasos de Reproducción Mínimos

Después de escribir los pasos, intenta minimizarlos:

Pasos iniciales (10 pasos):
1. Login
2. Navegar al dashboard
3. Click en perfil
4. Editar perfil
5. Agregar número de teléfono
6. Guardar
7. Navegar a configuración
8. Click en notificaciones
9. Habilitar notificaciones SMS
10. Observar error

Minimizado (4 pasos):
1. Login como usuario con número de teléfono guardado
2. Navegar a Configuración → Notificaciones
3. Cambiar "Habilitar Notificaciones SMS" a ON
4. Observar error: "Número de teléfono inválido"

→ Pasos 1-6 fueron innecesarios si usamos precondición "Usuario tiene número de teléfono guardado"

Beneficios de pasos mínimos:

  • Más rápido para los desarrolladores reproducir
  • Causa raíz más clara
  • Más fácil probar la corrección

Componente 5: Resultados Esperado vs Real

Resultado Esperado

Qué debería pasar según requisitos/sentido común.

Resultado Esperado:
- Página de confirmación de pedido se muestra
- Email de confirmación enviado a user@example.com
- Pedido aparece en "Mis Pedidos" con estado "Procesando"
- Pago cargado a tarjeta de crédito
- Inventario decrementado para artículos comprados

Resultado Real

Qué realmente pasa, incluyendo mensajes de error exactos.

Resultado Real:
- Página muestra error: "Procesamiento de pago falló"
- Código de error mostrado: ERR_PAYMENT_TIMEOUT_500
- No se recibió email de confirmación
- Pedido NO aparece en "Mis Pedidos"
- Tarjeta de crédito NO fue cargada
- Inventario NO decrementado
- Consola del navegador muestra: "TypeError: Cannot read property 'transactionId' of undefined"

Mejores Prácticas

1. Sé Específico Sobre Qué Está Mal

❌ Malo:
Resultado Real: No funciona

✅ Bueno:
Resultado Real:
- Botón "Enviar" está en gris (no clickeable)
- Formulario muestra error: "Formato de email inválido" bajo campo de email
- Campo de email muestra valor: "test@example.com" (que es formato válido)

2. Incluye Mensajes de Error Exactos

❌ Malo:
Resultado Real: Aparece mensaje de error

✅ Bueno:
Resultado Real: Mensaje de error se muestra:
"Error 500: Internal Server Error
No se puede procesar el pago en este momento. Por favor intenta de nuevo más tarde.
Transaction ID: TXN-2025-10-01-1234"

3. Cita Mensajes de Error Exactamente

Usa comillas para texto exacto:

Resultado Real:
Banner de error muestra: "Oops! Something went wrong. Error code: 404"
(Nota: "Oops" tiene O mayúscula, "went wrong" no tiene coma)

4. Incluye Todos los Cambios Visibles

Resultado Esperado:
- Botón "Agregar al Carrito" cambia a "¡Agregado!"
- Ícono del carrito muestra badge con "1"
- Notificación de éxito aparece brevemente

Resultado Real:
- Botón "Agregar al Carrito" SÍ cambia a "¡Agregado!" ✅
- Badge del ícono del carrito SÍ se actualiza a "1" ✅
- Notificación de éxito NO aparece ❌ (Este es el bug)

Esperado vs Real: Ejemplos

Ejemplo 1: Bug Visual

Resultado Esperado:
- Imagen del producto se muestra a 300x300px
- Imagen está centrada en tarjeta del producto
- Imagen tiene 10px de border radius (esquinas redondeadas)
- Imagen carga en 1 segundo

Resultado Real:
- Imagen del producto se muestra a 150x300px (relación de aspecto incorrecta, estirada)
- Imagen está alineada a la izquierda (no centrada)
- Imagen tiene 0px de border radius (esquinas afiladas)
- Imagen carga correctamente en 1 segundo ✅

Ejemplo 2: Bug de Cálculo

Resultado Esperado:
Cálculo del total del carrito:
- Subtotal: $100.00 (2 artículos @ $50 cada uno)
- Descuento (20%): -$20.00
- Envío: $5.00
- Impuesto (10%): $8.50 (calculado sobre $100 - $20 + $5 = $85)
- Total: $93.50

Resultado Real:
- Subtotal: $100.00 ✅
- Descuento (20%): -$20.00 ✅
- Envío: $5.00 ✅
- Impuesto (10%): $10.00 ❌ (calculado sobre $100 en lugar de $85)
- Total: $95.00 ❌ (debería ser $93.50)

→ Bug: Impuesto calculado sobre subtotal antes de aplicar descuento

Ejemplo 3: Bug de Rendimiento

Resultado Esperado:
- Tiempo de carga de página: <3 segundos
- Resultados de búsqueda aparecen: <1 segundo después de la consulta
- Página permanece responsiva durante búsqueda

Resultado Real:
- Tiempo de carga de página: 12 segundos ❌
- Resultados de búsqueda aparecen: 8 segundos después de la consulta ❌
- Página se congela (no responde) durante búsqueda ❌
- Consola del navegador muestra advertencia: "Long task took 6234ms"

Componente 6: Severidad y Prioridad

Severidad: Impacto en el Sistema

Severidad = ¿Qué tan malo es el bug?

SeveridadDefiniciónEjemplo
Crítica (S1)Crash del sistema, pérdida de datos, brecha de seguridadSistema de pagos caído, datos de usuario expuestos
Alta (S2)Función principal rota, sin solución temporalNo se puede completar checkout, no se puede hacer login
Media (S3)Función parcialmente rota, existe solución temporalFiltro no funciona, se puede hacer scroll manual
Baja (S4)Problema menor, cosméticoBotón desalineado, error tipográfico en texto

Prioridad: Urgencia de la Corrección

Prioridad = ¿Qué tan pronto debe corregirse?

PrioridadDefiniciónEjemplo
P1 (Urgente)Corregir inmediatamente (hotfix)Fallo de pago en producción
P2 (Alta)Corregir en sprint actualFunción principal rota en beta
P3 (Media)Corregir en próximo sprintProblema de función menor
P4 (Baja)Corregir cuando sea posibleProblemas cosméticos

Matriz Severidad vs Prioridad

               │  P1    │  P2    │  P3    │  P4
               │ Urgente│  Alta  │ Media  │  Baja
───────────────┼────────┼────────┼────────┼────────
S1 Crítica     │   🔴   │   🟠   │   ⚪   │   ⚪
───────────────┼────────┼────────┼────────┼────────
S2 Alta        │   🟠   │   🟠   │   🟡   │   ⚪
───────────────┼────────┼────────┼────────┼────────
S3 Media       │   🟡   │   🟡   │   🟢   │   ⚪
───────────────┼────────┼────────┼────────┼────────
S4 Baja        │   ⚪   │   🟢   │   🟢   │   🔵

🔴 Crítico - Corregir inmediatamente
🟠 Alto - Corregir en 24 horas
🟡 Medio - Corregir dentro del sprint
🟢 Normal - Corregir en próximo sprint
🔵 Bajo - Backlog
⚪ Combinación poco probable

Ejemplos del Mundo Real

Ejemplo 1: Severidad Crítica, Prioridad Urgente (S1/P1)

Bug: Payment gateway devuelve error 500 para TODAS las transacciones

Impacto:
- 100% de clientes no pueden completar compras
- Ingresos completamente detenidos
- Alto volumen de soporte al cliente
- Pérdida potencial de ingresos: $10,000/hora

Severidad: S1 Crítica
Prioridad: P1 Urgente (Hotfix inmediato requerido)

Ejemplo 2: Severidad Alta, Prioridad Media (S2/P3)

Bug: Función de exportar a PDF rota en dashboard de admin

Impacto:
- Admins no pueden generar reportes PDF
- Solución temporal: Usar exportación CSV en su lugar
- Afecta: 5 usuarios admin
- Producción: No bloquea funciones de cara al cliente

Severidad: S2 Alta (función principal rota)
Prioridad: P3 Media (corregir en próximo sprint; existe solución temporal)

Ejemplo 3: Severidad Baja, Prioridad Alta (S4/P2)

Bug: Logo de empresa se muestra incorrectamente en homepage

Impacto:
- Solo problema visual/de marca
- Sin impacto funcional
- Muy visible (homepage)
- CEO lo notó y escaló
- Campaña de marketing se lanza mañana

Severidad: S4 Baja (cosmético)
Prioridad: P2 Alta (alta visibilidad, solicitud ejecutiva)

Evaluación del Impacto del Usuario

Incluye quién está afectado y cuántos:

Impacto del Usuario:
- Usuarios Afectados: Todos los usuarios premium (est. 5,000 usuarios)
- Flujo de Usuario Bloqueado: No pueden acceder a contenido premium
- Solución Temporal: Ninguna
- Tickets de Soporte al Cliente: 23 tickets en las últimas 2 horas
- Impacto de Negocio: Función premium no disponible, posibles cancelaciones

→ Justifica Severidad Alta, Prioridad Urgente

Componente 7: Adjuntos (Capturas de Pantalla, Videos, Logs)

Capturas de Pantalla: Mejores Prácticas

1. Anota Tus Capturas de Pantalla

- ❌ Malo: Captura de pantalla cruda sin anotaciones
- ✅ Bueno: Captura de pantalla con:
   - Flecha roja apuntando al bug
   - Círculo rojo resaltando el problema
   - Anotación de texto explicando el problema

Herramientas para anotación:

  • Snagit
  • Greenshot (Windows, gratis)
  • Skitch (Mac, gratis)
  • CloudApp
  • Herramientas integradas del SO (macOS: Cmd+Shift+4+5)

2. Captura Contexto Completo

Incluir:
- Ventana completa del navegador (muestra URL, versión del navegador)
- Elementos de UI relevantes alrededor del bug
- Mensajes de error completos
- Consola/tab de red si es relevante

3. Múltiples Capturas de Pantalla para Bugs de Múltiples Pasos

Adjunto 1: screenshot_step3_cart.png
   → Muestra carrito con 2 artículos antes de clickear checkout

Adjunto 2: screenshot_step5_promo_applied.png
   → Muestra descuento aplicado exitosamente

Adjunto 3: screenshot_step7_error.png
   → Muestra error al clickear "Realizar Pedido"

4. Convención de Nombres de Capturas de Pantalla

❌ Malo: image1.png, screenshot.png, Screen Shot 2025-10-01 at 2.45.23 PM.png

✅ Bueno:
- bug-checkout-payment-error.png
- step3-cart-before-checkout.png
- console-error-payment-timeout.png
- network-tab-500-error.png

Grabaciones de Pantalla: Cuándo y Cómo

Cuándo Usar Video:

  • Bug requiere múltiples interacciones
  • Bugs dependientes del timing
  • Bugs de animación/transición
  • Estados de hover o tooltips
  • Bugs intermitentes
  • Flujos de usuario complejos

Herramientas de Grabación:

  • Loom (basado en web, tier gratis)
  • CloudApp
  • ScreenToGif (Windows, gratis, crea GIF)
  • QuickTime (Mac, integrado)
  • OBS Studio (gratis, código abierto)

Mejores Prácticas de Video:

✅ Buena grabación de video:
1. Iniciar grabación antes de reproducir el bug
2. Mostrar barra de URL (muestra entorno)
3. Narrar pasos si es posible ("Ahora estoy clickeando checkout...")
4. Mantener video < 2 minutos (editar si es más largo)
5. Pausar en momento del error/bug (3-5 segundos)
6. Mostrar consola del navegador relevante si aplica

Formato de archivo: MP4 o GIF (si es corto)
Tamaño máx: <50MB (comprimir si es necesario)

Ejemplo de Estructura de Video:

0:00-0:05 - Mostrar estado inicial (logueado, carrito con artículos)
0:05-0:15 - Clickear a través de pasos de checkout
0:15-0:20 - Aplicar código promocional
0:20-0:30 - Ingresar detalles de pago
0:30-0:35 - Clickear "Realizar Pedido"
0:35-0:45 - Error aparece (pausar aquí por 5 segundos)
0:45-0:50 - Mostrar consola del navegador con error

Logs de Consola del Navegador

Cuándo Incluir Consola:

  • Errores de JavaScript
  • Errores de red (llamadas API fallidas)
  • Problemas de rendimiento
  • Problemas de integración de terceros

Cómo Capturar Consola:

1. Abrir Developer Tools (F12 o Cmd+Option+I)
2. Ir a tab de Console
3. Reproducir bug
4. Click derecho en consola → "Save as..."
   O
   Tomar captura de pantalla de la consola

Incluir:
- Mensajes de error (en rojo)
- Mensajes de advertencia (en amarillo)
- Requests de red fallidos
- Stack traces

Ejemplo de Log de Consola:

Adjunto: console-error-payment.txt

Contenido:
---
payment.js:142 Uncaught TypeError: Cannot read property 'transactionId' of undefined
    at processPayment (payment.js:142)
    at submitOrder (checkout.js:89)
    at HTMLButtonElement.<anonymous> (checkout.js:45)

POST https://api.example.com/payments 500 (Internal Server Error)

Payload enviado:
{
  "amount": 9350,
  "currency": "USD",
  "promo_code": "SAVE20"
}

Respuesta:
{
  "error": "Internal server error",
  "code": "ERR_PAYMENT_TIMEOUT_500"
}
---

Información de Tab de Red

Para Bugs de API/Backend:

Incluir:
- URL del Request
- Método del Request (GET, POST, etc.)
- Headers del Request
- Payload del Request
- Código de Estado de Respuesta
- Cuerpo de Respuesta

Captura de Pantalla del Tab de Red Debería Mostrar:

Adjunto: network-tab-payment-500-error.png

Visible en captura de pantalla:
- Request: POST /api/v2/payments
- Status: 500 Internal Server Error
- Tiempo de respuesta: 5.2s (timeout)
- Payload del request visible
- Cuerpo de respuesta visible

Archivos HAR (HTTP Archive)

Para problemas de red complejos:

Cómo exportar archivo HAR:
1. Abrir Developer Tools
2. Ir a tab de Network
3. Marcar "Preserve log"
4. Reproducir bug
5. Click derecho en tab de Network → "Save all as HAR with content"

Adjunto: checkout-payment-failure.har

⚠️ Advertencia: Eliminar datos sensibles (contraseñas, tokens, tarjetas de crédito) antes de compartir!

Logs de la Aplicación

Para bugs del lado del servidor o móvil:

Adjunto: application-error.log

Contenido:
---
[2025-10-01 14:35:22] ERROR: Payment processing failed
[2025-10-01 14:35:22] User ID: 12345
[2025-10-01 14:35:22] Order ID: ORD-2025-10-001234
[2025-10-01 14:35:22] Payment Gateway Response: TIMEOUT
[2025-10-01 14:35:22] Stack trace:
  at PaymentService.processPayment (PaymentService.java:142)
  at CheckoutController.submitOrder (CheckoutController.java:89)
---

Componente 8: Información Adicional

Frecuencia

¿Con qué frecuencia ocurre el bug?

Frecuencia: Siempre (100%) — Ocurre cada vez que se siguen los pasos

Frecuencia: A menudo (75%) — Ocurre 3 de cada 4 veces

Frecuencia: A veces (25-50%) — Intermitente, ocurrió 3 veces de 10 intentos

Frecuencia: Raro (<10%) — Ocurrió dos veces en 30 intentos

Frecuencia: Una vez — Solo observado una vez, no se puede reproducir

La frecuencia afecta la prioridad:

  • Siempre → Prioridad más alta (reproducción confiable)
  • Intermitente → Puede necesitar más investigación
  • Una vez → Puede ser difícil de corregir (difícil de reproducir)

Solución Temporal

Si existe solución temporal:

Solución Temporal:
- Usar "Checkout Exprés" en lugar de "Checkout Estándar"
- O navegar manualmente a /checkout/express
- Esto evita el paso del código promocional y permite completar el pedido
- Limitación: El usuario no puede aplicar código promocional con esta solución temporal

Impacto: Reduce severidad de S1 a S2 (mayor pero tiene solución temporal)

Datos de Prueba

Datos específicos utilizados:

Datos de Prueba:
- Cuenta de Usuario: test-premium@example.com / Test123!
- Tarjeta de Crédito: 4242 4242 4242 4242 (tarjeta de prueba Stripe)
- Código Promocional: SAVE20 (20% descuento, expira 2025-12-31)
- Productos en carrito:
  * Mouse Inalámbrico (SKU: WM-001) - $25.00
  * Cable USB (SKU: USB-C-003) - $20.00
- Dirección de Envío: 123 Main St, San Francisco, CA 94105

Bugs Relacionados

Enlace a problemas similares o relacionados:

Bugs Relacionados:
- BUG-456: Problema similar de timeout de pago con diferente código promocional
- BUG-489: Checkout falla para pedidos >$500 (puede ser la misma causa raíz)

Posiblemente Relacionado:
- BUG-423: Tiempos de respuesta lentos de payment gateway (problema de rendimiento)

Información de Regresión

Si el bug es una regresión:

Regresión: SÍ
- Funcionó en: v3.4.1 (Build #442)
- Roto en: v3.5.0 (Build #455)
- Causa probable: Cambios recientes al módulo de procesamiento de pagos (PR #789)

Esta información ayuda a los desarrolladores a reducir significativamente la causa raíz.

Ejemplo de Bug Report Perfecto

Ejemplo 1: Bug de Aplicación Web

**Título:** Checkout falla con error 500 al aplicar código promocional "SAVE20" a carrito >$100

**Entorno:**
- Aplicación: App Web E-commerce v3.5.2 (Build #456)
- URL: https://staging.example.com
- Navegador: Chrome 120.0.6099.109
- SO: macOS Sonoma 14.2.1
- Cuenta de Usuario: test-premium@example.com (Premium, registrado 2025-09-01)
- Red: WiFi

**Severidad:** S1 Crítica
**Prioridad:** P1 Urgente

**Precondiciones:**
- Usuario logueado como miembro premium
- Código promocional "SAVE20" existe en sistema (20% descuento, expira 2025-12-31)
- Total del carrito debe ser >$100 después de agregar artículos

**Pasos para Reproducir:**
1. Navegar a https://staging.example.com
2. Login con test-premium@example.com / Test123!
3. Agregar "Mouse Inalámbrico" (SKU: WM-001, $25) al carrito
4. Agregar "Cable USB" (SKU: USB-C-003, $20) al carrito
5. Agregar "Teclado" (SKU: KB-005, $60) al carrito
6. Verificar que total del carrito muestra $105.00
7. Click en "Proceder al Checkout"
8. En página de checkout, ingresar código promocional: "SAVE20" en campo de descuento
9. Click en botón "Aplicar"
10. Observar descuento aplicado: Total cambia de $105.00 a $84.00
11. Seleccionar método de pago: "Tarjeta de Crédito"
12. Ingresar tarjeta de prueba: 4242 4242 4242 4242, Exp: 12/25, CVV: 123
13. Click en botón "Realizar Pedido"

**Resultado Esperado:**
- Pedido se procesa exitosamente
- Página de confirmación se muestra con número de pedido
- Email de confirmación enviado a test-premium@example.com
- Pedido aparece en "Mis Pedidos" con estado "Procesando"
- Pago de $84.00 cargado a tarjeta

**Resultado Real:**
- Página muestra error: "Procesamiento de pago falló. Por favor intenta de nuevo más tarde."
- Código de error mostrado: ERR_PAYMENT_TIMEOUT_500
- No se recibió email de confirmación
- Pedido NO aparece en "Mis Pedidos"
- Tarjeta de crédito NO fue cargada
- Consola del navegador muestra: "POST https://api.staging.example.com/payments 500 (Internal Server Error)"
- Error de consola: "TypeError: Cannot read property 'transactionId' of undefined at processPayment (payment.js:142)"

**Frecuencia:** Siempre (100%) — Reproducido 5 veces consistentemente

**Impacto del Usuario:**
- Afecta: Todos los usuarios (premium y estándar) aplicando código promocional a pedidos >$100
- Tickets de soporte al cliente: 12 tickets en última hora
- Usuarios afectados estimados: 50+ en últimas 24 horas
- Impacto de negocio: Ingresos perdidos, frustración del cliente

**Solución Temporal:**
- Remover código promocional antes de checkout (usuario paga precio completo)
- O usar pedidos <$100 (descuento funciona correctamente)
- Limitación: Usuarios no pueden obtener descuento promocional en pedidos grandes

**Adjuntos:**
1. screenshot-step10-discount-applied.png (Muestra total $84 después de descuento)
2. screenshot-step13-error-message.png (Muestra error después de clickear Realizar Pedido)
3. console-error-log.txt (Salida completa de consola con stack trace)
4. network-tab-500-error.png (Muestra detalles del request API fallido)
5. checkout-flow.mp4 (Grabación de pantalla de 30 segundos de reproducción completa)

**Notas Adicionales:**
- Bug NO ocurre con totales de carrito <$100
- Bug NO ocurre sin código promocional
- Código promocional diferente "WELCOME10" también activa mismo error
- Regresión: Funcionó en v3.4.1, roto desde deployment v3.5.0
- Posiblemente relacionado con BUG-456 (problemas de timeout de pago)

**Datos de Prueba:**
- Código promocional probado: SAVE20
- Productos en carrito: WM-001, USB-C-003, KB-005
- Total del carrito antes de descuento: $105.00
- Total del carrito después de descuento: $84.00
- Tarjeta de crédito: Tarjeta de prueba Stripe 4242...

Ejemplo 2: Bug de Aplicación Móvil

**Título:** App se cierra al subir foto de perfil >5MB en iPhone 14

**Entorno:**
- Aplicación: App Mobile Banking v2.3.0 (Build #234)
- Dispositivo: iPhone 14 Pro (Modelo: MQ0G3LL/A)
- Versión iOS: 17.2.1
- Almacenamiento Disponible: 32GB libre
- Cuenta de Usuario: testuser@bank.com (Titular de cuenta Checking)
- Red: WiFi (50 Mbps)

**Severidad:** S2 Alta
**Prioridad:** P2 Alta

**Precondiciones:**
- Usuario logueado en app
- Librería de fotos contiene imagen >5MB
- Usuario aún no ha establecido foto de perfil

**Pasos para Reproducir:**
1. Abrir App Mobile Banking
2. Tocar ícono de perfil (esquina superior derecha)
3. Tocar "Editar Perfil"
4. Tocar placeholder de foto de perfil
5. Tocar "Elegir de Librería"
6. Permitir acceso a fotos (si se solicita)
7. Seleccionar foto: IMG_5847.JPG (Tamaño de archivo: 8.2MB, 4032x3024px)
8. Tocar "Elegir"

**Resultado Esperado:**
- Imagen se sube exitosamente
- Foto de perfil se actualiza a imagen seleccionada
- Usuario regresado a pantalla de perfil
- Mensaje de éxito: "Foto de perfil actualizada"

**Resultado Real:**
- Indicador de progreso se muestra (spinner)
- Después de 2-3 segundos, app se cierra completamente
- Usuario regresado a pantalla de inicio de iOS
- Al reabrir app, foto de perfil NO actualizada
- Log de crash de app generado

**Frecuencia:** Siempre (100%) con imágenes >5MB

**Impacto del Usuario:**
- Afecta: Usuarios con imágenes de alta resolución de iPhones nuevos
- Estimado: 30% de usuarios tienen imágenes >5MB en librería
- Existe solución temporal (ver abajo)

**Solución Temporal:**
1. Usar app de terceros para comprimir imagen <5MB
2. Subir imagen comprimida
Limitación: Requiere pasos extra, menor calidad de imagen

**Adjuntos:**
1. crash-log-profile-picture.txt (Log de crash de iOS)
2. test-image-8.2MB.jpg (Imagen de muestra que activa crash)
3. screen-recording-crash.mp4 (Video mostrando crash)
4. xcode-console-output.txt (Salida del debugger de Xcode)

**Notas Adicionales:**
- Imágenes <5MB se suben exitosamente
- Bug ocurre en iPhone 13, 14, 15 (probado)
- Bug NO ocurre en iPad Pro (probado)
- Log de crash muestra: "Memory warning level 2" antes del crash
- Causa probable: Imagen no redimensionada antes de subir, causando problema de memoria

**Datos de Prueba:**
- Imagen de prueba 1: IMG_5847.JPG (8.2MB) → Crash
- Imagen de prueba 2: IMG_5848.JPG (4.8MB) → Éxito
- Imagen de prueba 3: IMG_5849.JPG (12.5MB) → Crash

Mejores Prácticas de Comunicación

Tono y Lenguaje

1. Sé Profesional, No Emocional

❌ Malo:
"¡Esto es ridículo! El checkout está completamente roto OTRA VEZ. ¿Cómo pasó esto la revisión de código?"

✅ Bueno:
"Checkout falla con error 500 al aplicar códigos promocionales. Esta es una regresión desde v3.4.1."

2. Enfócate en Hechos, No en Culpas

❌ Malo:
"Los desarrolladores obviamente no probaron esta función en absoluto."

✅ Bueno:
"Este escenario puede no haber sido cubierto en las pruebas. Caso de prueba sugerido: Códigos promocionales en pedidos >$100."

3. Usa Lenguaje Neutral

- ❌ Acusatorio: "Rompiste el sistema de pagos"
- ✅ Neutral: "Sistema de pagos devuelve error desde deployment v3.5"

- ❌ Emocional: "¡Esto es un desastre!"
- ✅ Factual: "Esto bloquea todas las transacciones de checkout (S1 Crítico)"

Colaboración, No Confrontación

Los bug reports son herramientas de comunicación, no armas.

Buena colaboración:

  • “Encantado de proporcionar más detalles si es necesario”
  • “Puedo probar una corrección en staging cuando esté lista”
  • “Avísame si no puedes reproducir—grabaré video”
  • “¿Posiblemente relacionado con PR #789? (Solo un pensamiento)”

Construyendo confianza:

  • Reconocer buenas correcciones: “¡Gracias por la corrección rápida! Verificado en staging ✅”
  • Admitir errores: “Mi error—esto fue mala configuración, no un bug. Cerrando.”
  • Ofrecer ayuda: “Puedo ayudar a investigar si es necesario”

Seguimiento de Bug Reports

1. Responde Rápidamente a Preguntas

Desarrollador pregunta: "¿Puedes probar con código promocional 'WELCOME10'?"

✅ Buena respuesta (en horas):
"Probado con WELCOME10—ocurre mismo error 500. También probé FREESHIP—funciona bien.
Parece ser específico a códigos promocionales basados en porcentaje."

2. Verifica Correcciones Completamente

Cuando bug marcado "Corregido":

✅ Buena verificación:
"Verificada corrección en staging (Build #460):
- Probados pasos de reproducción originales—sin error ✅
- Probado con diferentes códigos promocionales (SAVE20, SAVE10, WELCOME15)—todos funcionan ✅
- Probado con totales de carrito: $50, $100, $500—todos funcionan ✅
- Probado como usuario premium y estándar—ambos funcionan ✅

Marcando como Verificado. ¡Excelente corrección!"

3. Reabre Consideradamente

Si el bug vuelve a ocurrir:

✅ Buen comentario de reapertura:
"Reabriendo: Problema vuelve a ocurrir en Producción (Build #461) pero NO en Staging (Build #460).
¿Posible diferencia de entorno?

Nuevos hallazgos:
- Staging usa servicio de código promocional v2.1
- Producción usa servicio de código promocional v2.0 (verificado con DevOps)

Esto puede explicar la discrepancia."

Manejo de Situaciones Difíciles

Situación 1: Desarrollador No Puede Reproducir

Desarrollador comenta: "No puedo reproducir. Funciona bien para mí."

✅ Buena respuesta:
"Gracias por intentar. Déjame proporcionar más detalles:
1. Grabación de pantalla adjunta (repro-full-flow.mp4)
2. Puedo reproducir en staging pero NO en entorno dev
3. Verificado con Sarah (QA)—ella también lo reproduce
4. Encantado de hacer screenshare/pair debugging si es útil

Diferencia que noté: Dev usa SQLite, Staging usa PostgreSQL.
¿Podría esto estar relacionado con base de datos?"

Situación 2: Bug Marcado “Funciona Según Diseño”

Desarrollador cierra como "No es un bug—funciona según diseño"

✅ Buena respuesta:
"Gracias por aclarar. Veo por tu comentario que este es comportamiento intencional.

Sin embargo, desde la perspectiva del usuario esto es confuso porque:
- Código promocional parece aplicarse (descuento se muestra)
- Error solo aparece en paso final
- Sin indicación de que códigos promocionales no funcionan con pedidos >$100

Sugerencia: ¿Podríamos agregar validación más temprano en el flujo?
Ej., Mostrar mensaje al aplicar código: 'Este código promocional es válido para pedidos bajo $100'

¿Debería crear esto como solicitud de función en su lugar?"

Situación 3: Bug con Prioridad Baja a Pesar del Alto Impacto del Usuario

Bug marcado P3 (Media) pero crees que debería ser P1:

✅ Buena respuesta:
"Entendido que esto está priorizado como P3.

Quiero proporcionar contexto adicional:
- 45 tickets de soporte al cliente en últimas 24 horas (reporte adjunto)
- Estimado 200 usuarios afectados basado en analytics
- Tasa de éxito de pago cayó de 95% a 78% desde deployment
- Impacto de negocio: ~$5,000 de ingresos perdidos por día

¿Quieren los stakeholders reconsiderar prioridad dado este impacto?
Encantado de presentar datos en standup/planning."

Plantillas de Bug Report

Plantilla Simple (Para Bugs Rápidos)

**Título:** [Componente] + [qué falla] + [cuándo/condición]

**Entorno:** [Versión, Navegador/Dispositivo, SO]

**Pasos:**
1. Paso uno
2. Paso dos
3. Observar bug

**Esperado:** [Qué debería pasar]

**Real:** [Qué realmente pasa]

**Severidad/Prioridad:** [S#/P#]

**Captura de Pantalla:** [Adjuntar si aplica]

Plantilla Completa

**Título:**

**Entorno:**
- Aplicación:
- URL/Versión:
- Navegador/Dispositivo:
- SO:
- Cuenta de Usuario:

**Severidad:**  S__ (Crítica/Alta/Media/Baja)
**Prioridad:**  P__ (Urgente/Alta/Media/Baja)

**Precondiciones:**
-
-

**Pasos para Reproducir:**
1.
2.
3.

**Resultado Esperado:**
-
-

**Resultado Real:**
-
-

**Frecuencia:** [Siempre / A menudo / A veces / Raro / Una vez]

**Impacto del Usuario:**
- Usuarios afectados:
- Impacto:

**Solución Temporal:** [Si existe]

**Adjuntos:**
-
-

**Notas Adicionales:**
-
-

**Datos de Prueba:**
-

Plantilla de Bug Report API

**Título:** [Endpoint] devuelve [código de estado] para [condición]

**Entorno:**
- Versión API:
- Endpoint:
- Entorno: [Dev/Staging/Prod]
- Timestamp:

**Request:**

Método: POST URL: https://api.example.com/v2/payments Headers: Authorization: Bearer Content-Type: application/json

Body: { “amount”: 9350, “currency”: “USD”, “promo_code”: “SAVE20” }


**Respuesta Esperada:**

Status: 200 OK Body: { “transaction_id”: “TXN-xxx”, “status”: “success” }


**Respuesta Real:**

Status: 500 Internal Server Error Body: { “error”: “Internal server error”, “code”: “ERR_PAYMENT_TIMEOUT_500” }


**Frecuencia:**

**Info Adicional:**
- Tiempo de respuesta:
- Logs del servidor:

Conclusión: Dominando el Reporting de Bugs

El excelente reporting de bugs es una habilidad que distingue a los grandes profesionales de QA. Conclusiones clave:

1. Componentes Esenciales

  • Título claro y específico
  • Detalles completos del entorno
  • Pasos exactos para reproducir
  • Resultados esperados vs reales
  • Severidad/prioridad apropiada
  • Adjuntos de apoyo

2. Calidad Sobre Cantidad

  • Un bug report claro y detallado > Cinco vagos
  • Invierte tiempo al principio para ahorrar tiempo a todos después
  • Minimiza pasos de reproducción sin perder claridad

3. Evidencia de Apoyo

  • Capturas de pantalla (anotadas)
  • Grabaciones de pantalla (para flujos complejos)
  • Logs de consola y mensajes de error
  • Requests/respuestas de red

4. Comunicación Profesional

  • Tono neutral y factual
  • Enfoque en hechos, no en culpas
  • Enfoque colaborativo
  • Responsivo a preguntas

5. Piensa Como un Desarrollador

  • “¿Puedo reproducir esto desde estos pasos?”
  • “¿Tengo toda la información que necesito?”
  • “¿Cuál es probablemente la causa raíz?”

Próximos Pasos:

  1. Revisa tus bug reports recientes—¿cómo pueden mejorar?
  2. Crea plantillas para tu equipo
  3. Comparte esta guía con miembros del equipo
  4. Practica escribir un bug report “perfecto” esta semana
  5. Pide feedback a los desarrolladores sobre tus bug reports
  6. ¡Celebra cuando los bugs se corrijan rápidamente debido a tus reportes claros!

Recuerda: Tus bug reports son tu reputación profesional. Cada bug report bien escrito:

  • Ahorra tiempo de desarrollador
  • Hace que los bugs se corrijan más rápido
  • Construye confianza y respeto
  • Mejora la calidad del producto
  • Avanza tu carrera

¡Escribe bug reports que los desarrolladores amen, y observa cómo tu impacto se multiplica!