Guide pratique
6 min de lecture
Mis à jour le
Transformer un bug en cas reproductible
Décris le résultat attendu et observé, isole un cas minimal, expurge les preuves et vérifie la correction.
Réponse directe
Donne les conditions de départ et les actions numérotées qui mènent à un échec observable. Sépare attendu, observé et hypothèses. Réduis le cas dans une copie sûre, partage des preuves expurgées et rejoue les étapes initiales après correction.
01
1. Décris un échec observable
Écris un titre qui associe un déclencheur à sa conséquence visible, comme « Retirer un thème efface les autres choix ». Sépare le résultat attendu du résultat observé. Indique la page, la version de l’application, celle du navigateur, le système et le rôle du compte. Un rôle ou un compte fictif suffit souvent, sans identifiant réel.
Conserve d’abord les conditions de l’échec : données de départ, langue et session déjà ouverte ou non. Cherche les signalements existants avant d’en créer un autre. Sépare les échecs distincts pour qu’une correction ne masque pas les autres. Pour un problème intermittent, donne le nombre d’essais et d’apparitions au lieu d’annoncer une reproduction systématique.
02
2. Réduis le cas sans perdre la preuve
Travaille sur une copie ou dans un environnement de test. Retire un champ facultatif, une extension ou une interaction à la fois, puis rejoue les mêmes étapes. Garde le cas défaillant connu à côté de chaque réduction. Un cas minimal qui ne présente plus le défaut ne le reproduit pas : restaure le dernier élément nécessaire et note cette limite.
Compare précisément : même version avec un réglage différent, puis comparaison de versions séparée si utile. Un nouveau profil de navigateur aide à isoler une dépendance à la session ; ne réinitialise pas le profil de travail et ne supprime pas ses données. Si le profil neuf ne présente pas le défaut, conserve les conditions initiales et rapporte cette différence comme un indice.
03
3. Donne un signalement rejouable
Le signalement fictif ci-dessous illustre le format. Remplace la version et l’environnement par ceux observés ; les nombres sont un exemple, pas des mesures de SkillCodex. Utilise des données fictives qu’une personne ayant accès au test peut recréer.
Demande à une autre personne de suivre uniquement le signalement. Ajoute toute préparation qui manquait. Une page HTML réduite ou un petit dépôt peut aider si son partage est autorisé, avec le comportement déclencheur et les commandes de lancement. Une capture seule ne prouve pas la séquence d’interactions.
Titre : retirer Design retire aussi Tests
Version / navigateur / système : [versions observées]
Préparation : liste de test sans thème
1. Sélectionne Design.
2. Sélectionne Tests.
3. Active Retirer Design.
Attendu : Tests reste sélectionné.
Observé : les deux thèmes disparaissent.
Fréquence : 3 essais sur 3 (exemple fictif)
Preuve : capture expurgée après l’étape 3
Cause : inconnue04
4. Partage des preuves utiles et expurgées
Si tu utilises les traces Playwright, inspecte les instantanés du DOM et les détails réseau : le visualiseur peut afficher en-têtes et corps des requêtes et réponses. Une archive utile au débogage peut donc contenir des données sensibles. Vérifie l’archive elle-même, pas seulement la capture jointe au signalement.
Joins le plus court extrait montrant l’échec, avec les horodatages ou numéros d’étape utiles. Inspecte les captures, la console et les traces réseau avant partage. Retire identifiants secrets, cookies, en-têtes d’autorisation, messages personnels, données client et URL privées. Reproduis avec des données de test si le masquage rend la preuve illisible.
Ne conserve un original privé que si les règles d’accès de ton équipe l’autorisent ; ne colle pas un export complet de session dans un ticket public. Précise les retraits et les éventuelles simulations. Utilise le canal de sécurité restreint pour une vulnérabilité présumée. Un guide de signalement n’autorise pas à exposer les données d’autrui.
05
5. Sépare les indices temporels des causes prouvées
Pour un échec asynchrone présumé, note l’ordre des requêtes, celui des réponses et l’état visible aux moments utiles. Rejoue avec un délai contrôlé dans un environnement de test. Un réseau ralenti peut révéler le défaut sans prouver sa cause : ancienne réponse, état périmé ou autre prérequis peuvent expliquer le symptôme.
Après correction, rejoue le cas défaillant initial et un cas voisin qui fonctionnait déjà. Note la version testée et les deux résultats. Si le défaut ne réapparaît plus, rapporte cette observation avec ses limites : un essai réussi ne prouve pas la correction d’un problème intermittent. Cette procédure précise les preuves sans garantir une cause racine ni un correctif sûr en production.
- Rejoue les étapes sur la version corrigée identifiée : Tests doit rester.
- Retire plutôt Tests : Design doit rester dans le cas voisin de contrôle.
- Répète le cas intermittent et rapporte les apparitions sur le nombre d’essais, même zéro.
À conserver
Vérifie avant livraison
- 01Une autre personne peut recréer le départ et suivre les étapes.
- 02Attendu et observé sont séparés des causes supposées.
- 03Version, environnement et fréquence sont notés sans secret.
- 04Le défaut initial et un cas voisin fonctionnel sont rejoués après changement.
- 05Chaque réduction conserve le déclencheur et le cas défaillant de référence.
- 06Les pièces jointes ont été inspectées et les retraits de données privées sont précisés.
Sources primaires
Les affirmations techniques de ce guide sont reliées aux spécifications et documentations first-party.
- Trace viewer (nouvel onglet)Microsoft / Playwright · Instantanés du DOM, en-têtes et corps réseau présents dans les traces ; inspecte-les avant partage.
- Bug Writing Guidelines (nouvel onglet)Mozilla · Étapes précises, attendu et observé, cas réduit et version ; les conseils propres à Firefox demandent une adaptation.
Continuer
Guides et outils associés
Comprendre → Reconnaître → Choisir → Comparer
Pack pour ton agent
Instruction pré-écrite par SkillCodex — ta demande n’est ni envoyée ni utilisée pour adapter ce texte ; aucun contenu n’est généré et copier n’exécute rien.
Implémenter correctement
Applique « Transformer un bug en cas reproductible » pas à pas
# Applique le guide « Transformer un bug en cas reproductible » dans ton agent ## Objectif Donne les conditions de départ et les actions numérotées qui mènent à un échec observable. Sépare attendu, observé et hypothèses. Réduis le cas dans une copie sûre, partage des preuves expurgées et rejoue les étapes initiales après correction. ## Prérequis - Inspecte le dépôt, la documentation et les conventions existantes. - Confirme que le besoin correspond au périmètre du guide : Décris le résultat attendu et observé, isole un cas minimal, expurge les preuves et vérifie la correction. - Préserve les décisions correctes déjà en place. ## Étapes du guide - 1. 1. Décris un échec observable — Écris un titre qui associe un déclencheur à sa conséquence visible, comme « Retirer un thème efface les autres choix ». Sépare le résultat attendu du résultat observé. Indique la page, la version de l’application, celle du navigateur, le système et le rôle du compte. Un rôle ou un compte fictif suffit souvent, sans identifiant réel. - 2. 2. Réduis le cas sans perdre la preuve — Travaille sur une copie ou dans un environnement de test. Retire un champ facultatif, une extension ou une interaction à la fois, puis rejoue les mêmes étapes. Garde le cas défaillant connu à côté de chaque réduction. Un cas minimal qui ne présente plus le défaut ne le reproduit pas : restaure le dernier élément nécessaire et note cette limite. - 3. 3. Donne un signalement rejouable — Le signalement fictif ci-dessous illustre le format. Remplace la version et l’environnement par ceux observés ; les nombres sont un exemple, pas des mesures de SkillCodex. Utilise des données fictives qu’une personne ayant accès au test peut recréer. - 4. 4. Partage des preuves utiles et expurgées — Si tu utilises les traces Playwright, inspecte les instantanés du DOM et les détails réseau : le visualiseur peut afficher en-têtes et corps des requêtes et réponses. Une archive utile au débogage peut donc contenir des données sensibles. Vérifie l’archive elle-même, pas seulement la capture jointe au signalement. - 5. 5. Sépare les indices temporels des causes prouvées — Pour un échec asynchrone présumé, note l’ordre des requêtes, celui des réponses et l’état visible aux moments utiles. Rejoue avec un délai contrôlé dans un environnement de test. Un réseau ralenti peut révéler le défaut sans prouver sa cause : ancienne réponse, état périmé ou autre prérequis peuvent expliquer le symptôme. ## Critères d’acceptation — Vérifie avant livraison - Une autre personne peut recréer le départ et suivre les étapes. - Attendu et observé sont séparés des causes supposées. - Version, environnement et fréquence sont notés sans secret. - Le défaut initial et un cas voisin fonctionnel sont rejoués après changement. - Chaque réduction conserve le déclencheur et le cas défaillant de référence. - Les pièces jointes ont été inspectées et les retraits de données privées sont précisés. ## Garde-fous - Montre d’abord les changements envisagés avant toute action externe. - Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite. - Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu. ## Format de sortie - Résultat obtenu ou verdict. - Fichiers ou actions concernés. - Vérifications exécutées et preuves observables. - Blocages ou limites restantes.
- Prérequis · Le contexte réel du projet : dépôt, documentation et contraintes existantes
Pourquoi ça marche
- Les étapes viennent d’un guide publié et sourcé, pas d’une improvisation.
- La checklist transforme le conseil en critères vérifiables.
- Le périmètre déclaré évite d’étendre le guide au-delà de ses preuves.
À essayer ensuite
Ancre le guide dans le projet
# Ancre le guide dans le projet ## Objectif Transforme les étapes appliquées en conventions durables du dépôt. ## Contrôles - Relie chaque décision prise à l’étape du guide qui la justifie. - Ajoute la checklist aux revues concernées. - Note les cas hors périmètre pour les guides voisins. ## Garde-fous - Montre d’abord les changements envisagés avant toute action externe. - Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite. - Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu. ## Format de sortie - Résultat obtenu ou verdict. - Fichiers ou actions concernés. - Vérifications exécutées et preuves observables. - Blocages ou limites restantes.
sha256:06ce61c187a9c474c206daadb3b6205058d5b06987e86dd54904c010d3d80493
Diagnostiquer un problème
Diagnostique un écart au guide « Transformer un bug en cas reproductible »
# Diagnostique une application ratée du guide « Transformer un bug en cas reproductible » ## Symptôme observé [DÉCRIS ICI LE SYMPTÔME] ## Contrôles observables - Rejoue les étapes dans l’ordre et note la première qui diverge : - 1. 1. Décris un échec observable — Écris un titre qui associe un déclencheur à sa conséquence visible, comme « Retirer un thème efface les autres choix ». Sépare le résultat attendu du résultat observé. Indique la page, la version de l’application, celle du navigateur, le système et le rôle du compte. Un rôle ou un compte fictif suffit souvent, sans identifiant réel. - 2. 2. Réduis le cas sans perdre la preuve — Travaille sur une copie ou dans un environnement de test. Retire un champ facultatif, une extension ou une interaction à la fois, puis rejoue les mêmes étapes. Garde le cas défaillant connu à côté de chaque réduction. Un cas minimal qui ne présente plus le défaut ne le reproduit pas : restaure le dernier élément nécessaire et note cette limite. - 3. 3. Donne un signalement rejouable — Le signalement fictif ci-dessous illustre le format. Remplace la version et l’environnement par ceux observés ; les nombres sont un exemple, pas des mesures de SkillCodex. Utilise des données fictives qu’une personne ayant accès au test peut recréer. - 4. 4. Partage des preuves utiles et expurgées — Si tu utilises les traces Playwright, inspecte les instantanés du DOM et les détails réseau : le visualiseur peut afficher en-têtes et corps des requêtes et réponses. Une archive utile au débogage peut donc contenir des données sensibles. Vérifie l’archive elle-même, pas seulement la capture jointe au signalement. - 5. 5. Sépare les indices temporels des causes prouvées — Pour un échec asynchrone présumé, note l’ordre des requêtes, celui des réponses et l’état visible aux moments utiles. Rejoue avec un délai contrôlé dans un environnement de test. Un réseau ralenti peut révéler le défaut sans prouver sa cause : ancienne réponse, état périmé ou autre prérequis peuvent expliquer le symptôme. ## Causes possibles - Une étape a été sautée ou exécutée hors ordre. - Le besoin réel sort du périmètre du guide. - Un critère de la checklist n’a jamais été vérifié. ## Corrections bornées - Reprends uniquement l’étape divergente et ce qui en dépend. - Documente l’écart si le périmètre du guide ne couvre pas le besoin. ## Vérification finale — Vérifie avant livraison - Une autre personne peut recréer le départ et suivre les étapes. - Attendu et observé sont séparés des causes supposées. - Version, environnement et fréquence sont notés sans secret. - Le défaut initial et un cas voisin fonctionnel sont rejoués après changement. - Chaque réduction conserve le déclencheur et le cas défaillant de référence. - Les pièces jointes ont été inspectées et les retraits de données privées sont précisés. ## Garde-fous - Montre d’abord les changements envisagés avant toute action externe. - Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite. - Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu. ## Format de sortie - Résultat obtenu ou verdict. - Fichiers ou actions concernés. - Vérifications exécutées et preuves observables. - Blocages ou limites restantes.
- Prérequis · Le contexte réel du projet : dépôt, documentation et contraintes existantes
Pourquoi ça marche
- Le diagnostic rejoue des étapes ordonnées au lieu de chercher au hasard.
- Les corrections restent bornées à la première divergence réelle.
- La checklist sert de vérification finale reproductible.
À essayer ensuite
Préviens la prochaine dérive
# Préviens la prochaine dérive ## Objectif Fais de la première étape divergente un contrôle explicite du projet. ## Contrôles - Ajoute un contrôle ciblé sur l’étape qui a divergé. - Vérifie la checklist sur un second cas réel. - Documente la limite de périmètre rencontrée. ## Garde-fous - Montre d’abord les changements envisagés avant toute action externe. - Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite. - Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu. ## Format de sortie - Résultat obtenu ou verdict. - Fichiers ou actions concernés. - Vérifications exécutées et preuves observables. - Blocages ou limites restantes.
sha256:715062b425f5a03e8ea9b8ba1b5a974f377e4e1047fc1ed3555d9c49a4e8f91a
Digest du Pack: sha256:0d69b4802c608bc560baa4491f8246583fe22cc5006ed8f7e0247a8a34f1c294