Un reporte de defecto bien escrito es la diferencia entre que tu hallazgo se corrija en el sprint actual o se pierda en un backlog porque nadie entendió qué quisiste decir. Cuando un desarrollador responde con "no lo puedo reproducir", el problema casi nunca es de actitud: es un problema de escritura. Construir un reporte campo por campo, con precisión y sin ambigüedades, elimina ese ida y vuelta que consume tiempo y desgasta equipos.
¿Cómo redactar un título que realmente comunique el bug?
El título es lo primero que todo el mundo lee en el tracker y lo último que muchos redactan bien. Funciona como un titular de periódico: no cuenta toda la historia, pero ofrece suficiente contexto para decidir si vale la pena leer más [0:30].
La fórmula es sencilla: síntoma más ubicación más impacto, todo en una sola oración.
- Ejemplo débil: "Algo está roto en el sitio." No le dice al desarrollador absolutamente nada.
- Ejemplo fuerte: "Botón de login no responde tras ingresar credenciales válidas en Chrome."
Con una línea ya identificas el síntoma — botón muerto —, el dónde — página de login en Chrome — y el impacto — nadie puede entrar. Lo importante es evitar títulos kilométricos que metan pasos de reproducción dentro del título; esos detalles van en el cuerpo del reporte.
¿Por qué los pasos para reproducir son el corazón del reporte?
Si el título es el titular, los pasos para reproducir son la receta de cocina. Omites la temperatura del horno y el plato sale crudo [1:20]. Cada paso debe cumplir reglas claras:
- Una sola acción por línea, numerada y en orden exacto.
- No combinar dos acciones en un mismo paso.
- Incluir siempre los pasos de preparación: si tuviste que loguearte con un rol específico antes de llegar al bug, eso debe estar documentado.
Todo lo que conduce al problema importa. Si el desarrollador no puede llegar al mismo punto de partida, no puede ver el mismo fallo.
¿Qué diferencia hay entre resultado esperado y resultado actual?
Estos dos campos trabajan como pareja inseparable [2:05]. Una prueba pasa cuando coinciden y falla cuando no. El resultado esperado debe estar vinculado a la especificación o al criterio de aceptación, redactado para que alguien pueda verificarlo con un sí o un no.
- Mal ejemplo: "El sistema responde rápido y muestra algo." La palabra "rápido" es subjetiva; "algo" es inútil.
- Buen ejemplo: "El sistema muestra Orden enviada exitosamente dentro de tres segundos tras hacer clic en Enviar."
El resultado actual describe exactamente lo que observaste — solo hechos, cero interpretaciones. Decir "no pasó nada" parece informativo, pero no aclara si la pantalla se congeló, si apareció un error o si cargó una página en blanco.
¿Por qué el entorno decide si el bug se reproduce o no?
Muchos tratan el campo de entorno como opcional, pero frecuentemente es el factor determinante [2:50]. El mismo software se comporta distinto según navegador, sistema operativo o versión del build. Un bug en Safari 17 sobre macOS puede ser invisible en Chrome sobre Windows.
Registra siempre:
- Sistema operativo con versión.
- Navegador con versión exacta.
- Tipo de dispositivo.
- Versión de la aplicación.
- Tasa de reproducción: ¿se repite cada vez o una de cada cinco?
Un defecto intermitente se gestiona de manera completamente diferente a uno constante, y esa distinción solo es posible si documentas la frecuencia.
¿Cómo saber si tu reporte está listo para enviarse?
Hazte esta pregunta: ¿podría un compañero que no sabe nada de este bug seguir mis pasos y llegar al mismo problema? [3:30] Si la respuesta es sí, envíalo. Si dudas, revisa estos puntos:
- Cada paso es una sola acción.
- El entorno está completo.
- Hay evidencia visual adjunta: capturas anotadas para bugs de interfaz, grabación corta para bugs de flujo, logs para errores de backend.
En la siguiente sesión se abordarán dos dimensiones adicionales: severidad y prioridad. Aunque suenan parecido, representan conceptos distintos — la severidad mide el impacto técnico del defecto, mientras que la prioridad refleja la urgencia desde la perspectiva de negocio [4:20]. Separar ambas permite que cada bug reciba la atención que realmente necesita.
¿Cómo es el proceso de reportes en tu equipo? Comparte qué campo te cuesta más completar y qué estrategia usas para que tus reportes no generen preguntas de vuelta.
