Por Que Importa la Calidad del Bug Report

Un bug report es una herramienta de comunicacion entre QA y desarrollo. Un report bien escrito se corrige rapido. Uno mal escrito se ignora, se devuelve para clarificacion o se desprioriza porque nadie puede reproducirlo.

Impacto de malos bug reports:

  • Desarrollador gasta 30 minutos intentando reproducir un bug vago = tiempo perdido
  • Bug regresa a QA para mas informacion = 1-2 dias de retraso
  • Bug se cierra como “Cannot Reproduce” = el defecto llega a produccion

Impacto de buenos bug reports:

  • Desarrollador lee el report, reproduce en 2 minutos, empieza a corregir inmediatamente
  • No se necesita comunicacion ida y vuelta
  • Bug se corrige en el mismo sprint que se reporto

Anatomia de un Bug Report Perfecto

Titulo

El titulo debe responder: Que fallo, Donde fallo y Cuando/Como fallo.

Formula: [Componente] Accion falla con [Error] cuando [Condicion]

Malo: “Login no funciona” Bueno: “Formulario de login retorna HTTP 500 cuando email contiene caracter ‘+’”

Malo: “Problema en carrito” Bueno: “Total del carrito muestra $0.00 despues de aplicar cupon de 100% de descuento a un item”

Entorno

Siempre especifica: browser/version, OS, resolucion, rol de usuario, version de API.

Precondiciones

Establece el punto de partida claramente:

  • “Usuario logueado con rol: Admin”
  • “Carrito contiene 2 items (total: $59.98)”

Pasos para Reproducir

Pasos numerados y precisos que cualquiera puede seguir:

1. Navegar a https://app.example.com/login
2. Ingresar "user+test@example.com" en el campo email
3. Ingresar "ValidPass123!" en el campo password
4. Hacer click en boton "Sign In"

Reglas:

  • Una accion por paso
  • Incluir valores exactos
  • Incluir URLs y rutas de navegacion
  • Numerar cada paso
  • Partir desde un estado conocido (precondiciones)

Resultado Esperado

Que deberia pasar segun requisitos: “Usuario es redirigido al dashboard. Mensaje de bienvenida muestra el nombre.”

Resultado Actual

Que realmente pasa, con detalles especificos: “Pagina muestra HTTP 500 Internal Server Error. Consola muestra: TypeError: Cannot read property 'split' of undefined”

Evidencia

Adjuntar:

  • Screenshot — anotado con flechas senalando el issue
  • Video — grabacion de pantalla mostrando la reproduccion completa
  • Console logs — errores de consola del browser
  • Network trace — archivo HAR o request/response especifico
  • Server logs — logs de error relevantes

Informacion Adicional

  • Frecuencia: Siempre / Intermitente (3 de 10 intentos) / Una vez
  • Workaround: Hay un camino alternativo para usuarios?
  • Regresion: Funcionaba en version anterior?
  • Bugs relacionados: Links a issues similares

Ejemplo Real de Bug Report 

Titulo: Checkout falla con "Payment declined" para tarjetas Visa
        validas terminando en 0000 en Safari 17

Entorno: Safari 17.2 / macOS Sonoma 14.2 / Produccion

Precondiciones:
- Usuario logueado como test_user_42
- Carrito contiene "Premium Plan" ($49.99/mes)

Pasos para Reproducir:
1. Navegar a /checkout
2. Seleccionar "Credit Card" como metodo de pago
3. Ingresar tarjeta: 4242 4242 4242 0000
4. Ingresar expiracion: 12/28
5. Ingresar CVC: 123
6. Hacer click en "Subscribe"

Resultado Esperado:
Pago exitoso. Usuario ve pagina de confirmacion.

Resultado Actual:
Banner de error: "Payment declined. Please try a different card."
Network tab muestra POST /api/payments retorna 422.

Nota: Misma tarjeta funciona en Chrome 120 y Firefox 121.
Issue especifico de Safari.

Frecuencia: Siempre en Safari 17. Nunca en Chrome/Firefox.
Workaround: Usuario puede completar checkout en Chrome.
Regresion: Funcionaba en Safari 16.

Ejercicio: Corrige Estos Bug Reports

Reescribe los siguientes bug reports mal escritos:

Mal Report 1:

Titulo: Busqueda rota
Descripcion: Cuando busco cosas, no funciona bien.

Mal Report 2:

Titulo: Pagina lenta
Descripcion: La pagina es muy lenta. Por favor arreglar.
Solucion

Report 1 Reescrito:

Titulo: Busqueda retorna 0 resultados para productos existentes
        cuando query contiene caracteres especiales (&, <, >)

Entorno: Chrome 120 / Windows 11 / Entorno QA

Precondiciones:
- Producto "AT&T Wireless Plan" existe en BD
- Usuario en homepage

Pasos:
1. Hacer click en barra de busqueda
2. Escribir "AT&T"
3. Presionar Enter

Esperado: Resultados muestran "AT&T Wireless Plan"
Actual: "0 results found for AT&T". El caracter & se codifica como %26
pero la API no lo decodifica antes de buscar.

Frecuencia: Siempre con &, <, >. Queries normales funcionan bien.

Report 2 Reescrito:

Titulo: Dashboard tarda 12 segundos en cargar con 500+ tareas
        (esperado < 3 segundos)

Entorno: Chrome 120 / macOS / Produccion

Precondiciones: Cuenta con 547 tareas en 12 proyectos

Pasos:
1. Loguearse como test_heavy_user (547 tareas)
2. Navegar a /dashboard
3. Medir tiempo de carga (DOMContentLoaded)

Esperado: Dashboard carga en menos de 3 segundos
Actual: DOMContentLoaded: 12.3 segundos. GET /api/tasks retorna 547
items en una sola respuesta (4.2MB). Sin paginacion.

Evidencia: [Profile de rendimiento adjunto] [Archivo HAR adjunto]

Errores Comunes

  1. “No funciona” — explica que especificamente no funciona
  2. Sin pasos para reproducir — desarrolladores no pueden arreglar lo que no ven
  3. Screenshots sin contexto — siempre anota que mirar
  4. Sin info de entorno — bugs frecuentemente son especificos de browser u OS
  5. Lenguaje emocional — “Este bug terrible” no ayuda. Se factual
  6. No verificar si ya fue reportado — busca bugs existentes primero

Puntos Clave

  • Bug reports son herramientas de comunicacion — escribe para el desarrollador que lo corregira
  • Formula del titulo: [Componente] Accion falla con [Error] cuando [Condicion]
  • Pasos para reproducir son lo mas critico — una accion por paso, valores exactos
  • Siempre incluir resultado esperado vs actual con detalles especificos
  • Adjuntar evidencia: screenshots anotados, videos, console logs, trazas de red
  • Incluir entorno, frecuencia, workaround e informacion de regresion