El resultado más común de un reporte de bug mal escrito: el desarrollador no puede reproducir el problema, lo marca como "Cannot Reproduce" y sigue. El bug sigue existiendo. Cada elemento de un reporte efectivo previene un fallo específico: un título preciso evita que el ticket quede en el equipo equivocado, los pasos numerados exactos con precondiciones evitan el resultado "cannot reproduce", y los resultados esperado y actual separados evitan que los desarrolladores bajen la prioridad de algo que no pueden evaluar.

Por qué fallan los reportes de bugs

El resultado más común de un reporte de bug mal escrito: el desarrollador lo abre, no puede reproducir el problema, lo marca como "Cannot Reproduce" y sigue. El bug sigue existiendo. Perdiste tiempo. El desarrollador está levemente frustrado. Nadie gana.

El segundo resultado más común: el desarrollador lo reproduce pero no entiende el impacto, le baja la prioridad y llega a producción.

Los dos fallos son prevenibles.

La anatomía de un reporte de bug que se corrige

Título: una oración, sin palabras vagas

El título es lo que aparece en Jira o en el tracker que use tu equipo. Debería decirle a un desarrollador que lee una lista de tickets exactamente cuál es el bug, sin abrirlo.

Títulos malos:

  • "Bug de login"
  • "Algo roto en el dashboard"
  • "Problema con el mensaje de error"
  • "La tabla no funciona bien"

Títulos buenos:

  • "El formulario de login se envía con el campo de contraseña vacío: no se muestra error de validación"
  • "La tabla del dashboard pierde el orden de clasificación después de filtrar por estado"
  • "La subida de archivos muestra un toast de 'Éxito' aunque falle con error 413"
  • "El conteo de filas de la tabla de ítems difiere de la respuesta de la API cuando la página carga con un filtro activo"

El patrón es: [componente/función] [qué pasa] [cuándo/bajo qué condición]. Todo lo que un desarrollador necesita para entender el alcance del problema, antes de hacer clic para abrirlo.

Entorno: exactamente dónde ocurre

Vago: "Chrome en Windows"

Útil:

