6 min lecture • Guide 636 of 877
Créer des Rapports de Bug Efficaces
Les rapports de bug efficaces contiennent les informations dont les développeurs ont besoin pour reproduire, comprendre et corriger les problèmes rapidement. Les fonctionnalités de suivi de bugs de GitScrum aident les équipes à standardiser les rapports de bug, assurer une capture d'information cohérente, et rationaliser le chemin du rapport à la résolution.
Structure du Rapport de Bug
Composants Essentiels
TEMPLATE RAPPORT DE BUG :
┌─────────────────────────────────────────────────────────────┐
│ TITRE : [Action] cause [Problème] dans [Zone] │
│ Exemple : "Cliquer 'Sauver' cause perte de données profil" │
├─────────────────────────────────────────────────────────────┤
│ │
│ SÉVÉRITÉ : 🔴 Critique / 🟠 Haute / 🟡 Moyenne / 🟢 Basse │
│ │
│ ENVIRONNEMENT : │
│ • Navigateur/Appareil : Chrome 120, Windows 11 │
│ • Version App : 2.4.1 │
│ • Type de Compte : Utilisateur Premium │
│ │
│ ÉTAPES DE REPRODUCTION : │
│ 1. Naviguer vers Paramètres > Profil │
│ 2. Changer nom d'affichage en "Utilisateur Test" │
│ 3. Cliquer bouton "Sauver" │
│ 4. Observer le message d'erreur │
│ │
│ COMPORTEMENT ATTENDU : │
│ Le profil devrait sauver et afficher message de succès │
│ │
│ COMPORTEMENT RÉEL : │
│ Erreur "Échec sauvegarde" apparaît, changements perdus │
│ │
│ PIÈCES JOINTES : │
│ • [Capture d'écran de l'erreur] │
│ • [Log console] │
│ • [Capture requête réseau] │
└─────────────────────────────────────────────────────────────┘
Directives de Sévérité
NIVEAUX DE SÉVÉRITÉ BUG :
┌─────────────────────────────────────────────────────────────┐
│ NIVEAU │ CRITÈRES │ RÉPONSE │
├───────────┼─────────────────────────────┼───────────────────┤
│ 🔴 Critique│ • App inutilisable │ Corriger immédiat │
│ │ • Perte de données │ Release même jour │
│ │ • Faille sécurité │ │
├───────────┼─────────────────────────────┼───────────────────┤
│ 🟠 Haute │ • Fonctionnalité majeure │ Corriger ce sprint│
│ │ cassée │ File prioritaire │
│ │ • Contournement difficile │ │
│ │ • Beaucoup d'utilisateurs │ │
├───────────┼─────────────────────────────┼───────────────────┤
│ 🟡 Moyenne│ • Fonctionnalité dégradée │ Planifier sprint │
│ │ • Contournement existe │ à venir │
│ │ • Certains utilisateurs │ │
├───────────┼─────────────────────────────┼───────────────────┤
│ 🟢 Basse │ • Inconvénient mineur │ Backlog │
│ │ • Problème cosmétique │ Corriger si poss. │
│ │ • Occurrence rare │ │
└─────────────────────────────────────────────────────────────┘
Rapports de Bug de Qualité
Étapes de Reproduction
BONNES ÉTAPES DE REPRODUCTION :
┌─────────────────────────────────────────────────────────────┐
│ │
│ ✅ BIEN : │
│ 1. Se connecter comme utilisateur "test@example.com" │
│ 2. Naviguer vers Dashboard > Rapports │
│ 3. Sélectionner plage dates : 1 Jan - 31 Jan 2024 │
│ 4. Cliquer "Générer Rapport" │
│ 5. Attendre chargement rapport (environ 5 secondes) │
│ 6. Cliquer "Exporter PDF" │
│ Résultat : Erreur "Export échoué" apparaît │
│ │
│ ❌ MAL : │
│ "L'export PDF ne marche pas" │
│ │
│ ❌ AUSSI MAL : │
│ "Aller aux rapports et essayer d'exporter" │
│ │
│ CONSEILS : │
│ • Être spécifique sur les actions │
│ • Inclure toutes données requises │
│ • Noter le timing si pertinent │
│ • Mentionner si c'est intermittent │
└─────────────────────────────────────────────────────────────┘
Preuves Annexes
PIÈCES JOINTES UTILES :
┌─────────────────────────────────────────────────────────────┐
│ TYPE │ QUAND INCLURE │
├───────────────────┼────────────────────────────────────────┤
│ Capture écran │ Bugs visuels, messages erreur │
│ Vidéo │ Interactions complexes, timing │
│ Logs console │ Erreurs JavaScript, warnings │
│ Capture réseau │ Échecs API, requêtes lentes │
│ Logs erreur │ Problèmes côté serveur │
│ Fichier HAR │ Trace réseau complète │
│ Données exemple │ Bugs liés aux données │
└─────────────────────────────────────────────────────────────┘
DANS GITSCRUM :
• Glisser-déposer pièces jointes sur tâche
• Lier aux enregistrements d'écran
• Coller images directement dans description
• Attacher fichiers logs
Workflow des Bugs
Cycle de Vie du Bug
WORKFLOW STATUT BUG :
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ Nouveau│→ │ Triage │→ │Correction│→│ Test │→ │ Fermé │
└────────┘ └────────┘ └────────┘ └────────┘ └────────┘
│ │ │ │ │
│ │ │ │ │
↓ ↓ ↓ ↓ ↓
Soumis Priorisé Dev Fix Livré
& assigné assigné vérifié
TRANSITIONS POSSIBLES :
• Triage → Fermé (Pas un bug / Won't fix / Doublon)
• Test → Correction (Fix ne marche pas, réouvrir)
• Tout → Fermé (Won't fix avec explication)
Processus de Triage
CHECKLIST RÉUNION TRIAGE :
┌─────────────────────────────────────────────────────────────┐
│ │
│ POUR CHAQUE NOUVEAU BUG : │
│ │
│ 1. VALIDER │
│ □ Est-il reproductible ? │
│ □ Est-ce un doublon ? │
│ □ Est-ce vraiment un bug (pas demande feature) ? │
│ │
│ 2. ÉVALUER │
│ □ Quelle est la sévérité ? │
│ □ Combien d'utilisateurs affectés ? │
│ □ Y a-t-il un contournement ? │
│ │
│ 3. PRIORISER │
│ □ Où se situe-t-il dans le backlog ? │
│ □ Doit-il interrompre le travail en cours ? │
│ □ Quel sprint planifier ? │
│ │
│ 4. ASSIGNER │
│ □ Qui a le contexte ? │
│ □ Qui a la capacité ? │
└─────────────────────────────────────────────────────────────┘