Reportar un bug de forma profesional significa documentar un defecto con suficiente detalle para que cualquier desarrollador pueda reproducirlo, entenderlo y corregirlo sin hacerte preguntas.
El reporte que nadie quiere leer
Imagina que encuentras un error en la app de Liverpool. El carrito de compras no guarda los productos seleccionados. Escribes en Jira: "El carrito no funciona" y lo asignas al desarrollador.
El desarrollador lo abre, no sabe qué probaste, en qué dispositivo, ni qué pasos seguiste. Te escribe de regreso. Tú tardas en responder. El bug sigue abierto dos días después.
Eso es un reporte malo. Cuesta tiempo, genera fricción y retrasa el sprint completo. Un buen reporte elimina todas esas preguntas antes de que nazcan.
El Sistema DEFECTO-CLARO
Un reporte profesional sigue siempre la misma estructura. Llámala el Sistema DEFECTO-CLARO: cada campo del reporte tiene un propósito específico y ninguno es opcional.
Este sistema tiene siete componentes:
- Título descriptivo — Una oración que identifica el problema sin ambigüedad.
- Entorno — Sistema operativo, navegador, versión de la app, dispositivo.
- Pasos para reproducir — Lista numerada, exacta y reproducible.
- Resultado actual — Lo que realmente ocurre.
- Resultado esperado — Lo que debería ocurrir según los criterios de aceptación.
- Severidad y prioridad — Qué tan grave es y qué tan urgente hay que corregirlo.
- Evidencia — Captura de pantalla, video, log de consola o respuesta de API.
Cuando los siete campos están completos, el desarrollador puede reproducir el bug en menos de cinco minutos. Sin ese sistema, el reporte es solo una queja.
Cómo escribir cada campo
El título: sé específico desde la primera palabra
Un mal título: "Error en el checkout". Un buen título: "Al aplicar cupón BIMBO20 en checkout, el total no se actualiza y muestra precio original".
El buen título tiene tres elementos: dónde ocurre, qué acción lo dispara y qué falla exactamente. Cualquier persona que lea ese título ya sabe de qué se trata sin abrir el reporte.
Los pasos para reproducir: trata al desarrollador como si fuera nuevo
Escribe los pasos como si la persona que los va a seguir nunca ha usado la app. No asumas contexto. No saltes pasos.
Ejemplo real para una app de FEMSA:
- Abrir la app OXXO Pay en iPhone 14, iOS 17.2.
- Iniciar sesión con cuenta registrada (correo + contraseña válidos).
- Seleccionar "Pagar servicio" en el menú principal.
- Elegir "CFE" de la lista de servicios.
- Ingresar número de contrato: 123456789012.
- Presionar "Continuar".
- Observar el comportamiento de la pantalla de confirmación.
Resultado actual: la pantalla se queda en blanco por 30 segundos y muestra "Error desconocido". Resultado esperado: mostrar el desglose del monto a pagar y un botón de confirmación.
Con esos pasos, cualquier desarrollador reproduce el bug en dos minutos. No hay ambigüedad.
Severidad vs. prioridad: no son lo mismo
Mucha gente confunde estos dos campos. La diferencia es crucial.
Severidad mide el impacto técnico del bug. ¿Qué tan grave es el daño? Prioridad mide la urgencia del negocio. ¿Qué tan rápido hay que corregirlo?
Ejemplo: en Mercado Libre, un bug visual donde el logo aparece pixelado en la página de inicio tiene severidad baja (no rompe ninguna función) pero puede tener prioridad alta si hay una campaña de marca activa ese día.
Al revés: un bug que corrompe datos de pagos tiene severidad crítica siempre, independientemente de si hay o no campaña.
Usa esta escala de severidad:
- Crítica: el sistema no funciona, pérdida de datos o dinero.
- Alta: una función principal no funciona pero hay workaround.
- Media: una función secundaria falla o el comportamiento es incorrecto.
- Baja: problema cosmético, texto mal escrito, alineación incorrecta.
La evidencia: una imagen vale más que cien reportes
Siempre adjunta evidencia. Siempre.
Para bugs visuales: captura de pantalla anotada con flechas o recuadros rojos que señalen exactamente el problema. Para bugs de flujo: video de pantalla que muestre los pasos y el momento exacto del fallo. Para bugs de backend: la respuesta completa del API (status code, body, headers) copiada como texto plano.
Si el bug involucra un cálculo de dinero — por ejemplo, el sistema de nómina de una empresa calcula mal el IMSS de un empleado con salario de $18,500 — adjunta también los valores de entrada y el resultado incorrecto vs. el resultado esperado en forma de tabla.
Plantilla lista para usar
Copia esta plantilla en Jira, Azure DevOps o cualquier herramienta que uses:
**Título:** [Dónde + qué acción + qué falla]
**Entorno:**
- App/versión:
- Sistema operativo:
- Navegador/dispositivo:
- URL o módulo:
**Pasos para reproducir:**
1.
2.
3.
**Resultado actual:**
[Describe exactamente lo que pasa]
**Resultado esperado:**
[Describe lo que debería pasar según los criterios de aceptación]
**Severidad:** Crítica / Alta / Media / Baja
**Prioridad:** Alta / Media / Baja
**Evidencia:**
[Adjunta screenshot, video o log]
**Notas adicionales:**
[Frecuencia del bug, si es intermitente, condiciones especiales]
Esta plantilla elimina el 90% de las preguntas de seguimiento.
Errores comunes al reportar bugs
Incluso testers con experiencia cometen estos errores. Reconócelos y evítalos.
Error 1: Mezclar varios bugs en un solo reporte. Cada bug es un ticket independiente. Si encuentras que el cupón no aplica Y que el botón de pago está deshabilitado, son dos reportes distintos. Mezclarlos complica el rastreo y la corrección.
Error 2: Escribir el resultado esperado desde la opinión personal. No escribas "debería verse mejor" o "el botón debería ser más grande". El resultado esperado debe venir de los criterios de aceptación de la historia de usuario, no de tu gusto estético.
Error 3: No verificar si el bug ya existe. Antes de crear un ticket nuevo, busca en la herramienta de gestión. Crear duplicados genera confusión y hace que el equipo trabaje dos veces en el mismo problema.
Error 4: Reportar sin reproducir el bug dos veces. Si el bug ocurrió una vez y no pudiste reproducirlo, no lo reportes como confirmado. Anótalo como "intermitente" e intenta reproducirlo en diferentes condiciones antes de escalar.
Error 5: Usar lenguaje acusatorio. Escribe "el sistema no calcula correctamente el IVA", no "el desarrollador rompió el cálculo del IVA". El reporte es un documento técnico, no un señalamiento personal.
Cómo priorizar qué bugs reportar primero
En un sprint activo, puedes encontrar diez bugs en un día. No todos tienen el mismo peso. Usa esta regla simple:
Reporta primero los bugs de severidad crítica o alta que bloqueen el flujo principal del usuario. En una tienda en línea como Liverpool, eso significa: registro, búsqueda, carrito, pago y confirmación de pedido.
Los bugs de severidad media o baja pueden esperar al cierre del sprint o agruparse en un reporte de deuda técnica.
Recuerda lo que aprendiste en la lección anterior: probar y reportar dentro de las primeras 24 horas después de que el desarrollador termina una historia reduce el costo de corrección. Eso también aplica a la velocidad con que reportas: un bug encontrado y documentado hoy cuesta menos que el mismo bug encontrado mañana.
El reporte como comunicación profesional
Un reporte de bug bien escrito hace dos cosas al mismo tiempo: resuelve un problema técnico y comunica tu nivel de profesionalismo como QA.
Cuando el equipo de desarrollo de Bimbo recibe un reporte tuyo y puede reproducir el bug sin hacerte ninguna pregunta, te ganarás su respeto rápidamente. Eso no es un detalle menor: en equipos de tecnología, la reputación de un QA se construye reporte a reporte.
Un reporte de bug profesional no solo describe un problema: le da al desarrollador todo lo que necesita para resolverlo sin perderse un segundo.