Cómo dictar un informe de errores que otra persona pueda reproducir

«Volvió a fallar» es un informe sincero. También es difícil de resolver. Para cuando abres el gestor de incidencias, la pantalla, el botón y el resultado exactos ya se han desdibujado en tu memoria. Dictar un informe de errores puede conservar esos detalles mientras aún están frescos, pero solo si organizas lo que vas a decir antes de empezar.

Este es un proceso breve para convertir un fallo observado en un informe que otra persona pueda reproducir. Sirve tanto si estás probando un proyecto personal como si registras una incidencia en el trabajo o ayudas a mantener una herramienta de código abierto. Aun así, tendrás que escribir los comandos exactos y revisar el informe final. La voz sirve para contar lo que ocurrió, no para inventar pruebas.

Empieza por el fallo, no por un diagnóstico

Los informes de errores se desvían cuando el título anuncia una teoría: «La caché de la base de datos está rota». Puede que tengas razón, pero quien investigue necesita primero saber qué observaste. Un título mejor nombra la acción y el resultado: «Al guardar un borrador se borra el idioma seleccionado en Configuración». Eso se puede comprobar sin aceptar tu teoría sobre la causa.

La misma regla ayuda al dictar. Di en una frase qué tarea intentabas completar y, en otra, qué hizo el software en su lugar. No empieces con una larga historia de tu semana ni con una suposición sobre qué subsistema falló. Si el problema es intermitente, dilo. Si ocurre siempre en tu equipo, dilo también, pero no afirmes que le pasa a todo el mundo.

La guía de GitHub para crear una incidencia explica cómo introducir un título y un cuerpo descriptivos, y señala que un repositorio puede proporcionar una plantilla de incidencias. Úsala cuando exista. La estructura para dictar que aparece abajo te ayuda a reunir los hechos antes de rellenar sus campos; no es motivo para ignorar las instrucciones del propio proyecto.

La nota de voz de cinco campos

Abre un borrador privado en blanco en lugar de publicar directamente en un gestor de incidencias público. Haz clic en el editor y dicta cinco campos breves, cada uno en una línea nueva. El primer borrador debe sonar como el relato de un testigo, no como unas notas de lanzamiento pulidas:

1. Contexto: ¿Qué intentabas hacer? Indica la página, función u operación.
2. Pasos: ¿Qué acciones provocaron el fallo? Numéralas en orden.
3. Esperado: ¿Qué resultado esperabas razonablemente?
4. Real: ¿Qué ocurrió en pantalla? Cita un mensaje de error breve solo después de comprobarlo.
5. Alcance: ¿Cuándo ocurrió, en qué entorno y puedes repetirlo?

Aquí tienes una plantilla para copiar y pegar. Sustituye cada texto entre corchetes por un detalle observado. Si desconoces un campo, escribe «no comprobado» en vez de rellenarlo con una respuesta plausible.

Título: [acción] provoca [resultado observado]
Contexto: Intentaba [objetivo] en [función/página].
Pasos para reproducirlo:
1. [estado inicial exacto]
2. [primera acción]
3. [siguiente acción]
Esperado: [lo que debería haber ocurrido]
Real: [lo que ocurrió, incluido el texto del error comprobado]
Frecuencia: [una vez / a veces / en cada intento en este dispositivo]
Entorno: [versión de la aplicación, sistema operativo, navegador si procede]
Pruebas: [captura de pantalla segura o registro sin datos sensibles, si resulta útil]

No leas los corchetes en voz alta esperando que se conviertan en una estructura. Escribe primero los encabezados en el editor y después dicta el contenido de cada campo. Si usas un teclado de voz de escritorio como Talkpad en macOS o Windows, coloca el cursor en tu borrador privado y dicta un campo cada vez. Así será más fácil parar, inspeccionar y corregir cada parte antes de publicarla.

Reprodúcelo una vez y luego narra los clics

La memoria convierte una secuencia en un resumen. «Cambié un ajuste y la página dejó de funcionar» puede omitir la recarga, el cambio de cuenta o un formulario sin guardar. Repite la secuencia si es seguro hacerlo, con el borrador abierto junto a la aplicación afectada. Detente después de cada acción y anota lo que hiciste. No provoques repetidamente un error que borra datos o genera cargos solo para mejorar la redacción.

Describe los pasos de forma literal: «Abre Configuración, elige español, haz clic en Guardar y vuelve a abrir Configuración». Evita instrucciones como «entra en las preferencias de siempre y haz lo de siempre». Si la aplicación tiene varios botones Guardar, indica el panel. Si el error solo aparece tras recargar, incluye la recarga. Una persona que nunca haya visto tu pantalla debería poder seguir los pasos sin preguntarte por el clic que falta.

Puedes dictar el relato, pero usa el teclado para las cadenas delicadas. Un modelo puede convertir el nombre de un paquete en palabras comunes, cambiar las mayúsculas de una opción o eliminar un signo menos. Pega un seguimiento de pila o un error comprobado desde la aplicación en lugar de dictarlo. Lo mismo se aplica a una versión precisa como 1.4.12. Consulta nuestra guía de nombres y términos técnicos para palabras menos arriesgadas que también requieren una revisión cuidadosa.

