Cómo escribir un informe reproducible de un error del navegador
Convierte un fallo del navegador en un informe útil y seguro con comportamiento esperado, pasos mínimos y datos del entorno.
BotBrowser Team
Quieres la documentación estructurada de Primeros pasos?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
Un informe útil permite que otra persona vea el mismo fallo sin adivinar. Explica lo esperado, lo observado, la reproducción mínima, el entorno y la evidencia segura. No es un veredicto de causa raíz ni una petición de estado privado del navegador.
Comportamiento esperado y real
Escribe primero el contrato visible. “Al seleccionar Guardar aparece la confirmación y el foco pasa al título” es esperado. “La solicitud termina, pero no aparece estado y el foco queda en Guardar” es real. No afirmes la causa antes de tener evidencia.
Un informe debe cubrir un fallo coherente. Login, layout y descarga pueden compartir release, pero necesitan pasos y responsables distintos. Enlaza incidencias relacionadas por identificador público, sin copiar trazas privadas.
Consulta las guías de Chromium y Mozilla para pasos, esperado, real y contexto. No exigen credenciales ni un volcado completo.
Reproducción mínima
Quita pasos hasta que quitar uno elimine el fallo. Usa una fixture propia, datos sintéticos, acción exacta, resultado visible y limpieza. No pruebes servicios que no administras.
Título: Falta la confirmación al guardar un perfil de prueba
Esperado:
1. Abrir la fixture de perfil propia.
2. Cambiar el nombre a "Example".
3. Seleccionar Guardar.
4. Ver "Guardado" y mover el foco al estado.
Real:
La solicitud termina, no aparece estado y el foco queda en Guardar.
Entorno:
Navegador: Chromium 154, fixture Linux
Viewport: 1280x800, teclado y puntero
Release: app 2026.10.06
Reproducibilidad: 5/5 ejecuciones
| Estado | Evidencia | Acción |
|---|---|---|
| Bloqueante y reproducible | pasos fallan siempre | asignar dueño y pausar release |
| Reproducible y acotado | falla una ruta o entorno | comparar celda conocida |
| Intermitente | frecuencia y cantidad de ejecuciones | añadir contexto y repetir |
| No reproducible | fixture y entorno exactos | pedir un solo dato faltante |
| Redactado por privacidad | datos sensibles eliminados | usar hechos visibles o canal aprobado |
Datos del entorno
Incluye solo factores que puedan cambiar el resultado: familia y versión, plataforma, viewport, entrada, release de la aplicación, ruta, locale, perfil/permisos y red. Indica caché fría o cálida y visibilidad. Las etiquetas describen condiciones de prueba, no una persona.
Separa build de aplicación, build del navegador y revisión del perfil. Si cambiaron juntos, declara la combinación y causa desconocida. Repite con una variable fija antes de atribuir el fallo.
BotBrowser puede repetir recorridos autorizados con perfil, plataforma, release, viewport, ruta y datos de prueba declarados. No infiere causa raíz, no recopila registros privados, no expone credenciales, no garantiza una corrección ni autoriza reproducciones contra servicios de terceros.
Revisar privacidad antes de compartir
Elimina cookies, tokens, contraseñas, identificadores, URL privadas, consultas, texto personal, pestañas ajenas y archivos descargados con datos de clientes. Usa nombres sintéticos. Recorta capturas al control que falla y conserva el estado visible necesario.
Un vídeo o captura solo ayuda cuando el texto no basta. Oculta direcciones, avisos y cuentas. Comparte solo las líneas necesarias de una traza o consola, con valores redactados. Nunca subas un perfil o volcado de almacenamiento a un tracker público.
Si hacen falta datos privados, usa un canal aprobado con dueño de retención. El informe público puede indicar que existe un artefacto redactado.
Triage y seguimiento
El informe está listo cuando otra persona puede ejecutar pasos, ver la diferencia, identificar entorno y entender el límite de privacidad. Añade frecuencia, primer paso fallido y recuperación visible. Si no se reproduce, compara una ruta conocida y solicita una condición cada vez. No pidas un volcado completo.
En releases enlaza el informe con candidato, celda de matriz o regresión. El arreglo debe añadir un fixture de regresión. La decisión indica bloqueo, waiver limitado, una alternativa controlada o fuera de alcance. Conserva fallo original y corrección verificada.
Antes de cerrar el informe, confirma que la ruta y los datos de prueba siguen disponibles para el equipo que lo recibirá. Anota quién puede repetirlo y qué condición debe permanecer fija.
Si el resultado cambia entre ejecuciones, conserva el recuento y el intervalo de tiempo. Esa pequeña medición permite comparar una corrección sin convertir una impresión aislada en una conclusión.
Revisa el título, el paso inicial, la primera diferencia visible y la acción solicitada para que el responsable pueda empezar sin leer una traza extensa.
Separa las versiones del navegador y de la aplicación. Si cambiaron a la vez, describe la combinación observada y deja la causa abierta hasta comparar.
Usa una fixture sintética que pueda reiniciarse. Describe la forma de un estado privado y conserva su valor únicamente en el canal aprobado.
Indica también el responsable y la fecha de la próxima comprobación para que el caso no quede sin seguimiento.
Para contexto, consulta la validación de releases y la matriz de pruebas de navegador.
Fuentes públicas
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.