Por qué el formato se descuida más que el contenido
El formato de un informe de bug son 10 campos fijos agrupados en cuatro bloques: identidad → entorno → síntoma → evidencias. Con el orden fijado, el desarrollador sabe exactamente dónde mirar sin volver a preguntarte. Abajo tienes la lista completa de campos, las reglas de redacción con ejemplos buenos y malos para cada uno, y los 7 errores de formato que arruinan informes por lo demás correctos.
La misma información redactada con otro formato cuesta el doble de tiempo de proceso. Un formato inconsistente provoca tres problemas:
El valor de un formato no está en que se vea ordenado, sino en que el mismo campo aparece siempre en el mismo sitio.
El formato estándar de un informe de bug: 10 campos
| # | Campo | Para qué sirve | ¿Obligatorio? | Cómo redactarlo |
|---|---|---|---|---|
| 1 | Título | Permite al desarrollador decidir si abre el ticket | Obligatorio | Componente + acción + resultado inesperado + condición (ver ejemplos de títulos de bug) |
| 2 | ID | Permite que todos citen el mismo registro | Obligatorio (automático) | BUG-0042, nunca «el de antes» |
| 3 | Gravedad / Prioridad | Base para planificar | Recomendado | La gravedad mide el daño, la prioridad la urgencia de negocio — sepáralas |
| 4 | Entorno | Determina si el informe se puede reproducir | Obligatorio | URL, versión de navegador, sistema operativo, dispositivo, resolución, cuenta |
| 5 | Requisitos previos | El estado inicial para reproducir | Recomendado | «Sesión iniciada como cuenta enterprise, con 2 artículos ya en el carrito» |
| 6 | Pasos para reproducir | Lleva a otra persona a la misma pantalla | Obligatorio | Numerados, una acción por paso (ver cómo escribir los pasos) |
| 7 | Resultado esperado | Base para decidir «¿esto es un defecto?» | Obligatorio | Describe lo que debería ocurrir, nunca «no funciona bien» |
| 8 | Resultado real | Descripción factual | Obligatorio | Síntoma + cifras + texto exacto del error, sin suposiciones |
| 9 | Evidencias | Evita que el desarrollador lo repita todo | Muy recomendado | Capturas anotadas, grabación de pantalla, logs de consola, peticiones fallidas |
| 10 | Notas | Contexto adicional | Opcional | Frecuencia, soluciones temporales, tickets relacionados |
Cómo redactar cada campo
Identidad: título, ID, gravedad y prioridad
- Título: una línea con dónde, qué hiciste, qué salió mal y bajo qué condición. 40 ejemplos buenos y malos comparados: ejemplos de títulos de bug.
- ID: deja que lo genere el sistema. La numeración manual siempre acaba duplicando.
- Gravedad vs prioridad: el par que más se fusiona en un solo campo.
| Campo | Pregunta que responde | Quién decide | Ejemplo |
|---|---|---|---|
| Gravedad | ¿Cuánto daño causa el defecto en sí? | QA / quien lo reporta | Pérdida de datos = crítica; una errata = menor |
| Prioridad | ¿Cuándo lo vamos a arreglar? | Producto / lead técnico | Una errata en el hero en semana de lanzamiento = prioridad alta |
Entorno: entorno y requisitos previos
El campo de entorno debe cubrir los seis elementos: URL, navegador y versión, sistema operativo, dispositivo, resolución o viewport, y tipo de cuenta. Escribir solo «Chrome» equivale a no escribir nada: las diferencias de comportamiento entre versiones de navegador son rutina en la web.
El requisito previo que más se olvida no es el estado de sesión, sino el estado de los datos: «2 artículos en el carrito», «la cuenta está en el día 3 de la prueba», «ese pedido ya tuvo un reembolso». Eso es lo que bloquea la reproducción.
Síntoma: pasos para reproducir, resultado esperado y resultado real
- Pasos para reproducir: numerados, una acción por paso, datos reales. El método completo está en cómo escribir los pasos.
- Resultado esperado: describe qué debería ocurrir y cita la fuente cuando puedas (un requisito, el ID de un criterio de aceptación o simple lógica de negocio). «Debería funcionar bien» devuelve el juicio al desarrollador.
- Resultado real: solo hechos, con cifras y el texto exacto del error. Sin suposiciones — las hipótesis del tipo «probablemente sea la caché» van a Notas, marcadas como «sospecha».
Evidencias: capturas / grabaciones / logs, y notas
- Las capturas deben ir anotadas: rodea la zona del problema y añade flechas o texto, para que nadie recorra una captura a pantalla completa.
- Las grabaciones deben durar de 10 a 30 segundos y conservar solo el momento relevante — una grabación de cinco minutos no se ve.
- Los logs deben incluir solo lo útil: salida de consola en nivel error, peticiones de red fallidas (HTTP ≥ 400) y los cuerpos de petición y respuesta del endpoint implicado.
- Las notas deben llevar dos cosas: la frecuencia (siempre / intermitente, con probabilidad) y el workaround si existe.
Diferencias de formato en tres canales
| Canal | Cómo aparecen los campos | La trampa |
|---|---|---|
| Gestor de incidencias (Jira / Linear / GitHub Issues) | Campos personalizados + plantilla de descripción | La info de entorno al final de la descripción, ahogada en el texto — su sitio son los campos personalizados |
| Correo o mensajería (a un cliente o colaborador externo) | Bloques de texto plano | Sin TL;DR, y adjuntos con nombres al azar que obligan a buscar entre una docena de archivos |
| Hoja de cálculo (Excel / Google Sheets / Feishu Bitable) | Una fila por bug, columnas = campos | El orden de columnas no coincide con los 10 campos y el filtrado y la ordenación se rompen |
El canal cambia, los campos no. La información que falta no se perdona porque se haya enviado por correo.
7 errores de formato que arruinan un informe
captura-1.png, que ni quien los envió sabe asociar tres días después.Checklist de formato
Confirma cada línea antes de enviar:
- ¿Están los 10 campos, en el mismo orden que la última vez?
- ¿Están rellenados los seis elementos de entorno (URL / navegador / SO / dispositivo / resolución / cuenta)?
- ¿Resultado esperado y resultado real van por separado?
- ¿Los pasos están numerados, con una acción por paso?
- ¿Las capturas están anotadas y las grabaciones por debajo de 30 segundos?
- ¿No hay ninguna suposición sin verificar en el resultado real?
- ¿Se indica con claridad la frecuencia (siempre / intermitente + probabilidad)?
FAQ
¿Existe un «formato estándar» de informe de bug?
No hay una norma sectorial de obligado cumplimiento, pero sí un consenso de facto: título, entorno, pasos para reproducir, resultado esperado, resultado real y evidencias aparecen en prácticamente todos los marcos (IEEE 829, ISTQB y la mayoría de las plantillas de defecto comerciales). Los 10 campos de aquí añaden identidad y notas a ese núcleo.
¿Se puede cambiar el orden de los campos?
Sí, siempre que se mantenga consistente y estable dentro del equipo. El sentido de un orden fijo es la memoria muscular: los desarrolladores saben dónde mirar. Cambiarlo a menudo perjudica más que elegir un orden poco óptimo.
¿Cuál es la diferencia real entre gravedad y prioridad?
La gravedad describe el daño objetivo del defecto (lo juzga QA); la prioridad describe la urgencia de corregirlo (lo juzga producto). Pueden divergir: una errata en el hero tiene gravedad baja, pero si el lanzamiento es en tres días su prioridad es alta.
¿De verdad hacen falta los 10 campos en un bug simple?
No. Un bug simple se apaña con título, entorno y resultado real — pero nunca sin el entorno, la primera causa de «no se puede reproducir». Los campos son opcionales; las posiciones, no.
¿Cuál es la diferencia entre «formato» y «plantilla»?
Un formato es la especificación de campos: cuáles existen, en qué orden y cómo se redacta cada uno. Una plantilla es un archivo esqueleto que se copia y se rellena. Funcionan juntos: define los campos con el formato y entrégalos como plantilla. Si quieres el esqueleto listo para rellenar, consulta plantilla de informe de bug (versiones Word y Markdown).
El formato se puede automatizar; el criterio es tuyo
Para ser precisos con el límite: BugCapturer no decide qué cuenta como defecto ni escribe tu título — eso requiere tu comprensión de lo observado. Pero lo que se olvida y lo que consume tiempo puede rellenarse solo:
- Contexto técnico automático: URL, navegador, sistema operativo, resolución de pantalla y tamaño de viewport se escriben en el campo de entorno, sin copiar a mano.
- Datos de diagnóstico: se recogen logs de consola en nivel error y peticiones de red fallidas (HTTP ≥ 400), con anonimización automática de parámetros sensibles (tokens, contraseñas, claves de API).
- Capturas anotadas: selecciona la zona y añade flechas, cajas y texto, para que «dónde está mal» quede fijado en la imagen.
- Grabación de pantalla: graba la pestaña actual y recorta el clip, para entregar un vídeo corto que se puede verificar.
- Compartir o sincronizar: genera un enlace que colaboradores externos abren sin registrarse, o envía el informe a Feishu Bitable o a un webhook genérico.
El criterio sigue siendo tuyo. Del resto se encarga la herramienta.
Lecturas recomendadas
- Plantilla de informe de bug: todos los campos con un esqueleto para copiar
- Ejemplos de títulos de bug: 40 títulos buenos y malos comparados
- Cómo escribir los pasos para reproducir: 5 ejemplos completos
- Cómo reportar bugs con eficacia
- Checklist de QA para sitios web