Cómo documentar un error para que un desarrollador pueda reproducirlo
Prepara un reporte útil con pasos, resultado esperado, contexto y evidencias, sin compartir contraseñas ni datos personales.
Un reporte útil permite entender qué intentabas hacer, qué ocurrió y en qué condiciones. No necesitas identificar la causa ni utilizar términos técnicos: describir una secuencia concreta suele ayudar más que proponer una solución sin pruebas.
1. Resume el fallo como una acción
En lugar de «la web no funciona», escribe algo como «el formulario de contacto muestra confirmación, pero la consulta no aparece en el panel». Es un ejemplo ficticio: la frase identifica el recorrido sin asegurar dónde está el problema.
Indica si impide trabajar, afecta a algunas personas o solo cambia el aspecto visual. Describe el impacto sin inventar un nivel de urgencia.
2. Anota los pasos mínimos
Empieza por el estado inicial: sesión iniciada o cerrada, página y permisos del usuario. Después enumera las acciones hasta el fallo.
No repitas una operación real que pueda cobrar, enviar mensajes, eliminar información o crear pedidos. En esos casos registra lo que ya ocurrió y pide una prueba aislada.
Si el error es intermitente, dilo. Anota cuántos intentos observaste y sus horas en lugar de afirmar que sucede siempre.
3. Separa lo esperado de lo observado
«Esperaba recibir una confirmación» y «aparece un mensaje de error» son datos distintos. Copia el texto exacto del error si no contiene información sensible. Si no sabes qué debería pasar, explica el objetivo de negocio.
Evita atribuirlo automáticamente a la última actualización. Puedes señalar que coincidió con un cambio, pero la coincidencia todavía no demuestra la causa.
4. Añade contexto y evidencias seguras
Incluye fecha y hora con zona horaria, navegador, dispositivo y versión de la aplicación si la conoces. En una captura o vídeo breve muestra solo lo necesario.
Oculta nombres de clientes, correos, direcciones, datos de pago y secretos. No envíes contraseñas, cookies, tokens ni archivos completos de configuración. Las URLs también pueden contener información sensible.
Si te solicitan registros técnicos, comparte un extracto revisado por un canal adecuado. No adjuntes un archivo de tráfico del navegador sin revisarlo: puede contener sesiones o datos enviados.
5. Usa esta plantilla
Resumen:
Sistema o página afectada (sin secretos en la URL):
Fecha, hora y zona horaria:
Navegador y dispositivo:
Perfil o permisos, sin identificar a la persona:
Estado inicial:
1. Primera acción:
2. Segunda acción:
3. Momento del fallo:
Resultado esperado:
Resultado observado y mensaje:
Frecuencia observada:
Impacto en el trabajo:
Cambios recientes conocidos:
Captura o evidencia depurada:
¿Puede repetirse sin efectos reales?:
No hace falta rellenar lo que desconoces. Marcar «no comprobado» evita que quien investiga interprete una suposición como hecho.
6. Cierra el reporte con una comprobación
Cuando recibas una corrección, repite los pasos acordados en el entorno indicado y confirma el resultado. Si vuelve a fallar, conserva el reporte y añade nuevas evidencias; no sobrescribas la secuencia original.
En WordPress puedes preparar un entorno de pruebas. Si necesitas que alguien se haga cargo del sistema, revisa continuación de proyectos o el planificador de relevo técnico.