Écrire un rapport de bug navigateur reproductible
Transformez un échec navigateur en rapport utile et sûr avec comportement attendu, reproduction minimale et contexte.
BotBrowser Team
Vous voulez la documentation structurée pour Démarrage ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Un rapport utile permet de revoir le même échec sans deviner. Il décrit attendu, observé, reproduction minimale, environnement et preuve partageable. Ce n’est pas un verdict de cause ni une demande d’état privé.
Comportement attendu et réel
Écrivez le contrat visible. « Après Enregistrer, la confirmation apparaît et le focus va au titre » est attendu. « La requête finit, mais aucun état n’apparaît et le focus reste sur Enregistrer » est observé. Ne concluez pas la cause sans preuve.
Un rapport couvre un échec cohérent. Connexion, mise en page et téléchargement peuvent partager une release mais ont des étapes et propriétaires différents. Reliez les rapports par identifiant public, sans copier de traces privées.
Consultez les consignes Chromium et Mozilla. Elles demandent des étapes claires, pas des identifiants ni un dump navigateur.
Reproduction minimale
Retirez une étape à la fois jusqu’à ce que l’échec disparaisse. Utilisez une fixture possédée, des données synthétiques, l’action exacte, le résultat visible et le nettoyage. Ne testez pas un service tiers que vous ne contrôlez pas.
Titre : confirmation absente après l’enregistrement d’un profil de test
Attendu : ouvrir la fixture, changer le nom, sélectionner Enregistrer, voir « Enregistré » et déplacer le focus.
Observé : la requête finit, aucun état n’apparaît et le focus reste sur Enregistrer.
Environnement : Chromium 154, Linux, 1280x800, clavier et pointeur, app 2026.10.06, 5/5 exécutions.
| État | Preuve | Action |
|---|---|---|
| Bloquant et reproductible | étapes échouent toujours | propriétaire et release retenue |
| Reproductible et borné | une route ou condition | comparer une cellule connue |
| Intermittent | fréquence et fenêtre | ajouter contexte et rejouer |
| Non reproduit | fixture et environnement précis | demander une condition |
| Preuve masquée | données sensibles retirées | canal approuvé ou faits visibles |
Informations d’environnement
Gardez famille/version, plateforme, viewport, entrée, release, route, locale, profil, permissions et réseau seulement s’ils changent le résultat. Indiquez cache froid ou chaud et visibilité. Séparez build application, navigateur et profil; si tout change, notez la cause inconnue.
BotBrowser peut répéter des parcours autorisés avec profil, plateforme, release, viewport, route et données de test déclarés. Il n’infère pas la cause, ne collecte pas de journaux privés, n’expose pas de secrets, ne garantit pas une correction et n’autorise pas les reproductions contre des services tiers.
Revue de confidentialité
Supprimez cookies, tokens, mots de passe, comptes, URL privées, paramètres, texte personnel, onglets étrangers et fichiers client. Utilisez des noms synthétiques. Recadrez les captures et masquez adresses et notifications. Ne versez jamais profil complet, capture réseau ou stockage dans un tracker public.
Si une preuve privée est nécessaire, utilisez un canal contrôlé et notez son propriétaire et sa conservation. Le rapport public peut pointer vers l’artefact masqué.
Triage et suivi
Un rapport est prêt quand les étapes, différence visible, environnement et limite de confidentialité sont clairs. Ajoutez fréquence, première étape échouée et récupération. Si l’échec ne revient pas, comparez une route connue et demandez une seule condition.
Pour une release, reliez le rapport au candidat, à la cellule de matrice ou au test de régression. Décidez blocage, exception bornée, repli ou hors périmètre. Gardez l’échec et la correction dans l’historique.
Pour le contexte, consultez la validation des releases et la matrice de tests navigateur.
Avant de fermer le ticket, vérifiez que la fixture et les données synthétiques sont encore accessibles à l’équipe qui reprend l’enquête. Indiquez la personne responsable de la prochaine reproduction.
Si le résultat varie, notez le nombre d’essais et la fenêtre temporelle. Cette mesure courte rend la comparaison avec un correctif plus fiable sans transformer un seul essai en verdict.
Vérifiez aussi le titre, l’étape initiale, la première divergence et l’action demandée. Ces quatre repères permettent au propriétaire de la route de commencer sans relire une longue trace.
Conservez les versions du navigateur et de l’application séparément. Une mise à jour simultanée doit rester décrite comme une combinaison observée, sans attribution prématurée.
Utilisez une fixture synthétique et réinitialisable. Si une donnée privée est indispensable, décrivez sa forme dans le ticket et gardez sa valeur dans le canal contrôlé.
Ajoutez le résultat de la correction au même rapport, avec le nombre d’essais et les conditions constantes. Cela préserve l’historique utile aux prochaines releases.
Indiquez également le propriétaire et la date de la prochaine vérification afin que l’enquête reste suivie même si le premier essai ne suffit pas.
Conservez enfin le lien vers la fixture de test afin qu’une autre équipe puisse reprendre le même scénario.
Sources publiques
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.