Plantilla de reporte de errores (bugs): gratis, con ejemplos

Una plantilla de reporte de errores es la forma más rápida de que los fallos de una web se arreglen a la primera. Si quien desarrolla recibe «el formulario no va», tiene que hacer cuatro preguntas antes de empezar; si recibe la URL, la versión del navegador, tres pasos y una captura marcada, normalmente lo reproduce en pocos minutos. La plantilla gratis funciona en Excel, Google Sheets y Word, y los ejemplos de más abajo muestran la diferencia entre un reporte que se resuelve y uno que vuelve con preguntas.

¿Qué es un reporte de errores?

Un reporte de errores (o informe de bugs) es una descripción escrita de un fallo de software con la información suficiente para que alguien pueda reproducirlo, entenderlo y corregirlo. En una web, eso significa dónde ocurre, en qué dispositivo y navegador, cómo provocarlo y qué debería haber pasado. Uno bueno se puede resolver sin hacer una sola pregunta de vuelta.

Un reporte de errores no es una queja ni una petición de funcionalidad. «Quiero el menú en verde» es un cambio. «El menú no se abre en el iPhone» es un error. Conviene separarlos, porque los cambios suelen requerir hablar de presupuesto y los errores no.

¿Qué debe incluir un reporte de errores?

Bastan diez campos: un título concreto, la URL, el navegador y su versión, el sistema operativo, el tamaño de pantalla o el dispositivo, los pasos numerados para reproducirlo, el resultado esperado, el resultado real, una captura marcada y una gravedad o prioridad. Los cinco primeros dicen dónde mirar; el resto, qué hacer.

Por qué se gana su sitio cada uno:

• URL: «la página de servicios» pueden ser tres páginas distintas si la web tiene varios idiomas o una versión de pruebas y otra publicada. Copia la barra de direcciones.
• Navegador, sistema y pantalla: muchos errores solo aparecen en un navegador o a un ancho concreto. Sin estos datos, quien desarrolla prueba en su equipo, no ve nada raro y lo cierra como «no se puede reproducir».
• Pasos para reproducirlo: la captura demuestra que el error existe; los pasos explican cómo volver a provocarlo. Empieza desde la carga de la página y numera cada acción.
• Resultado esperado y real: convierte «no funciona» en algo comprobable y a veces revela que lo que se pide es un cambio.
• Captura: una captura marcada elimina cualquier duda sobre a qué elemento te refieres. Dibuja una flecha o un recuadro justo donde está el problema.

Opcional pero útil: si pasa siempre o solo a veces, si tenías la sesión iniciada y con qué rol, el idioma del navegador y los errores de consola si sabes abrir las herramientas de desarrollo (Chrome lo explica en su guía de la consola).

¿Cómo se escribe un reporte de errores paso a paso?

Reproduce el error una vez, apunta los pasos exactos desde la carga de la página, anota qué esperabas y qué pasó, registra navegador, sistema y pantalla, haz una captura y marca el problema, y solo entonces escribe el título. Reporta un error cada vez y busca duplicados antes de añadir el tuyo.

1. Reprodúcelo. Si no consigues que vuelva a pasar, dilo («ha pasado una vez, no lo he podido reproducir») en lugar de suponer.
2. Escribe los pasos, numerados desde que carga la página, una acción por línea.
3. Indica el resultado esperado y el real en dos frases cortas, sin diagnóstico.
4. Apunta el navegador y su versión, el sistema operativo y el dispositivo o el tamaño de ventana.
5. Haz una captura y pon una flecha o un recuadro sobre el problema.
6. Escribe el título al final: el sitio más el problema, en unas diez palabras.
7. Busca duplicados en el gestor de incidencias antes de añadir uno nuevo.

Dos hábitos marcan la diferencia. Describe, no diagnostiques: «la imagen principal se ve borrosa» es mejor que «la compresión de imágenes está mal», porque la causa la busca quien desarrolla. Di dónde no ocurre: «en Chrome de escritorio los mismos pasos funcionan» es de las pistas más útiles que puedes dar. Las pautas para escribir bugs de Mozilla (en inglés) dicen lo mismo para cualquier software.

¿Cómo es un buen reporte de errores?

Dice en el título la página y el problema, incluye la URL y el entorno exactos, da pasos numerados que cualquiera puede seguir, separa el resultado esperado del real y señala el problema en una captura. Uno malo dice que algo está roto y deja que quien desarrolla averigüe qué, dónde y en qué dispositivo.

Ejemplo malo:

Título: Formulario roto

¡¡El formulario de contacto no funciona, arregladlo cuanto antes!!

Quien lo recibe no sabe qué formulario es (la web tiene dos), en qué dispositivo pasa, qué significa «no funciona» ni si es más urgente que el resto de tareas.

Ejemplo bueno:

Título: Contacto: el botón Enviar no hace nada en iPhone (Safari)

