Réponse.

Contexte :

Au début des tests, les bugs étaient souvent corrigés sans systématisation. À mesure que le logiciel devenait plus complexe, et que le nombre de tâches et de bugs augmentait, il est devenu nécessaire de prioriser correctement — afin que les ressources soient principalement consacrées aux problèmes critiques et non aux problèmes insignifiants.

Problème :

Sans priorisation, les testeurs, les managers et les développeurs peuvent perdre du temps sur des bugs mineurs, négligeant des erreurs critiques qui peuvent entraîner des pertes financières ou de réputation, des défaillances dans le fonctionnement du produit.

Solution :

Mise en place d'un système de niveaux de priorité :

Les priorités des bugs sont divisées en "Critique", "Élevé", "Moyen", "Bas" (ou niveaux similaires)
La priorité est déterminée en fonction de l'impact du bug sur l'entreprise, l'utilisateur et le système dans son ensemble
Dans les grandes équipes, cela se fait en collaboration avec le product manager

Caractéristiques clés :

Économie de temps et de ressources grâce à la concentration sur les défauts les plus importants pour l'entreprise
Prévention des conflits entre l'équipe QA, le développement et les affaires
Flexibilité de révision des priorités au fur et à mesure que la situation évolue

Questions pièges.

De quoi dépend la priorité d'un bug — de la gravité du défaut ou des priorités commerciales ?

Des deux facteurs. Il existe des bugs de faible gravité technique, mais critiques pour l'entreprise (par exemple, une erreur dans le prix d'un produit sur la page de paiement).

Tous les bugs de même gravité doivent-ils avoir la même priorité ?

Non, il est important de prendre en compte le contexte d'utilisation, la fréquence d'apparition et l'impact sur les indicateurs clés de l'entreprise.

La priorité d'un bug peut-elle changer avec le temps ?

Oui, au fur et à mesure que le projet évolue, que les plans de lancement changent, que de nouvelles exigences apparaissent ou que des retours d'utilisateurs sont reçus, les priorités peuvent être révisées.

Erreurs typiques et anti-patterns

Attribution uniforme d'une haute priorité à tous les bugs
Discussion de la priorité uniquement au sein de QA sans participation du PO/des affaires
Ignorer les bugs avec une priorité "basse", qui sont en réalité critiques

Exemple de la vie

Cas négatif

Sur un site de e-commerce, de petits bugs d'apparence visuelle étaient classés dans le bug tracker avec la priorité maximale, tandis que les bugs liés aux défaillances de l'intégration de paiement étaient classés avec la priorité minimale.

Avantages :

Correction rapide de la partie extérieure esthétique du site

Inconvénients :

Pertes de revenus dues à des paiements non fonctionnels, malgré "l'apparence parfaite" du magasin

Cas positif

Dans l'équipe, les priorités étaient définies collectivement : les bugs empêchant le paiement et le bon fonctionnement de fonctionnalités vitales étaient marqués comme "Critiques" et traités en premier.