Glossaire · Fondamentaux du test
Priorité d’un bug
En anglais : Bug priority
Également appelé : priorité d’un défaut, priorité des bugs, niveaux de priorité
Définition
L’urgence avec laquelle un défaut doit être corrigé par rapport au reste du travail, selon les besoins métier ; elle est fixée par le product owner ou en triage.
La priorité d’un bug décrit l’ordre dans lequel les défauts sont corrigés. C’est une décision métier qui met en balance l’impact sur les utilisateurs, les échéances, les engagements envers les clients, la réputation et le coût de la correction. Les testeurs peuvent proposer une priorité, mais la décision finale revient généralement au product owner, souvent lors d’une réunion de triage avec le développement et la QA.
Échelle typique
| Priorité | Signification |
|---|---|
| P1 / Urgente | Corriger immédiatement, éventuellement via un hotfix hors du cycle de release normal |
| P2 / Haute | Corriger dans le sprint en cours ou avant la prochaine release |
| P3 / Moyenne | Planifier dans un sprint futur |
| P4 / Basse | Corriger quand c’est possible, ou accepter et clore |
Priorité et sévérité
La sévérité mesure l’impact : à quel point le produit est cassé. La priorité mesure l’urgence : à quelle échéance il faut corriger. On les évalue séparément parce qu’elles divergent souvent.
- Sévérité faible, priorité haute : un prix erroné affiché dans une bannière pour une campagne qui démarre demain. Rien ne plante, mais tout doit être juste avant le lancement.
- Sévérité haute, priorité faible : un plantage dans un rapport d’administration qui ne s’exécute qu’en fin d’année, dans onze mois.
La priorité évolue aussi dans le temps, alors que la sévérité ne change généralement pas. Ce même plantage de fin d’année devient P1 en décembre.
Comment la priorité est décidée
Questions utiles pendant le triage :
- Combien d’utilisateurs sont touchés, et lesquels (clients payants, équipes internes, un seul tenant) ?
- Existe-t-il un contournement, et le support peut-il l’expliquer ?
- Y a-t-il une échéance de release, de démo, légale ou contractuelle ?
- Quels sont le coût et le risque de la correction elle-même ? Une correction risquée en fin de release peut être reportée délibérément.
Erreurs courantes
- Utiliser un seul champ pour les deux. Les équipes qui ne suivent que la « priorité » perdent l’information sur l’impact, qui compte pour le risque de release et les métriques.
- Tout est P1. Quand la plupart des bugs sont urgents, aucun ne l’est. Gardez le niveau le plus élevé rare et bien défini.
- Ne jamais réviser la priorité. Réévaluez les bugs ouverts quand le plan de release ou la situation client évolue.