-
Adresse d'origine : Pourquoi les bugs ne sont pas corrigés
Auteur : Alan Page, directeur de l'excellence en ingénierie des tests chez Microsoft, co-auteur du livre How We Test Software at Microsoft (traduit du chinois par « Microsoft's Software Testing Way »).
Traduction : Lu Yueli, Lu Mengyan, Wang Hong
Dernièrement, j'ai rencontré de plus en plus de gens surpris que nous sortions un produit buggé. Ce qui m'a surpris, c'est que beaucoup de ces personnes étaient des testeurs de logiciels, et je pensais qu'ils le savaient déjà. Je vous suggère de lire d'abord l'article précédent (mais excellent) d'Eric Sink. Je ne sais pas dans quelle mesure je peux contribuer davantage à ce sujet, mais je veux essayer.
De nombreux bugs ne valent pas la peine d’être corrigés. "Etes-vous testeur ?", me crierez-vous, "Les testeurs sont les gardiens de la qualité des produits." Je peux le répéter (si nécessaire) de nombreux bugs ne valent pas la peine d'être corrigés. "Laissez-moi vous dire pourquoi. Dans la plupart des cas, corriger un bug nécessite de changer le code. Et changer le code nécessite un investissement de ressources (de temps) et introduit des risques. C'est nul, mais c'est vrai. Parfois, si le risque et l'investissement sont loin l'emportent sur la valeur de la correction des bugs, nous ne les corrigerons donc pas.
Notre décision de corriger ou non un bug n'est pas, et ne devrait pas être, basée sur le « ressenti ». J'aime utiliser le concept de « douleur de l'utilisateur » pour m'aider à prendre des décisions. J'utilise trois facteurs clés pour considérer et identifier la « douleur des utilisateurs » :
1. Gravité – Quel impact ce bug aura-t-il – va-t-il faire planter l’ensemble du programme ? Cela entraînera-t-il la perte des informations de l'utilisateur ? Ou alors ce n'est pas si grave ? Existe-t-il une solution plus simple ? Ou est-ce simplement un problème sans importance ?
2. Fréquence – Les utilisateurs rencontrent-ils fréquemment ce problème ? Cela fait-il partie du flux de travail principal du programme ? Ou est-il caché dans une fonctionnalité qui n’est pas couramment utilisée ? Les petits problèmes qui existent dans les parties les plus couramment utilisées du programme devront probablement être résolus, tandis que certains gros problèmes qui existent dans les parties les moins utilisées du programme pourront être mis de côté.
3. Impact sur les clients – Si vous avez bien fait vos devoirs, vous devriez déjà savoir qui sont vos clients et combien (ou combien vous espérez avoir) d'utilisateurs il y aura dans chacun de vos groupes de clients. Ensuite, vous devez juger si ce problème affectera tous les utilisateurs ou seulement certaines personnes. Si vous pouvez suivre la manière dont les clients utilisent votre produit, vous pouvez obtenir des données plus précises.
Les trois facteurs ci-dessus constituent une formule. Attribuez une plage de valeurs à chacun des facteurs ci-dessus et effectuez quelques calculs - vous pouvez directement ajouter, multiplier ou ajouter des pondérations en fonction de votre application et des facteurs du marché. Par exemple, il suffit d'effectuer une addition et d'attribuer une plage numérique de 10 points à chaque bug.
Bug n°1 : Par exemple, c'est un bug qui fait planter le programme (10 points), il existe dans une partie majeure du programme (10 points), et il affecte 80% des clients (8 points), donc ce bug provoque « douleur de l'utilisateur » « Le volume est de 28 points et nous parions que nous allons le réparer.
Bug n°2 : C'est juste un bug d'arrangement (2 points), il apparaît dans la fenêtre secondaire (2 points), et la partie du programme où se trouve le bug ne sera utilisée que dans les anciennes versions (2 points). Par conséquent, la valeur de « douleur utilisateur » de ce bug est de 6 points, et nous ne le corrigerons probablement pas.
Malheureusement, de nombreuses situations ne sont pas aussi simples que celles décrites ci-dessus. Le bug n°3 est un problème de perte de données (10 points) qui existe dans la majeure partie d'une application mais qui n'échoue que dans certaines circonstances (5 points) (les données sont subjectives, d'ailleurs). Les recherches clients prouvent qu'il est rarement utilisé (2 points). Sa valeur de « douleur utilisateur » est donc de 17 points. Il s'agit d'une donnée ambiguë, modifiable ou non. D'une part, l'investissement requis pour le réparer n'en vaut peut-être pas la peine, mais tant que le problème est compris et qu'il ne présente aucun angle mort, ignorer le bug est probablement la bonne approche.
D’un autre côté, vous devez le comparer aux autres bugs du système. Nous appliquons ici l'effet "Fenêtre cassée" - s'il y a trop de bugs de ce type à seuil moyen dans l'application, la qualité du produit (ou du moins la perception de la qualité) en sera grandement affectée. Lorsque vous examinez chaque bogue du système, vous devez également prendre en compte les autres bogues (connus) du système et les utiliser pour analyser et décider quels bogues doivent être corrigés et lesquels ne valent pas la peine d'être corrigés.
C'est en effet une très mauvaise chose d'avoir des bugs dans les logiciels officiellement publiés - mais sur la base de nos outils et langages de développement existants, nous n'avons pas encore trouvé de solution plus raisonnable.
Remplir:
Au moment où j'écris ceci, je pense qu'il me manque un quatrième facteur dans la formule : la date de sortie. Ce facteur joue également un rôle clé dans la décision de corriger ou non un bug à l'approche de la date de sortie. Cependant, je ne sais pas s'il s'agit du quatrième facteur, ni quel est le seuil du niveau de « douleur de l'utilisateur » requis pour corriger un bug à l'approche de la publication.