Glossaire · Fondamentaux du test
Sévérité d’un bug
En anglais : Bug severity
Également appelé : sévérité d’un défaut, gravité d’un bug, niveaux de sévérité
Définition
L’impact d’un défaut sur le système ou ses utilisateurs, d’un plantage complet ou d’une perte de données jusqu’au simple problème cosmétique ; elle est fixée par la QA.
La sévérité d’un bug décrit à quel point un défaut affecte le produit : ce qui casse, pour qui, et s’il existe un contournement. C’est un jugement technique sur l’impact, et ce sont généralement les testeurs qui l’attribuent lorsqu’ils signalent le bug. La sévérité ne dit rien directement de la date à laquelle le bug sera corrigé ; c’est le rôle de la priorité.
Échelle typique
Les noms varient selon les équipes et les outils de suivi, mais la plupart utilisent quatre ou cinq niveaux :
| Sévérité | Signification | Exemple |
|---|---|---|
| Critique / Bloquant | Système hors service, perte ou corruption de données, faille de sécurité, aucun contournement | Le paiement renvoie une erreur 500 pour tous les utilisateurs |
| Majeure / Haute | Une fonctionnalité principale est cassée ou erronée, le contournement est pénible ou inexistant | Les remboursements sont calculés avec le mauvais taux de TVA |
| Modérée / Moyenne | Fonctionnalité partiellement cassée, un contournement raisonnable existe | L’export CSV ignore le filtre de date ; on peut filtrer dans un tableur |
| Mineure / Basse | Petit problème fonctionnel à faible impact | L’ordre de tri d’une liste rarement utilisée est inversé |
| Triviale / Cosmétique | Problème visuel ou de texte, sans effet fonctionnel | Icône mal alignée, faute de frappe dans une infobulle |
Sévérité et priorité
Sévérité = impact du défaut (technique, fixée par la QA). Priorité = urgence de la correction (métier, fixée par le product owner ou en triage).
Elles sont indépendantes, c’est pourquoi les recruteurs demandent souvent un exemple de chaque combinaison en entretien :
- Sévérité haute, priorité faible : l’application plante lors de l’import d’un format de fichier qu’un seul client historique utilise une fois par an.
- Sévérité faible, priorité haute : le nom de l’entreprise est mal orthographié sur la page d’accueil la veille d’un lancement.
- Sévérité haute, priorité haute : le paiement échoue pour tous les utilisateurs.
- Sévérité faible, priorité faible : une faute de frappe sur une page de paramètres rarement consultée.
Erreurs courantes
- Gonfler la sévérité pour faire corriger un bug plus vite. C’est le rôle de la priorité. Une sévérité gonflée vide la métrique de son sens.
- Évaluer selon la difficulté à trouver le bug. Évaluez selon l’impact sur les utilisateurs et le métier, et précisez qui est touché et à quelle fréquence.
- Ignorer le contournement. Une même défaillance est plus sévère quand il n’existe aucun moyen de la contourner.