Coup de Gueule: arrêtez de me parler de 0 Bug!

Introduction

Si vous êtes dans le test depuis quelques années vous n’avez pas pu échapper au « 0 bug ».

Cette notion se voit régulièrement à travers:

• La promesse d’outil de test comme des outils d’automatisation ou de modélisation
• Les attentes de managers ou les annonces de certains bilans de test
• Des articles ou des communications…

Cette notion m’insupporte de plus en plus. Plus je connais le test logiciel, plus je ressens que le « 0 bug » est une imposture, un concept inatteignable et l’absence de la prise en compte du contexte…

Un de mes tous premiers articles, écrit fin 2016, abordait d’ailleurs ce sujet en montrant que, même s’il était possible d’assurer un 0 bug cela coûterait beaucoup trop cher.

Analyse du 0 bug

Comme dit en intro je retrouve la notion de logiciel à « 0 bug » dans 3 conditions que je propose d’analyser de la situation par ordre croissant de « gravité ».

Des articles ou des communications

Ce point est souvent lié à 2 facteurs.

Le premier est une volonté de vulgarisation envers des non testeurs. Dans cette optique le « 0 bug » est décrit comme « 0 bug » pendant l’utilisation de la majorité des utilisateurs… Cette vulgarisation me pose problème car cela occulte en grande partie le non-fonctionnel comme la sécurité (pendant une session on ne voit pas de bug mais quelqu’un peut nous prendre nos données et les utiliser à notre place…) mais surtout car cela va à l’encontre des 7 principes du test qui restent, selon moi, un des meilleurs points d’entrée pour faire comprendre le test. J’adore la vulgarisation mais il faut éviter des vulgarisation qui véhiculent des contre-sens! Pour rappel, ce ‘est pas parce que l’on a pas trouvé de champignon dans une forêt qu’il n’y a pas de champignons dans celle-ci. C’est pareil avec les bugs!

Le second point est généralement l’objet d’article de personnes n’étant pas des testeurs de métier! Dans ce cas, cela traduit un manque de compréhension du métier.

Ce point reste moins critique que les autres car il a peu de chances de se retrouver appliqué sur un logiciel et d’impacter la qualité ou le coût des tests de ce dernier

Les attentes de managers ou les annonces de certains bilans de test

Ce point commence à être plus problématique et est, selon moi, une dérive de la nomination de QA pour désigner un testeur. En effet QA revient à dire « Assurance Qualité », cette assurance devant justement « assurer » le bon fonctionnement et donc l’absence de bug.

Il est d’ailleurs intéressant de se pencher sur le terme « non-régression » très populaire dans le milieu francophone qui laisse également penser qu’à l’issue d’une campagne de régression, si on n’a pas trouvé de régression c’est qu’il n’y en a pas… Il est pourtant plus honnête de dire que l’on n’a pas trouvé de bug plutôt qu’il n’y en a pas. On en revient à la recherche de champignons.

Le problème de ce point c’est qu’il arrive qu’il soit demandé aux testeurs qu’aucun bug ne passe en production sans qu’il n’ai été identifié en test.

Je me rappelle d’une anecdote où mon manager était rentré dans le bureau des testeurs en remontant un bug décrit par un utilisateur et il nous demandait « pourquoi on n’avait pas trouvé ce bug en test ». La réponse de ma test manager avait alors été très bonne: « on ne peut pas tout tester et trouver tous les bugs ».

Ce type d’attentes (ou de bilan pouvant laisser penser qu’il n’y a pas de bug) est particulièrement problématique car cela peut créer des tensions entre la hiérarchie et les équipes de testeurs qui on « failli » dans leur travail en ne repérant pas un bug… De même cela peut également dériver sur moins de budget sur les tests…

Un des meilleurs points pour éviter ce type de problématique c’est de faire attention à la communication et d’employer des termes ne permettant pas de laisser croire à cette possibilité.

La promesse d’outil de test comme des outils d’automatisation ou de modélisation

Ce point est celui qui me dérange le plus car c’est un mensonge pour pousser à l’achat d’outils. Il m’arrive d’ailleurs d’avoir des mails d’éditeurs assurant le « 0 bug ». Je ne peux honnêtement pas accepter de recevoir ce type de mail de la part d’éditeur proposant des outils dans le test. Même si cela reste du marketing je considère cela comme de la publicité mensongère qui devrait être sanctionnée juridiquement comme tel! En effet, un outil offrant cette fonctionnalité permettrait donc de rendre possible l’impossible (les tests exhaustifs sont impossible et que les tests montrent la présence de défaut et non leur absence), ce qui peut sembler alléchant! D’ailleurs l’homme dans son histoire n’a t-il pas rendu plusieurs fois possible des choses qui semblaient impossible comme voler, discuter en direct avec quelqu’un vivant à des milliers de km ou encore faire Paris Marseille en moins de 3 heures ?

Néanmoins, les outils de tests actuels ne peuvent proposer des ruptures suffisantes pour s’affranchir des principes du test. En effet, les outils assurant du « 0 bug » sont des outils souvent liés à l’automatisation ou la modélisation. Ils sont donc limités par plusieurs points rendant impossible le « 0 bug »:

• L’automatisation des tests c’est avant tout des tests. Les tests exhaustifs sont impossible leur automatisation, même de millions de test, si efficace soit-elle ne peut être suffisante.
• La modélisation est également sujette à des simplifications et des renoncements. Le modèle n’est pas parfait et ne peut donc pas proposer des résultats parfaits.

Conclusion

Le « 0 bug » n’existe pas. Cela ne doit d’ailleurs même pas être un objectif. Le « 0 bug » est en faite une chimère qui ne peut même pas être considérée comme un Graal! Le vrai Graal d’un testeur c’est de proposer des tests et processus adaptés en fonction du contexte, d’arriver pour un coût aussi faible que possible au niveau de qualité adéquate et correspondant au contexte.

Si je devais vous donner un conseil lorsque vous vous retrouvez avec cette notion de « 0 bug » à atteindre c’est celui-ci: « fuyez! ». Évitez cet environnement ou, si ce n’est pas possible, battez-vous pour éradiquer cette notion. Même dans l’aéronautique où les tests sont très poussés il reste des anomalies.

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.