Navegador: Chrome 124.0.6367.78 (Windows 11)
SO: Windows 11 22H2
Versión de la app/build: v2.4.1 (commit: abc123)
Entorno de test: staging (https://staging.lab.becomeqa.com)
Usuario de test: admin@becomeqa.com

Los detalles del entorno parecen tediosos hasta que estás intentando reproducir un bug que solo ocurre en Firefox en macOS y llevas 20 minutos en Chrome en Windows preguntándote por qué no falla.

Pasos para reproducir: exactos, numerados, autocontenidos

Cada paso debe ser tan específico que alguien que nunca vio este bug pueda reproducirlo al primer intento.

Mal:

1. Iniciar sesión
2. Ir a los ítems
3. Ordenar y filtrar
4. El bug aparece

Bien:

Precondiciones: el usuario inició sesión como admin@becomeqa.com.
La tabla de ítems muestra la vista por defecto (sin filtros activos).

Pasos:
1. Navegar a https://lab.becomeqa.com/dashboard
2. Hacer clic en el encabezado de la columna "Estado" para ordenar de forma ascendente
3. Hacer clic en el dropdown "Filtrar" y seleccionar "Planificado"
4. Hacer clic nuevamente en el encabezado de la columna "Estado" para ordenar de forma descendente
5. Quitar el filtro haciendo clic en "Limpiar" en el dropdown de filtros

Resultado esperado: la tabla vuelve a la vista por defecto mostrando todos los ítems,
ordenados según el último orden de clasificación (Estado descendente).

Resultado actual: la tabla muestra todos los ítems pero el orden de clasificación
se resetea al por defecto (sin ordenar), perdiendo el estado de clasificación del paso 2.

La diferencia: la primera versión requiere que el lector adivine qué significa "ordenar y filtrar". La segunda no requiere adivinar nada.

Resultado esperado vs resultado actual: los dos son obligatorios

Todo reporte de bug necesita los dos:

Resultado esperado: qué debería pasar según la especificación, el sentido común o la intención del desarrollador. Si hay un requisito documentado, referencíalo. "Según los criterios de aceptación en PROJ-142, el filtrado no debería afectar el estado de clasificación." Resultado actual: qué pasa realmente. Sé preciso. "Muestra un error" es débil; "muestra 'Internal Server Error' en un toast rojo en la parte superior de la página durante 3 segundos" es útil.
No escribas "Esperado: que funcione. Actual: que no funciona." Este es el modo de fallo más común en los reportes de bugs de nivel junior. El resultado esperado debe describir el comportamiento correcto específico, no solo "que funcione."

Severidad y prioridad: son cosas distintas

Severidad es el impacto en el sistema: ¿qué tan grave es este bug técnicamente?
  • Crítico: caída del sistema, pérdida de datos, vulnerabilidad de seguridad, bloquea la funcionalidad principal para todos los usuarios
  • Mayor: función importante rota para un subconjunto de usuarios, tiene un workaround
  • Menor: problema funcional pequeño, cosmético, improbable que afecte a muchos usuarios
  • Trivial: error tipográfico, inconsistencia visual menor, sin impacto funcional
Prioridad es la urgencia del negocio: ¿con qué rapidez necesita corregirse?

Un error tipográfico en la página de error de un producto de salud puede ser de severidad Menor pero prioridad Alta (preocupación regulatoria). Una función de admin rota puede ser de severidad Mayor pero prioridad Baja (la usan dos personas una vez al mes).

Configurar la severidad y la prioridad con precisión señala que entiendes el impacto en el negocio, no solo el comportamiento técnico.

Adjuntos: mostrá, no solo describas

Las capturas de pantalla capturan el resultado actual de forma visual. Una captura que muestra el toast incorrecto vale más que tres oraciones describiéndolo.

Las grabaciones de video son invaluables para bugs dependientes del tiempo: race conditions, problemas con animaciones, fallos intermitentes. Un software de grabación de pantalla (Loom, OBS, ShareX) tarda 30 segundos en configurarse y previene horas de "cannot reproduce".

Los logs de red (desde DevTools del navegador, pestaña Network) son críticos para los bugs a nivel de API. Muestran exactamente qué solicitud se envió, qué respuesta llegó y el timing.

Los logs de consola a menudo contienen el error que explica el bug. Los desarrolladores pueden identificar la causa raíz de inmediato a partir de un stack trace de error de JavaScript.

Para los bugs intermitentes, grabá un video en la primera reproducción. No asumas que podrás reproducirlo de nuevo para el desarrollador.

Un ejemplo completo

Así se ve un reporte de bug bien escrito:

Título: El modal de subida de archivos muestra el toast "Subida exitosa" cuando el archivo supera el límite de 5MB Entorno:
  • Navegador: Chrome 124, Firefox 125
  • SO: Windows 11
  • Build: v2.4.1
  • Entorno: staging
Precondiciones: usuario con sesión iniciada como admin@becomeqa.com Pasos para reproducir:

1. Navegar a https://staging.lab.becomeqa.com/dashboard

2. Hacer clic en el botón "Subir archivo"

3. Seleccionar un archivo de más de 5MB (por ejemplo, un .pdf de 10MB)

4. Hacer clic en "Subir" en el modal

Resultado esperado: la subida falla con un error de validación: "El tamaño del archivo debe ser de 5MB o menos." El archivo no se sube. El toast de éxito no aparece. Resultado actual: el modal se cierra y aparece brevemente el toast "Subida exitosa". Al navegar a la sección Archivos, el archivo no está presente, lo que indica que la subida falló silenciosamente. No se comunica ningún error al usuario. Severidad: Mayor. Los usuarios pierden su subida sin ningún feedback y pueden no darse cuenta de que el archivo no se guardó. Prioridad: Alta. Afecta a cualquier usuario que intente subir archivos que superen el límite de tamaño. Adjuntos: [captura mostrando el toast de éxito] [log de red mostrando la respuesta 413]

Este reporte le da a un desarrollador todo lo necesario: reproducción exacta, comparación clara de esperado/actual, evaluación precisa de severidad y evidencia.

Errores comunes a evitar

"No funciona" sin decir qué debería pasar. Siempre especifica el comportamiento esperado. Pasos que asumen conocimiento previo. "Iniciar sesión como admin." ¿Cuál admin? ¿Qué URL? ¿Qué credenciales? Precondiciones faltantes. Los bugs que solo ocurren con ciertos datos, ciertos roles de usuario o después de ciertas acciones anteriores necesitan ese contexto en la sección de precondiciones. Títulos de una sola línea. "Bug de pago reportado." ¿Reportado contra qué escenario? Inflación de severidad. Llamar Critical a todo hace que Critical pierda significado. Resérvalo para pérdida de datos, problemas de seguridad y funciones completamente rotas para todos los usuarios. Sin limpieza de datos de test. Si tus pasos de reproducción crearon datos de test (un nuevo usuario, un pedido, un archivo), anótalo para que alguien pueda limpiar sin necesitar un administrador de base de datos.

FAQ

¿Debería escribir reportes de bugs para cada problema que encuentro?

Registra todo lo que no funciona como debería. Los desarrolladores y los product owners pueden cerrar o bajar la prioridad, pero no pueden corregir lo que no conocen. La excepción son las cosas de las que no estás seguro si son bugs: plantéalas primero en un comentario o un mensaje rápido.

¿Qué hago si no puedo reproducir el bug de forma consistente?

Igual regístralo. Anotá en el reporte: "Intermitente: reproducido 3 de 10 intentos. No se pudo identificar un gatillo consistente." Adjuntá un video de una reproducción. Un bug intermitente registrado es mejor que uno que no lo está.

¿Qué tan detallados deben ser los pasos de reproducción?

Lo suficientemente detallados para que un desarrollador que acaba de unirse al equipo pueda reproducirlo sin hacerte una sola pregunta. Si tienes dudas, yérrate del lado de más detalle.

Mi bug se marcó como "by design". ¿Estaba equivocado/a?

No necesariamente. "By design" significa que el product owner decidió que el comportamiento actual es aceptable. Es un resultado legítimo. Lo que importa es que documentaste el comportamiento claramente. Si está causando confusión en los usuarios, esa conversación debería ocurrir antes de que se tome la decisión de producto, no después.

→ See also: Cómo Escribir un Caso de Prueba: Formato, Ejemplos y Errores Comunes | ¿Qué Es el Testing Manual? La Guía Completa para 2026