8 min lecture • Guide 417 of 877
Processus de Triage des Bugs
Le triage des bugs détermine quels bugs corriger et quand. Un bon triage priorise basé sur l'impact, pas sur qui a crié le plus fort. Un mauvais triage laisse les bugs critiques languir pendant que les problèmes triviaux sont corrigés. Ce guide couvre le triage efficace des bugs.
Niveaux de Sévérité
| Sévérité | Description | Réponse |
|---|---|---|
| Critique | Système down, perte de données | Immédiate |
| Haute | Fonctionnalité majeure cassée | Ce sprint |
| Moyenne | Fonctionnalité dégradée | Bientôt |
| Basse | Problème mineur | Quand le temps le permet |
Processus de Triage
Gérer les Bugs
PROCESSUS DE TRIAGE DES BUGS
════════════════════════════
ÉTAPE 1 : VALIDER
─────────────────────────────────────
Est-ce un vrai bug ?
├── Peut-il être reproduit ?
├── Est-ce le comportement attendu ?
├── Est-ce un doublon ?
├── Est-il toujours pertinent ?
├── Assez d'info pour investiguer ?
└── Filtrer le bruit
Actions :
├── Valide → Continuer le triage
├── Doublon → Fermer, lier l'original
├── Pas un bug → Fermer avec explication
├── Besoin d'info → Demander des détails
└── Disposition
ÉTAPE 2 : ÉVALUER LA SÉVÉRITÉ
─────────────────────────────────────
CRITIQUE :
├── Système inutilisable
├── Perte ou corruption de données
├── Vulnérabilité de sécurité
├── Tous les utilisateurs affectés
└── Tout lâcher
HAUTE :
├── Fonctionnalité majeure cassée
├── Utilisateurs significatifs affectés
├── Pas de contournement existe
├── Impact business significatif
└── Correction prioritaire
MOYENNE :
├── Fonctionnalité dégradée
├── Contournement existe
├── Certains utilisateurs affectés
├── Gênant mais gérable
└── Planifier bientôt
BASSE :
├── Problème cosmétique
├── Cas limite rare
├── Inconvénient mineur
├── Bien de corriger un jour
└── Backlog
ÉTAPE 3 : PRIORISER
─────────────────────────────────────
Facteurs :
├── Sévérité (ci-dessus)
├── Impact utilisateur (combien affectés)
├── Impact business (revenus, réputation)
├── Effort pour corriger (victoire rapide ?)
├── Dépendances
└── Évaluation équilibrée
ÉTAPE 4 : ASSIGNER
─────────────────────────────────────
├── Ajouter au sprint/backlog approprié
├── Assigner à un développeur (optionnel)
├── Définir le délai cible
├── Communiquer au reporter
└── Suivi et visible
Réunion de Triage
Conduire le Triage
RÉUNION DE TRIAGE
═════════════════
FRÉQUENCE :
─────────────────────────────────────
├── Quotidienne : Volume élevé de bugs
├── 2-3x/semaine : Volume moyen
├── Hebdomadaire : Volume faible
├── Au besoin : Bugs critiques
└── Rythme régulier
FORMAT :
─────────────────────────────────────
Durée : 15-30 minutes
Participants : PO, Tech Lead, QA Lead
Ordre du jour :
1. Revoir les nouveaux bugs (5 min max chacun)
2. Valider/évaluer/prioriser rapidement
3. Assigner au sprint ou backlog
4. Revoir les bugs bloqués
RÔLES :
─────────────────────────────────────
PRODUCT OWNER :
├── Perspective business
├── Impact client
├── Priorité relative aux fonctionnalités
└── Décision finale si désaccord
TECH LEAD :
├── Complexité technique
├── Cause racine probable
├── Effort d'estimation
└── Risques techniques
QA LEAD :
├── Reproductibilité
├── Sévérité réelle
├── Impact de régression
└── Couverture de test
Workflow de Bug
Cycle de Vie
CYCLE DE VIE DU BUG :
┌─────────────────────────────────────────────────────────────┐
│ │
│ NOUVEAU → TRIÉ → ASSIGNÉ → EN COURS → RÉSOLU → VÉRIFIÉ │
│ │
│ NOUVEAU : │
│ ├── Bug reporté │
│ ├── Informations initiales │
│ ├── En attente de triage │
│ └── Pas encore évalué │
│ │
│ TRIÉ : │
│ ├── Validé comme vrai bug │
│ ├── Sévérité assignée │
│ ├── Priorité déterminée │
│ └── Prêt pour planification │
│ │
│ ASSIGNÉ : │
│ ├── Développeur assigné │
│ ├── Sprint ou release planifié │
│ ├── Délai défini │
│ └── En file d'attente │
│ │
│ EN COURS : │
│ ├── Développeur travaille dessus │
│ ├── Cause racine identifiée │
│ ├── Correction en développement │
│ └── PR en préparation │
│ │
│ RÉSOLU : │
│ ├── Correction mergée │
│ ├── En attente de déploiement │
│ ├── En attente de vérification QA │
│ └── Pas encore confirmé │
│ │
│ VÉRIFIÉ : │
│ ├── QA a confirmé la correction │
│ ├── Déployé en production │
│ ├── Reporter notifié │
│ └── Bug fermé │
│ │
│ AUTRES STATUTS : │
│ ├── NE SERA PAS CORRIGÉ : Décision de ne pas corriger │
│ ├── DOUBLON : Lié à un autre bug │
│ ├── BESOIN D'INFO : Infos manquantes │
│ └── NE PEUT REPRODUIRE : Pas reproductible │
│ │
└─────────────────────────────────────────────────────────────┘
Rapports de Bugs
Template de Bug
TEMPLATE DE RAPPORT DE BUG :
┌─────────────────────────────────────────────────────────────┐
│ │
│ TITRE : [Bref, descriptif] │
│ Ex : "Login échoue avec email contenant '+'" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ENVIRONNEMENT : │
│ ├── Version : 2.3.1 │
│ ├── Navigateur : Chrome 120 │
│ ├── OS : Windows 11 │
│ └── Compte test : user+test@example.com │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ÉTAPES POUR REPRODUIRE : │
│ 1. Aller sur la page de login │
│ 2. Entrer email : user+test@example.com │
│ 3. Entrer mot de passe valide │
│ 4. Cliquer "Connexion" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ COMPORTEMENT ATTENDU : │
│ L'utilisateur devrait être connecté et redirigé │
│ vers le dashboard. │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ COMPORTEMENT OBSERVÉ : │
│ Message d'erreur : "Format email invalide" │
│ L'utilisateur ne peut pas se connecter. │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PIÈCES JOINTES : │
│ ├── screenshot-error.png │
│ └── console-logs.txt │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ NOTES ADDITIONNELLES : │
│ Se produit uniquement avec les emails contenant '+'. │
│ Les emails standard fonctionnent normalement. │
│ │
└─────────────────────────────────────────────────────────────┘
Configuration GitScrum
Tableau de Bugs
CONFIGURATION GITSCRUM :
┌─────────────────────────────────────────────────────────────┐
│ PROJET DÉDIÉ AUX BUGS │
├─────────────────────────────────────────────────────────────┤
│ │
│ COLONNES : │
│ ┌─────┬─────┬─────┬─────┬─────┬─────┐ │
│ │Inbox│Triage│Back-│Sprint│En │Done │ │
│ │ │ │log │ │Cours│ │ │
│ └─────┴─────┴─────┴─────┴─────┴─────┘ │
│ │
│ LABELS DE SÉVÉRITÉ : │
│ ├── 🔴 P0-critique │
│ ├── 🟠 P1-haute │
│ ├── 🟡 P2-moyenne │
│ └── 🟢 P3-basse │
│ │
│ LABELS DE TYPE : │
│ ├── bug-regression │
│ ├── bug-nouveau │
│ ├── bug-ui │
│ ├── bug-perf │
│ └── bug-securite │
│ │
│ AUTOMATISATIONS : │
│ ├── Bug P0 → Slack #urgent + assign on-call │
│ ├── Bug dans Inbox > 24h → Rappel triage │
│ ├── Bug résolu → Demander vérification │
│ └── Bug vérifié → Fermer automatiquement │
│ │
└─────────────────────────────────────────────────────────────┘
Erreurs Courantes
Pièges à Éviter
ANTI-PATTERNS DE TRIAGE :
┌─────────────────────────────────────────────────────────────┐
│ ERREURS À ÉVITER │
├─────────────────────────────────────────────────────────────┤
│ │
│ ❌ PAS DE TRIAGE RÉGULIER : │
│ ├── Bugs s'accumulent │
│ ├── Critiques passent inaperçus │
│ └── Solution : Session fixe dans le calendrier │
│ │
│ ❌ PRIORISATION POLITIQUE : │
│ ├── Qui crie le plus fort gagne │
│ ├── Bugs VIP toujours prioritaires │
│ └── Solution : Critères objectifs documentés │
│ │
│ ❌ RAPPORTS INCOMPLETS : │
│ ├── Impossible de reproduire │
│ ├── Temps perdu à investiguer │
│ └── Solution : Template obligatoire, refuser incomplets │
│ │
│ ❌ IGNORER LES P3 : │
│ ├── Backlog infini de "petits" bugs │
│ ├── Mort par mille coupures │
│ └── Solution : Bug day régulier, cleanup trimestriel │
│ │
│ ❌ PAS DE COMMUNICATION : │
│ ├── Reporters ne savent pas le statut │
│ ├── Frustration et doublons │
│ └── Solution : Notifications automatiques │
│ │
└─────────────────────────────────────────────────────────────┘