Reportas un bug. Al día siguiente, el equipo de desarrollo responde: "no reproducible". El ticket se cierra sin arreglar nada.
Lo más probable es que el bug exista de verdad. El problema no es el fallo, es que el report no daba lo necesario para reproducirlo. Y eso, para un QA, es un error propio, no del desarrollador.
La diferencia entre un bug que se soluciona en el siguiente sprint y uno que se queda abierto meses sin que nadie le haga caso casi nunca está en la gravedad del fallo. Está en cómo está escrito el report. En este artículo tienes los campos que lo hacen accionable, la confusión entre severidad y prioridad que resta credibilidad, y los errores más habituales al reportar.
Los campos que hacen que un bug sea accionable
Un bug report no es un desahogo ("esto no funciona"), es una herramienta de comunicación entre tú y quien va a arreglarlo. Cuantos menos huecos deje, menos idas y vueltas hará falta antes de que alguien se ponga a corregirlo.
- Título descriptivo. No "el botón falla", sino qué falla, dónde y en qué condición: "El botón de pago muestra el precio original tras aplicar un cupón válido".
- Pasos para reproducir. Numerados, exactos, sin dar por hecho ningún paso previo. Si tú tuviste que hacer login con un usuario concreto, dilo.
- Resultado obtenido vs esperado. Qué pasó de verdad y qué debería haber pasado según la historia de usuario o los criterios de aceptación.
- Severidad y prioridad. Dos campos distintos, con significados distintos (lo vemos en la siguiente sección).
- Entorno. Navegador y versión, sistema operativo, dispositivo, entorno (staging, producción) y build o versión de la app.
- Evidencia. Captura, vídeo o, en bugs de API, la petición y respuesta completas. La que de verdad demuestre el fallo, no una genérica por costumbre.
Faltar solo uno de estos campos ya puede ser motivo suficiente para que alguien no consiga reproducir el bug a la primera.
- Título: "El pago no funciona"
- Pasos: ninguno
- Entorno: no especificado
- Evidencia: ninguna
"Con el cupón BIENVENIDO10 aplicado, el botón de pago cobra 49€ en vez de 44,10€. Reproducido en Chrome 126, checkout de /curso-qa-junior, con captura adjunta del precio incorrecto."
Severidad vs prioridad: la confusión que resta credibilidad
Es una de las preguntas más repetidas en entrevistas técnicas de QA junior, y también una de las que más se confunden en el día a día.
Severidad es el impacto técnico del fallo en sí mismo: cuánto rompe la funcionalidad, con independencia de cuándo haya que arreglarlo. Prioridad es la urgencia para corregirlo dentro del trabajo del equipo.
Son ejes distintos y no siempre van de la mano. Un bug puede tener severidad alta pero prioridad media, si afecta a una funcionalidad que todavía no está en producción. O severidad baja pero prioridad alta, si está bloqueando a otras personas del equipo para seguir trabajando.
| Severidad | Qué significa | Ejemplo |
|---|---|---|
| Crítica | El sistema cae o una función clave deja de funcionar por completo | El checkout no permite completar ningún pago |
| Alta | Una función importante falla, pero hay una vía alternativa | El cupón no descuenta el precio, pero se puede pagar el precio completo |
| Media | Afecta a la experiencia sin bloquear el flujo principal | El mensaje de error de un cupón inválido no se traduce al español |
| Baja | Detalle visual o cosmético, sin impacto funcional | Un icono desalineado dos píxeles en móvil |
El bug que más rebotes me ha dado en un ticket no fue el más raro de reproducir, fue uno donde puse "prioridad alta" sin más contexto. El equipo me pidió que explicara por qué era urgente frente a otros diez bugs abiertos esa semana. Desde entonces, siempre justifico la prioridad en una frase: a quién bloquea o qué usuario afecta ahora mismo.
Errores que hacen que un bug report se rebote
- Título vago. "No funciona" no dice nada útil a nadie que no haya visto el fallo con sus propios ojos.
- Pasos incompletos. Omitir el paso previo que a ti te parecía obvio (el usuario con el que iniciaste sesión, el dato de prueba que usaste) es la causa más habitual de un "no repro".
- Mezclar varios bugs en un mismo ticket. Cada fallo debe poder solucionarse, verificarse y cerrarse por separado.
- Opinión en vez de dato observado. "Esto es confuso para el usuario" es una opinión de UX, no un bug, salvo que contradiga un criterio de aceptación concreto.
- Sin entorno. Un bug que solo aparece en Safari o en una resolución móvil concreta puede pasar semanas sin reproducirse si nadie sabe dónde buscarlo.
Si quieres ver un bug report completo aplicado a un caso real, con historia de usuario y casos de prueba incluidos, tienes el ejemplo entero en la página de ejemplos prácticos de QA.
Por qué esto importa más de lo que parece
Escribir bien un bug report no es burocracia. Es la prueba de que sabes comunicar como QA: que puedes convertir "algo va mal" en información que otra persona puede actuar sin tener que perseguirte para pedirte más detalles.
Es también, muy a menudo, la primera prueba práctica que te ponen en una entrevista de QA junior: te dan un fallo y te piden que lo redactes tal cual lo harías en el trabajo. Practicarlo antes con casos reales, no solo con la teoría, es lo que marca la diferencia frente a otros candidatos.
Si estás preparando ese salto, en el curso de QA desde cero se trabaja con casos y bug reports reales, no solo con definiciones.
Preguntas frecuentes
¿Qué diferencia hay entre severidad y prioridad en un bug?
Severidad es el impacto técnico del fallo en sí mismo: cuánto rompe la funcionalidad. Prioridad es la urgencia para corregirlo dentro del trabajo del equipo. Un bug puede tener severidad alta pero prioridad media si afecta a algo que todavía no está en producción, o severidad baja pero prioridad alta si bloquea a otras personas del equipo.
¿Qué pasa si el desarrollador responde que no puede reproducir el bug?
Casi siempre significa que faltan datos en el report: un paso omitido, el entorno exacto o los datos de prueba usados. Antes de insistir en que el bug existe, revisa tu propio report y añade lo que falte: navegador y versión, usuario o rol usado, y los pasos exactos, sin dar nada por hecho.
¿Es necesario adjuntar captura de pantalla o vídeo siempre?
En bugs visuales o de interfaz, sí, casi siempre. En bugs de API o de backend, una captura no aporta nada: ahí la evidencia útil es la petición y la respuesta completas, por ejemplo exportadas desde Postman. La regla general es adjuntar la evidencia que de verdad demuestre el fallo, no una genérica por costumbre.
¿Qué herramientas se usan para gestionar bug reports?
Jira es la más habitual en empresas medianas y grandes, muchas veces con Zephyr para vincular el bug al caso de prueba que lo detectó. Equipos más pequeños o de producto usan GitHub Issues o Linear. La herramienta cambia, pero los campos que un bug report necesita para ser accionable son siempre los mismos.
¿Preguntan por bug reports en las entrevistas de QA junior?
Sí, es una de las preguntas técnicas más repetidas en entrevistas de QA junior en España: qué campos incluye un bug report efectivo y cómo se diferencia severidad de prioridad. Saber explicarlo con un ejemplo propio, no solo de memoria, marca la diferencia frente a otros candidatos.
¿Quieres entrar al sector?
Aprende QA desde cero, con formación práctica y orientada al mercado español.