Un informe de error tiene un solo trabajo: permitir que alguien que nunca ha visto el problema lo reproduzca al primer intento. La mayoría fracasa en eso, y rara vez por falta de esfuerzo. Fracasan por un puñado de costumbres que repiten personas cuidadosas que nunca han visto su propio informe aterrizar en el escritorio de otra persona.
Cada detalle omitido cuesta segundos al escribirlo y horas al recuperarlo: una vuelta por un hilo de comentarios, un desarrollador construyendo un estado en el que usted ya estaba, un ticket cerrado como no reproducible y vuelto a abrir quince días después por otra persona. Usted es la única persona que tendrá ese contexto gratis.
Diez costumbres, en dos grupos. Las seis primeras son criterio, y ninguna herramienta las hará nunca por usted. Las cuatro últimas son contexto que existía en el momento del fallo y que nadie anotó.
- Un título que describe una sensación
- Sin pasos de reproducción
- Sin comportamiento esperado
- Varios bugs en un mismo ticket
- Emoción en lugar de impacto
- No buscar duplicados
- Omitir el entorno
- Describir lo que vio en lugar de mostrarlo
- Saltarse la consola y la pestaña de red
- “En mi máquina funciona”, sin nada adjunto
Si busca el método y no las trampas, el artículo complementario sobre cómo escribir un informe de error perfecto tiene la anatomía de uno bueno.
Lo que solo puede escribir usted
1. Un título que describe una sensación
“El checkout está roto.” “El login no funciona.” “Algo pasa con las imágenes.”
Un título se lee muchas veces y se abre una. Aparece en los resultados de búsqueda, en la reunión diaria, en las notas de versión y en la lista que alguien repasa mientras decide qué coger esta mañana. Un título que podría describir cuarenta defectos distintos hace más lento cada uno de esos momentos.
El patrón es qué se rompió, más dónde o cuándo, más el único detalle que separa su caso del de todos los demás a quienes les funciona.
- Flojo
- Imágenes rotas
- Mejor
- Las imágenes de producto no cargan en Chrome móvil cuando la página se abre desde la búsqueda
Busque una frase que alguien pueda repetir en voz alta sin abrir el ticket.
2. Sin pasos de reproducción
Sin pasos, un desarrollador no está depurando, está adivinando qué hizo usted. Cada suposición
fallida termina en cannot reproduce, el ticket vuelve a usted y el reloj se reinicia.
Los pasos tienen que empezar en un estado que cualquiera pueda alcanzar.
- Flojo
- Ve a mi carrito e intenta pagar
- Mejor
- 1. Inicia sesión como cliente con el carrito vacío. 2. Añade dos artículos cualesquiera. 3. Aplica el código SAVE10. 4. Pulsa Continuar al pago.
Cuatro líneas, y quien lee está de pie donde estaba usted. Dele sus propios pasos a un compañero que no haya visto el fallo. Si vuelve con una pregunta, la pregunta es su paso ausente.
3. Sin comportamiento esperado
“El total está mal” da por hecho que quien lee sabe qué aspecto tiene lo correcto. A menudo no lo sabe, y a veces lo que usted reporta resulta ser una regla que desconocía.
Escriba las dos mitades.
- Flojo
- El descuento está mal
- Mejor
- Esperado: el total muestra 45,00 tras el 10 % de descuento. Real: el total muestra 50,00 y falta la línea del descuento.
Así es también como se descubre que usted y el desarrollador no coinciden en para qué sirve la funcionalidad, una conversación que conviene tener en el ticket y no tres semanas después.
4. Varios bugs en un mismo ticket
Reportar tres problemas juntos parece eficiente. No lo es, porque un ticket tiene un estado. Cuando dos de los tres están corregidos, el ticket no está ni hecho ni sin hacer, y el tercer problema desaparece en silencio bajo una conversación que se lee como terminada.
Un defecto por ticket. Si comparten causa, dígalo y enlácelos.
5. Emoción en lugar de impacto
“Esto es inservible.” “¿Cómo se ha llegado a publicar esto?” “Tercera vez esta semana.”
La frustración es legítima. Un bug acaba de comerse su tarde. Pero desplaza la información que haría que se arreglara, y pone a quien lee a la defensiva justo cuando necesita su atención puesta en el problema.
El impacto sí pertenece a un informe de error. Enúncielo como un hecho y dele a quien haga la clasificación lo suficiente para fijar una prioridad sin adivinar: a cuánta gente afecta, con qué frecuencia, si hay dinero o datos de por medio, si existe una forma de esquivarlo y si antes funcionaba.
- Flojo
- Esto es un desastre, arregladlo YA
- Mejor
- Bloquea el pago a todos los clientes de Safari, sin alternativa, empezó tras la versión del martes
El segundo es mucho más alarmante que el primero, y mucho más probable que se coja hoy. Un bug que impide a una persona cambiar su avatar y un bug que impide pagar a todos los clientes no deberían llegar nunca con el mismo aspecto.
6. No buscar duplicados
Los duplicados cuestan dos veces: una cuando alguien clasifica un informe que ya se conocía, y otra cuando la discusión de un problema queda partida en dos tickets y ninguno guarda la historia completa.
Busque en el gestor el mensaje de error, el nombre de la página y una o dos palabras del título que iba a escribir. Busque también en los tickets cerrados, porque un bug que se corrigió y ha vuelto es una regresión, y decirlo cambia cómo se trata.
Buscar es además la forma más rápida de aprender las palabras que su equipo usa de verdad. Si todos los demás lo llaman cesta y usted lo llama carrito, la siguiente persona que busque no encontrará su informe, y usted no encontrará el suyo.
Lo que el navegador ya sabe
Los cuatro siguientes son de otra naturaleza. Nadie omite la versión del navegador para ahorrarse esfuerzo. La omiten porque anotarla significa salir de la página, buscar una cadena de versión y teclearla en un formulario, y para entonces la pestaña está cerrada.
7. Omitir el entorno
Un bug que ocurre en todas partes y un bug que ocurre en un solo navegador son bugs distintos con causas distintas, y nadie puede saber cuál tiene usted hasta que alguien lo comprueba. Así es como un informe se cierra como no reproducible: el desarrollador lo probó en Chrome y usted estaba en Safari.
Anote el navegador y su versión, el sistema operativo, el dispositivo y el tamaño de la ventana si
el diseño interviene lo más mínimo. Latest Chrome no es una versión. Significa algo distinto el
día en que se lee que el día en que se escribió.
8. Describir lo que vio en lugar de mostrarlo
La prosa es un formato con pérdidas para un problema visual. “El diseño se pone raro más abajo” puede querer decir media docena de cosas, y esa media docena tiene arreglos distintos.
Una captura de pantalla resuelve de golpe los problemas de maquetación y de texto. Una grabación corta va mejor para todo lo que implique tiempos, animación o una secuencia de interacciones. Capture la ventana entera y no un recorte de la parte rota: la barra de direcciones, la consola y la página alrededor contienen a menudo la respuesta.
9. Saltarse la consola y la pestaña de red
Es lo primero que pide un desarrollador y lo último que incluye la mayoría de los informes. Un error en rojo en la consola suele nombrar el archivo y la línea que fallan. Una petición fallida en la pestaña de red suele nombrar el código de estado y el endpoint. Cualquiera de los dos puede convertir una tarde de bisección en una corrección de dos minutos.
Abra las herramientas de desarrollo antes de cerrar la pestaña. Copie el texto del error en vez de fotografiarlo, para que se pueda buscar. Si una petición falló, anote su estado y su ruta.
10. “En mi máquina funciona”, sin nada adjunto
La frase termina una conversación sin resolver nada, y funciona en las dos direcciones. De un desarrollador significa que al informe le faltaba el detalle para reproducirlo. De quien reporta, responder a una corrección con “a mí me sigue fallando” y nada más significa exactamente lo mismo al revés.
En ambos casos la respuesta es evidencia en lugar de afirmación: la versión que probó, el entorno en el que la probó y lo que vio. Un informe sobre una corrección fallida merece el mismo cuidado que el original.
Lo que de verdad resuelve la mitad de esto
Vuelva al segundo grupo. Los errores 7, 8, 9 y 10 son un solo problema con cuatro sombreros: el contexto existía en el momento del fallo y nadie lo anotó.
Esa es la parte que merece automatizarse, y por eso construimos Session Replay.
Session Replay
Extensión gratuita de Chrome. Un clic en la página que se está portando mal captura la captura de pantalla, la consola y el registro de red, y le devuelve un enlace para pegar en el ticket.
No sabe en qué hizo clic. Sabe lo que sabía el navegador. Así que no le escribirá el título, no partirá sus tres bugs en tres tickets ni le dirá qué esperaba usted que pasara. Eso es criterio y sigue siendo suyo. Lo que quita es la excusa de las cuatro costumbres que solo tenían que ver con la fricción, y le deja las seis que tienen que ver con pensar con claridad.
La lista de comprobación
Antes de pulsar enviar:
- El título nombra qué falló, dónde y bajo qué condición
- Los pasos empiezan en un estado que cualquiera puede alcanzar
- El comportamiento esperado y el real están los dos escritos
- Un defecto en este ticket, y solo uno
- Impacto enunciado como un hecho, con lo suficiente para que otro fije la prioridad
- He buscado un informe existente en los tickets abiertos y cerrados
- Navegador, versión, sistema operativo y dispositivo están anotados
- Hay adjunta una captura o una grabación que muestra la ventana entera
- Los errores de consola y las peticiones fallidas están copiados como texto
- Evidencia para todo lo que afirmo, incluido “sigue ocurriendo”