URL: https://pruebas.ejemplo.es/contacto/
Navegador y versión: Safari 17.5
Sistema operativo y versión: iOS 17.5
Dispositivo / tamaño de pantalla: iPhone 13, 390x844
¿Sesión iniciada? No

Pasos para reproducirlo:
1. Abrir https://pruebas.ejemplo.es/contacto/ en el iPhone
2. Rellenar Nombre, Email y Mensaje con datos válidos
3. Pulsar «Enviar»

Resultado esperado:
Se envía el formulario y aparece el mensaje «Gracias, te escribimos pronto».

Resultado real:
No pasa nada. Ni mensaje ni error, los campos siguen rellenos.
En Chrome 129 de escritorio (Windows 11) los mismos pasos funcionan.

Ocurre: siempre (probado 3 veces)
Gravedad: alta (las visitas desde móvil no pueden contactar)
Captura: adjunta, con el botón Enviar marcado en rojo

El informe bueno cuesta un par de minutos más de escribir y ahorra mucho más que eso en idas y venidas.

Plantilla de reporte de errores para copiar y pegar

Pégala en un email, un documento, una página de Notion o el gestor de incidencias que uséis. Tiene los mismos campos que la plantilla descargable de arriba.

Título: [Página/funcionalidad]: [qué falla], [dónde/cuándo]

URL:
Navegador y versión:
Sistema operativo y versión:
Dispositivo / tamaño de pantalla:
¿Sesión iniciada? (sí/no, con qué rol):

Pasos para reproducirlo:
1.
2.
3.

Resultado esperado:

Resultado real:

Ocurre: [siempre / a veces / una vez]
Gravedad: [crítica / alta / media / baja]
Captura o grabación: [adjuntar, con el problema marcado]
Notas:

¿Se pueden gestionar los errores en una hoja de cálculo?

Sí. Para un solo proyecto web o un equipo pequeño, una hoja de cálculo funciona bien como gestor de errores: una fila por error, con columnas para los campos del informe, la gravedad, la prioridad, la persona responsable y el estado. El Excel de arriba está hecho así, con desplegables de gravedad, prioridad y estado, y funciona igual en Google Sheets.

Para abrirlo en Google Sheets, usa Archivo, Importar y Subir (instrucciones de Google) y compártelo con quienes corrigen y prueban. La hoja empieza a quedarse corta cuando hay varios proyectos a la vez, muchas capturas que adjuntar o hace falta recibir avisos e historial de cambios. Ese es el momento de pasar a un gestor de verdad; en nuestra guía de herramientas gratis de seguimiento de bugs comparamos los planes gratuitos.

¿Cómo llegan los reportes completos a Jira, Trello u otro gestor?

Lo más fiable es dejar de copiarlos a mano. Si clientes y testers reportan desde un widget de feedback visual en la propia web, cada aviso llega con la captura, la URL y los datos del navegador ya rellenos, y puede crearse solo en el gestor que usa tu equipo, así nadie copia emails en tareas.

Aunque tengan plantilla, las personas sin perfil técnico rara vez saben su versión de navegador o su resolución de pantalla, y copiar URLs y marcar capturas a mano lleva tiempo. Ahí llegan los «formulario roto», sobre todo cuando un cliente revisa la web en una ronda de feedback. La solución es capturar los campos técnicos de forma automática para que quien reporta solo escriba lo que tiene que escribir una persona: los pasos, el resultado esperado y el real.

GiveFeedback.io añade un botón «Give Feedback» a tu web con un único fragmento de JavaScript. Cuando alguien lo pulsa (sin necesidad de cuenta), se hace la captura (en un ordenador, después de que el navegador pida permiso para capturar la pestaña) y la persona marca sobre una captura de la parte visible de la página con flechas, recuadros, texto, lápiz o subrayador, y añade un título, una descripción y un tipo, como Bug. Estos campos de la plantilla se adjuntan solos a cada informe:

• URL de la página: la dirección exacta, también en subdominios de pruebas.
• Navegador y sistema: navegador y versión, sistema operativo y versión.
• Pantalla: la resolución de pantalla.
• Idioma y zona: idioma del navegador y zona horaria.
• Consola: los mensajes de consola, errores y peticiones fallidas recientes de la página.

Los avisos llegan a un panel donde los marcas como abiertos, resueltos o archivados, y cada uno puede crearse automáticamente como incidencia en Jira, tarjeta en Trello, tarea en ClickUp, Asana o Wrike, elemento en monday.com, página en Notion, mensaje en Slack o Discord, o email a tu equipo. En los planes de pago, el estado se sincroniza en los dos sentidos con Jira, Trello, ClickUp, Asana, monday.com, Wrike, Slack y Discord.

El plan gratuito incluye 5 proyectos y 50 avisos; el resto de planes están en precios.

Uses una herramienta o la plantilla, la regla no cambia: un error por informe, la URL y el entorno exactos, pasos numerados y el resultado esperado frente al real. Con esas cuatro cosas bien, la mayoría de errores se arreglan la primera vez que alguien los mira.