Cuando un usuario hace clic en el botón de reporte, pasan bastantes cosas que nunca ve. Aquí están todas, y por qué está cada una.
Logs de consola, también los del pasado
La obvia, con un detalle que no lo es: BugDump captura los logs de antes de que se abriera el widget.
Esto importa más de lo que parece. La secuencia de un reporte de bug real casi nunca es «ocurre un error y el usuario lo reporta en el acto». Es así: ocurre un error, la página entra en un estado sutilmente roto, el usuario prueba tres cosas más, se confunde y lo reporta cuatro minutos después.
Un recolector que arranca al abrir el reporte captura esos cuatro minutos de confusión y se pierde el error que los causó. El SDK instala su recolector de consola al inicializarse, así que el error original sigue ahí cuando por fin se envía el reporte.
Peticiones de red
Método, URL, código de estado, tiempos. Aquí es donde viven de verdad la mayoría de los bugs: no en el código de tu frontend, sino en la respuesta que recibió.
Los cuerpos de petición y de respuesta están disponibles con captureNetworkBodies, y vienen desactivados por defecto. Ese valor por defecto es deliberado. Los cuerpos son el sitio donde con más probabilidad aparecen tokens de autenticación, datos personales y datos de pago. Activarlo debería ser una decisión que tomas tú, no un valor por defecto que heredas.
Incluso sin cuerpos, los códigos de estado y los tiempos resuelven la mayoría de los bugs. Un 500 justo antes de que el usuario se rindiera es tu bug. Un 200 que tardó nueve segundos también es tu bug, y uno que tu rastreador de errores nunca reportó.
Capturas de pantalla y la herramienta de difuminar
Las capturas de pantalla vienen en dos variantes, y vale la pena entender qué se gana y qué se pierde con cada una.
screen-capture usa getDisplayMedia. Es exacta al píxel: canvas, video, iframes de otros orígenes, selects nativos, todo capturado tal como se ve. El precio es un diálogo de permisos del navegador.
dom renderiza a partir del DOM con html2canvas. Sin aviso, así que sin fricción, pero el contenido de canvas y los iframes de otros orígenes pueden no sobrevivir.
Por defecto uso screen-capture, y si el usuario deniega el permiso se pasa automáticamente a dom. Un permiso denegado debería empeorar la captura, no hacer que se pierda el reporte.
Luego viene la anotación: flecha, rectángulo, dibujo a mano alzada, texto y difuminado. La herramienta de difuminar es la que merece destacarse, porque es un control de privacidad disfrazado de herramienta de dibujo. Los datos se ocultan en el navegador: una zona difuminada nunca se sube. Usuarios que de otro modo no enviarían una captura de una página con datos de clientes ahora pueden enviarla.
Repetición de sesión
Una grabación del DOM a lo largo del tiempo, hecha con rrweb. No es un video: es una repetición del documento real, que puedes inspeccionar.
La repetición se gana su sitio en ese tipo de bug en el que la consola está limpia, la red está limpia y el usuario está absolutamente seguro de que algo se rompió. Normalmente tiene razón, y normalmente lo que hizo no es lo que describió. La repetición te enseña la diferencia.
Acciones
Clics, entradas de texto y navegación, en orden.
Es la señal más humilde y una de las más útiles, porque son tus pasos para reproducir, grabados en lugar de recordados. «Pasos para reproducir» es el campo que peor rellenan los usuarios, y el que más necesitas. Así que dejé de preguntar y empecé a grabar.
Notas de voz
Hay usuarios que no escriben tres frases pero hablan encantados durante veinte segundos. La frustración también lleva información que el texto aplana: oyes qué parte del flujo fue la que de verdad los sacó de quicio.
Tiempos de rendimiento
Carga de la página y tiempos de los recursos, para los reportes que en realidad tratan de lentitud. «La app va lenta» es un reporte de bug real, y sin tiempos es uno imposible de refutar.
Metadatos
Navegador, sistema operativo, tamaño del viewport, URL de la página, marca de tiempo.
El viewport es el que pasa desapercibido. Una parte sorprendente de los reportes de «el botón no funciona» son bugs de maquetación en un ancho que nadie probó. Los usuarios casi nunca piensan en mencionar el tamaño de su ventana. Es un número, se captura automáticamente y cierra una categoría de bugs que, si no, es realmente difícil de reproducir.
Lo que BugDump no hace, a propósito
No exige la identidad de quien reporta. El nombre y el correo están en una sección plegada. Un reporte sin nombre sigue siendo un reporte; un formulario que exige identidad recibe menos.
No exige título, categoría, gravedad ni prioridad. Son campos de triaje disfrazados de campos de reporte. Los usuarios los rellenan a ojo, se equivocan y tú vuelves a hacer el triaje igualmente. El único campo obligatorio es la descripción.
No se mete en tu página. El widget se renderiza dentro de un Shadow DOM. Tu CSS no lo alcanza, y su CSS no te alcanza a ti.
La regla que lo une todo
Cada señal de esta lista sigue una regla: si el navegador ya lo sabe, el usuario no debería tener que decirlo.
El trabajo del usuario es una frase sobre lo que esperaba. Todo lo demás es trabajo de BugDump, y el navegador ya ha hecho la mayor parte.
Te puede interesar
Plantilla de reporte de bug que sí funciona (y cómo automatizarla) — una plantilla para copiar y por qué conviene borrar del formulario todos los campos que puede rellenar una máquina.
Repetición de sesión sin vigilancia — una grabación limitada a un reporte, en la que el usuario puede ocultar datos y que se desactiva con una línea.
Cómo capturar logs de consola y peticiones de red del navegador del usuario — qué parchear y en qué orden, y las trampas que hacen que una captura ingenua rompa la página que vigila.