Un reporte de error útil permite que otra persona reproduzca el problema o sepa qué evidencia buscar. No necesitas adivinar la causa para ayudar a resolverlo.
Una ficha que puedes completar
- Tarea: qué intentabas hacer.
- Resultado esperado: qué debía ocurrir.
- Resultado observado: qué apareció o qué faltó.
- Contexto: fecha, hora, pantalla, dispositivo y frecuencia.
- Evidencia: mensaje o captura sin datos sensibles innecesarios.
Ejemplo hipotético: “Al exportar el reporte de esta semana aparece un archivo vacío. El listado muestra registros. Ocurrió hoy a las 10:15 y volvió a ocurrir con el mismo filtro”. Es más útil que “la exportación no sirve”.
Separa hechos de sospechas
Si crees que empezó después de una actualización, indícalo como observación. No cambies configuraciones al azar para demostrar una hipótesis; podrías ocultar el estado que necesita revisar el responsable.
GitHub documenta las incidencias como una forma de registrar y seguir trabajo, con título y descripción. No necesitas contratar otra herramienta para aplicar una ficha equivalente en el canal acordado. Creación de una incidencia.
Facilita la comprobación final
Cuando se informe una corrección, repite la tarea original y anota si el resultado coincide. Si aparece otra falla, distingue si pertenece al mismo recorrido o a una necesidad nueva.
Conserva un identificador para el seguimiento. Repetir la explicación en varias conversaciones puede fragmentar decisiones. Un buen reporte reúne el contexto, la respuesta y la comprobación, sin incluir contraseñas, claves de API o datos de clientes que no sean necesarios.
Un reporte completo sin datos privados
| Campo | Ejemplo ficticio |
|---|---|
| Título | La exportación semanal genera un archivo vacío. |
| Pasos | Abrir reportes, elegir la semana y solicitar exportación. |
| Esperado | Archivo con las filas que muestra el listado. |
| Observado | Archivo creado sin filas; el listado sí tiene información. |
| Contexto | Hora y zona horaria, navegador, filtro y frecuencia por completar. |
| Comprobación final | Repetir con datos de ensayo y contrastar listado y archivo. |
Si no puedes reproducir el fallo, explica cuándo ocurrió y qué cambió desde entonces. “No volvió a pasar” es una observación válida; no la conviertas en “corregido” sin saber qué se comprobó. Mantén en el mismo registro las respuestas y el identificador del caso.
Para profundizar en las tareas relacionadas: Qué información reunir cuando falla un servidor; Cómo investigar un error con registros y depurador.
¿Necesitas ordenar el soporte del negocio?
Cuéntanos qué equipos, cuentas o tareas requieren atención y qué problema se repite. Con ese contexto podemos conversar sobre el soporte que necesitas.
Conocer soporte tecnológico