7 min lecture • Guide 521 of 877
Comment Utiliser GitScrum pour le Suivi et la Résolution des Bugs
Le suivi efficace des bugs nécessite plus qu'une simple liste—il faut des workflows de triage, des systèmes de priorité et des chemins de résolution clairs. Les workflows personnalisables de GitScrum, les étiquettes de sévérité et l'intégration Git créent un système complet de suivi des bugs qui connecte les problèmes signalés aux corrections de code et aux résolutions vérifiées.
Niveaux de Sévérité des Bugs
| Sévérité | Impact | Temps de Réponse | Exemples |
|---|---|---|---|
| Critique | Système hors service, perte de données | Immédiat | Login cassé, paiement échoue |
| Haute | Fonctionnalité majeure cassée | 24 heures | Export échoue, dashboard vide |
| Moyenne | Fonctionnalité dégradée | 1 semaine | Performance lente, glitch UI |
| Basse | Problème mineur | Backlog | Faute de frappe, problème cosmétique |
Workflow de Suivi des Bugs
CYCLE DE VIE DU BUG DANS GITSCRUM
1. NOUVEAU BUG SIGNALÉ
┌─────────────────────────────────────────────────┐
│ Sources: │
│ ├── Tickets support client │
│ ├── Tests internes │
│ ├── Monitoring automatisé │
│ ├── Retours utilisateurs │
│ └── Tests QA │
│ │
│ Statut Initial: [Nouveau] │
└─────────────────────────────────────────────────┘
│
▼
2. TRIAGE (sous 24h)
┌─────────────────────────────────────────────────┐
│ Actions: │
│ ├── Vérifier reproductibilité │
│ ├── Assigner niveau de sévérité │
│ ├── Vérifier les doublons │
│ ├── Ajouter labels et assigné │
│ └── Définir la priorité │
│ │
│ Statut: [Trié] │
└─────────────────────────────────────────────────┘
│
▼
3. INVESTIGATION
┌─────────────────────────────────────────────────┐
│ Actions développeur: │
│ ├── Reproduire localement │
│ ├── Identifier la cause racine │
│ ├── Estimer l'effort de correction │
│ └── Documenter les découvertes │
│ │
│ Statut: [En Cours] │
└─────────────────────────────────────────────────┘
│
▼
4. IMPLÉMENTATION DE LA CORRECTION
┌─────────────────────────────────────────────────┐
│ ├── Correction code avec tests │
│ ├── Revue de code │
│ ├── Merge vers main │
│ └── Déploiement en staging │
│ │
│ Statut: [En Revue] │
└─────────────────────────────────────────────────┘
│
▼
5. VÉRIFICATION
┌─────────────────────────────────────────────────┐
│ ├── QA vérifie la correction en staging │
│ ├── Le rapporteur original confirme │
│ └── Déploiement en production │
│ │
│ Statut: [Vérifié] │
└─────────────────────────────────────────────────┘
│
▼
6. FERMÉ
┌─────────────────────────────────────────────────┐
│ ├── Notifier les parties prenantes │
│ ├── Mettre à jour la documentation si besoin │
│ └── Considérer les mesures de prévention │
│ │
│ Statut: [Fermé] │
└─────────────────────────────────────────────────┘
Template de Rapport de Bug
STRUCTURE DU RAPPORT DE BUG
┌─────────────────────────────────────────────────┐
│ Titre: [Composant] Description brève │
│ Exemple: [Checkout] Paiement échoue PayPal │
│ │
│ Labels: [bug] [severite-haute] [paiements] │
│ │
│ SÉVÉRITÉ: Haute │
│ PRIORITÉ: P1 │
│ RAPPORTEUR: @username │
│ ENVIRONNEMENT: Production │
│ │
│ RÉSUMÉ: │
│ Une phrase décrivant le problème. │
│ │
│ ÉTAPES DE REPRODUCTION: │
│ 1. Naviguer vers le checkout │
│ 2. Sélectionner PayPal comme moyen de paiement │
│ 3. Cliquer sur "Finaliser la Commande" │
│ 4. Observer l'erreur │
│ │
│ COMPORTEMENT ATTENDU: │
│ Commande complète et confirmation affichée. │
│ │
│ COMPORTEMENT RÉEL: │
│ Message d'erreur: "Échec traitement paiement" │
│ Commande non créée, utilisateur bloqué │
│ │
│ FRÉQUENCE: │
│ 100% reproductible │
│ │
│ UTILISATEURS AFFECTÉS: │
│ Tous les utilisateurs PayPal (~15% commandes) │
│ │
│ NAVIGATEUR/APPAREIL: │
│ Chrome 120, macOS 14 │
│ (confirmé aussi sur Safari, Firefox) │
│ │
│ LOGS D'ERREUR: │
│ ``` │
│ PayPalAPIError: Invalid token format │
│ at processPayment (payment.service.ts:145) │
│ ``` │
│ │
│ CAPTURES/VIDÉO: │
│ [attaché] │
│ │
│ CONTOURNEMENT: │
│ Utilisateurs peuvent utiliser carte bancaire │
└─────────────────────────────────────────────────┘
Configuration du Tableau de Bugs
TABLEAU DE SUIVI DES BUGS
Colonnes:
┌────────┬────────┬──────────┬────────┬──────────┐
│Nouveau │ Trié │ En Cours │ Revue │ Vérifié │
├────────┼────────┼──────────┼────────┼──────────┤
│ [BUG] │ [BUG] │ [BUG] │ [BUG] │ [BUG] │
│ [BUG] │ [BUG] │ [BUG] │ │ │
│ [BUG] │ │ │ │ │
└────────┴────────┴──────────┴────────┴──────────┘
Swimlanes par Sévérité:
┌─────────────────────────────────────────────────┐
│ 🔴 Critique (0 en Nouveau - objectif) │
│ ├── BUG-234: Timeout système... │
├─────────────────────────────────────────────────┤
│ 🟠 Haute (réponse < 24h) │
│ ├── BUG-456: Paiement échoue... │
│ ├── BUG-457: Export cassé... │
├─────────────────────────────────────────────────┤
│ 🟡 Moyenne (réponse < 1 semaine) │
│ ├── BUG-567: Recherche lente... │
├─────────────────────────────────────────────────┤
│ 🟢 Basse (backlog) │
│ ├── BUG-678: Faute dans... │
└─────────────────────────────────────────────────┘
Labels:
├── [severite-critique]
├── [severite-haute]
├── [severite-moyenne]
├── [severite-basse]
├── [regression]
├── [signale-client]
└── [besoin-info]
Tableau de Bord des Métriques de Bugs
MÉTRIQUES DE SANTÉ DES BUGS
ÉTAT ACTUEL:
┌─────────────────────────────────────────────────┐
│ Bugs Ouverts par Sévérité: │
│ Critique: 0 (objectif: 0) ✓ │
│ Haute: 4 (objectif: <5) ✓ │
│ Moyenne: 18 (objectif: <25) ✓ │
│ Basse: 45 (objectif: <100) ✓ │
└─────────────────────────────────────────────────┘
VÉLOCITÉ DE RÉSOLUTION:
┌─────────────────────────────────────────────────┐
│ Sévérité Temps Moy SLA Statut │
│ ────────────────────────────────────────── │
│ Critique 4 heures 8h ✓ Respecté │
│ Haute 2 jours 3j ✓ Respecté │
│ Moyenne 8 jours 14j ✓ Respecté │
│ Basse 21 jours 30j ✓ Respecté │
└─────────────────────────────────────────────────┘
TENDANCES:
┌─────────────────────────────────────────────────┐
│ Cette Semaine: │
│ Nouveaux bugs: 12 │
│ Bugs corrigés: 15 │
│ Changement net: -3 (amélioration) │
│ │
│ Taux d'Échappement (bugs prod du sprint): │
│ Ce sprint: 2 bugs (objectif: <3) ✓ │
│ Sprint précédent: 4 bugs │
└─────────────────────────────────────────────────┘
Bonnes Pratiques
- Triez dans les 24 heures suivant le rapport
- Rédigez des rapports reproductibles avec étapes claires
- Assignez la sévérité de manière cohérente avec des guidelines
- Allouez une capacité bug (10-20% par sprint)
- Suivez les taux d'échappement pour améliorer la prévention
- Bouclez la boucle avec les rapporteurs
- Analysez les patterns pour des corrections systémiques
- Célébrez les releases sans bug pour motiver
Anti-Patterns
✗ Bugs sans étapes de reproduction
✗ Tous les bugs marqués "critique"
✗ Pas de triage dédié aux bugs
✗ Bugs languissant non triés
✗ Corriger les symptômes pas les causes racines
✗ Pas de feedback au rapporteur original