Separa lo esperado de lo real

Aquí es donde un informe se vuelve útil. «El formulario falló» no le dice casi nada a quien investiga. «Después de hacer clic en Guardar, apareció la confirmación, pero el idioma volvió a cambiar a inglés al abrir de nuevo Configuración» describe una discrepancia observable. El resultado esperado puede ser igual de sencillo: «El idioma guardado debería seguir siendo español cuando vuelva a abrir Configuración».

No introduzcas una solución propuesta en el campo de resultado esperado. «La aplicación debería usar otra caché» es una sugerencia de implementación, no una expectativa visible para el usuario. Pon cualquier hipótesis en una nota claramente identificada al final, sin ocultar la incertidumbre. Tu colega podría descubrir que la causa es una respuesta de la API, un cliente desactualizado o algo completamente distinto.

Cuando el reconocimiento de voz interpreta mal una negación, el informe puede decir justo lo contrario. Compara «el cuadro de diálogo no se cerró» con «el cuadro de diálogo se cerró». Vuelve a leer esas frases en pantalla antes de presentar el informe. Por eso, nuestro método de revisión que prioriza los riesgos sitúa las negaciones, los números y los nombres por delante de los retoques de estilo.

Añade el entorno sin crear un expediente forense

El entorno mínimo útil suele incluir la versión de la aplicación, el sistema operativo, el navegador si el error ocurre en él y cualquier ajuste necesario para reproducirlo. Indica si puedes reproducirlo en una sesión limpia o en otro dispositivo solo si lo has probado. La hora o el estado de la red importan cuando cambian el resultado; de lo contrario, añaden ruido.

Examina una captura de pantalla antes de adjuntarla. En las esquinas pueden esconderse nombres de usuario, direcciones de correo, tokens, registros de clientes y vistas previas de chats. Recorta la zona relevante o difumina los detalles sensibles con un editor de confianza. Revisa los registros de la misma manera. Si el gestor de incidencias es público, da por hecho que el archivo adjunto también lo será. Si tienes dudas sobre las políticas de tu trabajo, consulta nuestra lista de verificación de privacidad para el dictado antes de dictar material confidencial en cualquier herramienta.

Talkpad puede introducir un borrador dictado en la aplicación donde se encuentra el cursor, pero no comprueba si una captura de pantalla es segura ni si un seguimiento de pila es correcto. Esas comprobaciones te corresponden a ti. Si la política de la empresa restringe el procesamiento de voz para datos de incidentes, síguela y escribe manualmente las partes sensibles.

Dos pasadas de edición antes de publicarlo

La primera pasada sirve para comprobar que el fallo se puede reproducir. Parte del estado inicial indicado y sigue tus pasos al pie de la letra. ¿Aparece el fallo? ¿Son distintos y comprensibles los resultados esperado y real? ¿Omitiste un paso de inicio de sesión o un ajuste que cambia el resultado? Si no puedes reproducirlo de nuevo, modifica el campo de frecuencia para reflejarlo en vez de ocultar la incertidumbre.

La segunda pasada se centra en los riesgos. Contrasta las versiones y el texto de los errores con sus fuentes. Elimina los secretos del cuerpo y de los archivos adjuntos. Sustituye las especulaciones por hechos observables o márcalas como hipótesis. Acorta la introducción si retrasa la llegada a los pasos. Puedes utilizar el kit de edición de borradores dictados cuando el primer intento llegue como un bloque de discurso en vez de campos bien separados.

Un informe útil no tiene que ser largo. Algunos errores requieren tres pasos y dos frases; otros necesitan un ejemplo controlado. Evita el relleno. El objetivo es que otra persona reproduzca el comportamiento y entienda por qué esperabas algo diferente. Si no puedes explicar el estado inicial, investiga un poco más antes de publicarlo.

Preguntas frecuentes

¿Puedo usar el dictado para escribir un informe de errores?

Sí. Dicta el contexto, los pasos para reproducir el fallo y la diferencia entre el comportamiento esperado y el real en un borrador privado. Escribe y verifica los comandos, mensajes de error, URL y números de versión exactos antes de compartirlo.

¿Qué debe incluir un informe de errores?

Incluye un título descriptivo, el contexto inicial, los pasos ordenados, el resultado esperado, el resultado real, el entorno pertinente y pruebas seguras si hacen falta. Sigue la plantilla de incidencias del repositorio cuando exista.

¿Cómo informo de un error que no puedo reproducir?

Indica que ocurrió una vez o de forma intermitente, registra lo que observaste y el entorno que conoces, y explica qué intentos no lograron reproducirlo. No rellenes los pasos desconocidos con suposiciones.

¿Debo adjuntar registros a una incidencia pública?

Solo después de comprobar que no contienen secretos ni información personal. Elimina o censura los datos sensibles y comparte el fragmento más breve que ayude a explicar el fallo. Sigue las normas de tu equipo sobre incidentes y privacidad.

Descarga Talkpad gratis – 2500 palabras por semana con el plan gratuito.