Cómo redactar un reporte de error que otra persona pueda reproducir

“El sistema falló” indica al equipo de soporte que alguien necesita ayuda, pero no explica qué investigar. Un reporte útil conecta un problema observable con una condición inicial, una secuencia de acciones y un resultado. Otra persona debería poder repetir el intento o entender qué evidencia sigue faltando.

No necesitas diagnosticar el código. Describe con precisión lo ocurrido, explica su impacto y conserva contexto suficiente para que el equipo investigue sin pedirte que reconstruyas toda la situación después.

Separa la observación de la explicación

“Guardar un borrador muestra un error y deja el estado sin cambios” describe un comportamiento. “La base de datos está dañada” propone una causa. Mantén las hipótesis en una nota separada hasta que alguien las verifique.

Las recomendaciones de Mozilla para reportar errores destacan los pasos claros de reproducción y la separación entre resultado observado y esperado. Esa estructura también sirve en aplicaciones empresariales, aunque quien comunica el problema no sea desarrollador.

Dedica cada ticket a un problema principal. Si otro síntoma pudiera estar relacionado, enlázalo y explica la conexión, en lugar de agrupar fallos independientes en un mensaje largo que después resulte difícil cerrar.

Copia esta estructura de reporte

• Título: acción, área afectada y fallo visible.
• Entorno: producción o pruebas, versión de la aplicación, navegador o dispositivo y sistema operativo.
• Momento: cuándo ocurrió, incluyendo la zona horaria.
• Condiciones iniciales: rol, estado relevante del registro y disponibilidad de conexión.
• Pasos: acciones numeradas con nombres exactos de controles y datos necesarios para repetirlas.
• Resultado esperado: comportamiento acordado y referencia del requisito o proceso, cuando exista.
• Resultado observado: qué apareció, qué cambió y el texto exacto del error.
• Frecuencia: cuántos intentos controlados fallaron, o si todavía se desconoce la recurrencia.
• Impacto y alternativa: tarea del negocio bloqueada y cualquier solución provisional verificada.
• Evidencia: referencias seguras de registros, una captura enfocada y un identificador de petición o registro técnico autorizado, si existe.

Marca como desconocidos los campos que no puedas completar. Inventar una versión, una cantidad de usuarios afectados o una causa resta fiabilidad. No añadas contraseñas, tokens de sesión, datos de pago ni información innecesaria de clientes para que el reporte parezca más completo.

Ejemplo: no se guarda un borrador

El siguiente caso es ficticio y utiliza un entorno de pruebas:

Título: Modificar la nota de un servicio impide guardar su borrador. Entorno: Portal de pruebas, versión TEST-42; las versiones del navegador de escritorio y del sistema operativo están adjuntas a la ficha. Momento: Registrado con zona horaria en el ticket. Condición inicial: Rol Operador, solicitud ficticia DEMO-17, estado Borrador, con conexión.

1. Abre DEMO-17 desde Mis solicitudes.
2. Selecciona Editar nota y sustituye el texto por “Acceso por la puerta confirmado”.
3. Selecciona Guardar borrador una vez.

Esperado: La nota se guarda, la solicitud sigue como Borrador y al abrirla aparece el texto nuevo. Observado: Aparece “No se pudo guardar”; al abrirla permanece el texto anterior. Frecuencia: Fallaron los dos intentos controlados. Impacto: El operador no puede conservar la nota actualizada. Alternativa: Ninguna verificada. Evidencia: Captura con información sensible ocultada y referencia de prueba adjuntas.

El desarrollador recibe un punto de partida sin que el reporte atribuya una causa. Si no logra reproducirlo en otro lugar, el entorno y el estado del registro siguen siendo pistas útiles.

Recoge evidencia sin crear otro problema

Prefiere una captura recortada del control y del error. Revisa la barra de direcciones, ventanas de fondo, notificaciones y campos visibles antes de compartirla. Utiliza el canal aprobado para cualquier material que necesite acceso restringido.

No repitas operaciones que puedan cobrar, enviar, borrar o crear registros solo para mejorar el reporte. Anota que el resultado es incierto y deja que el responsable compruebe primero el destino. La reproducción con efectos de negocio debe realizarse en un entorno controlado.

Si no puedes reproducir el problema, indícalo. Incluye la última acción exitosa conocida, la hora aproximada y cualquier referencia visible. Un fallo intermitente puede merecer investigación; simplemente tiene un límite de evidencia distinto.

Cierra con una repetición concreta

Cuando haya una corrección, repite los pasos originales en la versión identificada. Comprueba el estado guardado al abrir otra vez el registro y prueba una variante cercana, como guardar sin modificar la nota. Documenta el resultado y cualquier problema pendiente.

Contacta con Dynelink para definir un proceso de reporte y verificación que convierta quejas imprecisas en trabajo reproducible y útil para tu equipo.