Busca «plantilla de reporte de bug» y encontrarás cien variantes del mismo formulario. Título, entorno, pasos para reproducir, resultado esperado, resultado real, gravedad, capturas de pantalla. Cópiala en tu gestor de incidencias y, en un mes, prácticamente nadie la rellena.
Esto suele diagnosticarse como un problema de disciplina. No lo es. Es un problema de diseño: la plantilla le pide a una persona que transcriba información que una máquina ya tiene, y las personas, con razón, se niegan a hacer un trabajo tedioso sin recompensa visible.
Así que este post tiene dos mitades. Primero, una plantilla para copiar que vale la pena conservar. Después, el argumento más útil: qué campos borrar, porque debería rellenarlos otra cosa.
La plantilla
## Resumen
Una frase. Qué está roto, desde el punto de vista del usuario.
## Pasos para reproducir
1.
2.
3.
## Esperado
Lo que creías que iba a pasar.
## Real
Lo que pasó en su lugar.
## Impacto
¿A quién afecta, con qué frecuencia y hay alguna forma de sortearlo?
## Entorno
Navegador / sistema operativo / dispositivo / versión de la app / URL / tipo de cuenta con la que iniciaste sesión
## Pruebas
Captura de pantalla, grabación, salida de la consola, petición fallida, ID de la peticiónEso es todo. Aquí no hay nada nuevo: el valor está en para qué sirve de verdad cada campo, que es justo donde fallan la mayoría de las plantillas.
Resumen
El campo que más a menudo se rellena mal. Un buen resumen se escribe desde fuera: «El botón de pagar no hace nada en el paso de pago con tarjetas guardadas». Uno malo se escribe desde dentro de una suposición: «Condición de carrera en el token de Stripe».
Las suposiciones en el título hacen daño porque condicionan a todos los que leen el reporte después. En los bugs mal titulados, la mitad del tiempo de triaje se va en desmentir un diagnóstico que inventó quien lo reportó y que nadie cuestionó.
Pide la observación. El diagnóstico es trabajo de quien lo arregla.
Pasos para reproducir
El campo que todo el mundo sabe que importa y que casi todo el mundo escribe mal, de una forma concreta: quien reporta escribe los pasos que cree relevantes, no los pasos que dio.
Se salta «tenía dos pestañas abiertas». Se salta «llevaba como una hora en la página». Se salta «entré desde el enlace del correo, no desde el menú». Esas omisiones suelen ser el bug.
La instrucción que ayuda: escribe lo que hiciste, desde que abriste la página, incluidas las partes aburridas.
El estado inicial importa tanto como las acciones. ¿Con qué cuenta habías iniciado sesión? ¿Qué datos había ya en la cuenta? ¿Con qué plan? Una reproducción que empieza desde una cuenta nueva a menudo no reproduce nada.
Esperado y real
Al lado del resumen parecen redundantes. Consérvalos de todos modos.
Separarlos detecta toda una clase de reportes que no son bugs: casos en los que el software se comporta exactamente como se diseñó y el usuario esperaba otra cosa. Eso es real y vale la pena saberlo (es un bug de documentación, de UX o del discurso de ventas), pero no es un defecto del código, y es muchísimo más barato identificarlo en el triaje que después de dos días de investigación.
El par también obliga a ser preciso. «No funciona» no sobrevive a que lo partan en esperado y real. Dejar vaga una de las dos casillas da vergüenza.
Impacto
El campo que la mayoría de las plantillas omite, y el que más determina lo que pasa después.
Los desplegables de gravedad no funcionan. Todo el que reporta elige «Alta», porque desde dentro de su tarea bloqueada todo parece grave. Pide en cambio las tres cosas que la gravedad intenta medir:
Quién: ¿solo yo, todo mi equipo, todos los clientes que usan Safari?
Con qué frecuencia: ¿una vez, siempre, más o menos una de cada diez?
Alternativa: ¿hay otra forma de hacer el trabajo?
«Siempre, todos los usuarios en dispositivos móviles, sin alternativa» y «una vez, solo yo, al recargar se arregla» se ordenan solos sin que nadie toque un desplegable. Y «una de cada diez» aporta más de lo que parece: intermitente significa condición de carrera, caché o dependencia de la carga, y eso orienta dónde buscará quien desarrolla antes de haber mirado en ningún sitio.
Entorno
Necesario, y el peor uso del tiempo de una persona de toda esta lista. Vuelvo a él más abajo.
Pruebas
Las capturas de pantalla son lo habitual, y son la prueba más débil de las que se usan a menudo. Una captura demuestra que la página se veía mal. No dice nada del porqué.
Ordenadas por lo que de verdad resuelve bugs:
La petición que falla: método, URL, código de estado, cuerpo de la respuesta y un ID de petición o de traza si lo tienes. Un ID de petición convierte un reporte del lado del cliente en una búsqueda en los logs del servidor, que es el camino más corto que existe del reporte a la causa raíz.
El error de consola con su stack: apunta a una línea de código.
Una grabación: muestra tiempos y secuencia, cosa que una captura no puede.
Una captura de pantalla: muestra el estado final.
La mayoría de las plantillas piden la cuarta y nunca mencionan las tres primeras, porque las tres primeras requieren DevTools y quien reporta no tiene DevTools abierto.
Ahora borra casi todo
Vuelve a mirar la plantilla y ordena los campos según quién puede rellenarlos.
Solo puede rellenarlos una persona: resumen, pasos para reproducir, esperado y la parte de «quién y con qué frecuencia» del impacto. Requieren intención. Ninguna instrumentación sabe qué intentaba conseguir alguien ni qué esperaba ver.
Una máquina puede rellenarlos, y mejor: entorno, comportamiento real y los cuatro tipos de prueba.
Cada campo del segundo grupo es un campo en el que le pides a una persona que haga peor un trabajo que un script haría mejor, y lo pagas en reportes abandonados.
Piensa en lo que pide de verdad «Entorno». Navegador y versión exacta: la mayoría no sabe encontrarla. Versión del sistema operativo: lo mismo. Tamaño del viewport: nadie lo sabe, y es el campo que habría explicado el bug de maquetación. URL de la página: pegarán la URL de la página en la que están ahora, que es tu formulario de soporte. Versión de la app o hash del build: invisible para ellos por diseño.
Seis datos, todos trivialmente legibles desde el navegador, y cada uno exige una ida y vuelta con soporte cuando se le pide a una persona.
El mismo argumento pesa todavía más en las pruebas. Le estás pidiendo a un usuario no técnico que abra DevTools, encuentre la pestaña de red, reproduzca el bug, identifique cuál de doscientas peticiones es la relevante y copie su respuesta. Es una petición que no va a cumplir. Y es una línea de instrumentación.
Cómo debería ser el formulario
Redúcelo a lo que solo sabe una persona:
## ¿Qué salió mal?
[texto libre]
## ¿Qué esperabas que pasara?
[texto libre]
## ¿Te había pasado antes?
( ) Primera vez ( ) A veces ( ) SiempreTres campos. Treinta segundos. Mientras tanto, el reporte llega con el navegador, el sistema operativo, el viewport, la URL, la consola con todo lo que se registró antes de abrir el reporte, el registro de red con códigos de estado y tiempos, una repetición de sesión de los últimos minutos y los clics y entradas del usuario en orden.
Ese es el intercambio del que trata todo esto: la persona escribe la frase que solo ella puede escribir, y la máquina adjunta todo lo demás.
Es lo que hace BugDump. Una etiqueta script pone un botón de reporte en la página; el usuario escribe qué salió mal; el reporte llega con la telemetría ya adjunta, junto con una captura de pantalla anotada que puede difuminar antes de que salga de su navegador. El plan Gratis incluye 500 reportes por proyecto.
Dos cosas que hay que seguir haciendo a mano
Automatizar la captura no lo automatiza todo, y conviene tener claros los límites.
El triaje sigue necesitando a una persona. Doce reportes del mismo proceso de pago roto deberían convertirse en una tarea con doce pruebas, y solo una persona reconoce que son el mismo bug. En esa agrupación los reportes duplicados dejan de ser ruido y se convierten en datos: doce reportes en cinco navegadores y dos sistemas operativos son una matriz, y el patrón que hay en ella suele señalar la causa. BugDump lo modela tal cual: los reportes son pruebas, las tareas son lo que arreglas, y muchos reportes se adjuntan a una sola tarea.
Cerrar el ciclo sigue necesitando a una persona. Un reporte enviado al vacío le enseña a alguien a no volver a reportar. Uses la herramienta que uses, quien reporta tiene que ver que lo que envió avanzó. Dale una página de estado, o mándale un mensaje cuando salga el arreglo: un portal público en el que pueda ver su tarea pasar de Confirmado a Hecho es la versión más barata de esto que funciona.
Las plantillas son un sustituto del objetivo real, que es un reporte con el que quien desarrolla puede actuar sin hacer una pregunta de seguimiento. Si un formulario te lleva hasta ahí, usa el de arriba. Si la instrumentación te lleva sin formulario, es estrictamente mejor: la mejor plantilla de reporte de bug es la que nadie tiene que rellenar.
Te puede interesar
Cómo escribir un buen reporte de bug (con checklist) — qué separa un reporte que se arregla de uno que se cierra como «no reproducible», con una lista para revisar antes de enviarlo.
Anatomía de un reporte de bug: qué captura BugDump y por qué — cada señal que recoge el widget, por qué se gana su sitio y cuáles resuelven bugs de verdad.
Reporte de bugs en QA y UAT: cómo hacer eficaces a los testers no técnicos — por qué una ronda de UAT acaba en una hoja de cálculo con la mitad de filas inservibles, y cómo conservar las pruebas.