La dure réalité à propos des logiciels sans défaut
Il y a de nombreuses années, le jour où nous avons décidé de publier une mise à niveau majeure de notre produit — une décision qui, bien sûr, nécessitait mon approbation en tant que Directeur de l’Assurance Qualité — je marchais dans le couloir lorsque le PDG m’a croisé.
Il m’a arrêté et m’a dit : « Donc, je peux supposer que nous livrons sans aucun défaut ? »
Sans réfléchir autant que j’aurais dû, j’ai répondu avec désinvolture : « Bien sûr que non. Il n’existe pas de logiciel sans défauts. »
Il a été stupéfait et choqué par ma réponse. Il était tellement contrarié qu’il a mis fin à notre conversation et est parti furieux dans le couloir.
À l’époque, j’ai attribué cela au fait qu’il était nouveau dans l’industrie du logiciel et son cycle de vie, venant du secteur de l’édition (longue histoire — une autre fois). Car tout le monde au sein de l’équipe de développement savait que nous livrions avec des défauts. Mais nous savions dès le départ quels étaient ces défauts, et cela faisait toute la différence dans notre évaluation des risques.
Cependant, je remarque avec inquiétude que ce malentendu, tel qu’affiché par mon ancien PDG, est récemment devenu très répandu dans notre secteur. Un logiciel sans bug, « zéro défaut » est un nouveau slogan/mantra que je vois et entends de plus en plus. Et pas seulement de la part de PDG qui n’y comprennent rien (pléonasme, je sais), mais aussi de la part de personnes du métier qui devraient mieux s’y connaître. Et qui, en fait, le savent. Ce que je trouve très préoccupant.
Il y a cependant un sens dans lequel la pensée « zéro défaut » n’est pas qu’un non-sens mensonger et intéressé. En Occident, ce n’est généralement que du vent et de la posture. Mais au Japon, cela a réellement un sens. Et dans toutes ses industries.
J’ai travaillé un an au Japon, et cela m’a complètement bouleversé, mais de façon très positive. Parce que leur définition d’un « défaut » est très différente de la nôtre. Par exemple, s’il y a un emballage de chewing-gum laissé au sol dans l’usine, cela est considéré comme un défaut, au même titre qu’un problème sur une machine ou sur le résultat d’un processus. Si nous étions vraiment sérieux à propos du « zéro défaut », nous réfléchirions à cette question comme le font les Japonais. Mais ce n’est pas le cas, donc nous ne le ferons pas.
Ce que j’essayais de dire à ce malheureux PDG, peut-être trop franchement, c’est que tout logiciel commercial moderne est d’une complexité infinie, et les façons dont il peut interagir avec lui-même ou avec son environnement le sont donc également. Il n’est possible de trouver tous les défauts que si l’on dispose d’un temps infini pour tester. Mais aucun d’entre nous n’est immortel.
Même si l’on pouvait trouver absolument tous les défauts dès le premier essai, on n’aurait pas le temps de tous les corriger et de sortir un produit avant la fin du siècle — le délai de mise sur le marché est une contrainte bien réelle. Donc, même détectés, il faudra livrer avec eux.
La notion même de « logiciel zéro défaut » est donc intrinsèquement illusoire dès le départ.
D’où vient la notion de logiciel « zéro défaut » ?
La racine de cette illusion, c’est l’idée que le rôle de l’Assurance Qualité serait « d’assurer » la qualité. Ce n’est absolument pas le cas. Cette tâche incombe à la gestion produit et à l’ingénierie. Le rôle de l’assurance qualité est d’*évaluer* leur degré de réussite dans cette mission.
Mais il existe un autre aspect pernicieux à ce problème.
Récemment, j’ai discuté précisément de ce sujet avec un développeur logiciel. Il m’a expliqué que la façon dont on lui avait présenté la signification du « logiciel zéro défaut » correspondait exactement à ce que je viens de dire ci-dessus. Cela signifie livrer en ayant corrigé tous les bugs que l’équipe jugeait nécessaire de corriger pour pouvoir livrer. Et en gardant tous les défauts qu’elle avait décidé de ne pas corriger. Une définition à laquelle, soit dit en passant, mon interlocuteur n’adhérait pas.
Or, c’est clairement un jeu de mots trompeur. Vous livrez réellement avec des défauts, et vous le savez, mais vous utilisez le slogan « zéro défaut » pour vous dissimuler cette réalité — et aussi à la direction, évidemment. Qui, comme chacun sait, est facilement hypnotisée par des slogans creux qui la rassurent sur sa réussite.
Il s’agit simplement d’une réduction sélective des défauts, rien de plus.
Comment sortir du leurre du zéro défaut ?
Le fondement de cette supercherie réside justement dans le langage, un langage qui façonne et contraint notre pensée avant même que nous puissions commencer à répondre conceptuellement à ce que l’on affirme. C’est ce faux langage qui crée d’emblée la nécessité d’expliquer pourquoi il est erroné. Et ainsi, nous commençons à nous retrouver piégés par le vocabulaire d’un slogan.
C’est une pratique tellement courante dans le développement logiciel. Ce n’est malheureusement pas cantonné au fait de se mentir à soi-même au sujet des « zéro défauts ». Cela infecte tous les niveaux de notre manière de penser et d’agir, en tant que testeurs, dans nos processus de développement, dans nos méthodologies et dans nos métriques.
Regardons les choses en face, il est temps d’admettre la réalité de ce que nous faisons et de ce que nous ne faisons pas. Et la première étape de ce changement est d’utiliser un langage qui décrit honnêtement cette réalité. Car si le langage que nous employons pour communiquer sur ce que nous faisons est, lui-même, fondamentalement frauduleux, malhonnête et illusoire, alors nous ne fabriquons pas de logiciels de qualité. Nous produisons de la propagande.
L’autre problème du discours sur le « logiciel zéro défaut », c’est que même s’il s’agit d’un objectif sincèrement poursuivi — au sens où les gens croient sincèrement que c’est possible, et qu’il ne s’agit pas seulement d’une posture cynique — un autre problème, plus sérieux, limite l’utilité de cette idée. Ce problème est le suivant :
Comment pourriez-vous savoir, et prouver, que vous avez trouvé « tous » les défauts existant dans le logiciel testé ? Et pas seulement le nombre de défauts que vous avez réussi à trouver dans le temps imparti ? Comment pourriez-vous vous assurer que l’ensemble de bugs découverts constitue la totalité des bugs réellement présents dans le logiciel ?
Vous ne le pouvez pas. Car cela impliquerait qu’il existe un processus extérieur au contrôle qualité (QA) lui-même pour en décider. Sinon, ce n’est qu’un raisonnement circulaire. Et quel serait ce processus externe ?
Et cela reste vrai quel que soit le nombre de bugs déjà découverts. Vous pourriez en avoir trouvé un million. Cela ne prouve pas qu’il n’y a pas un millionième et unième bug qui rôde quelque part dans les recoins du logiciel.
Y a-t-il quelque chose de précieux dans le concept de zéro défaut ?
Les problèmes logiques et épistémologiques flagrants que pose l’idée de « logiciel zéro défaut » sont tout simplement insurmontables. L’expression elle-même est irréparable, quelle que soit la façon dont on la reformule.
Mais si l’on va au-delà du slogan trompeur, pour s’attacher à ce qui le rend séduisant et intellectuellement légitime aux yeux de certains, on y trouve toutefois matière à réflexion.
Ce « quelque chose » est une question différente, mais qui répond aux besoins pratiques et émotionnels apparemment adressés par le faux discours du logiciel zéro défaut, et d’une façon plus cohérente et défendable.
La problématique que les professionnels du logiciel tentent réellement de cerner à travers cette forme d’auto-illusion est en réalité d’une simplicité trompeuse. À savoir : « Quand sait-on que l’on peut arrêter de tester ? »
C’est la seule question que je pose aux candidats aux postes de responsable QA dans mon organisation. Parce qu’au fond, c’est la question essentielle à laquelle le contrôle qualité (QA) doit répondre. Et s’il ne peut pas, le QA est une perte de temps complète. Pour y parvenir, il nous faut d’abord répondre à une question préalable.
Zéro défaut vs % de couverture de test
Comment savoir si les défauts déjà identifiés — quel que soit leur nombre — peuvent être raisonnablement considérés comme représentatifs de l’enveloppe de risque créée par la façon dont le logiciel testé a été conçu et spécifié ? De telle sorte que l’on puisse affirmer avec confiance que les défauts restants non détectés constituent un risque acceptable pour la décision de publier le logiciel ?
Posée ainsi, il apparaît que cette question n’est absolument pas une question de défauts. C’est une question de couverture de test. Votre analyse des bugs découverts, aussi nombreux soient-ils, ne signifie rien si elle ne peut être corrélée à une compréhension analytique de la couverture de test atteinte à ce jour par l’effort QA, en regard de la couverture restant à réaliser.
En effet, si cet ensemble de défauts connus — peu importe le temps passé à tester — ne représente que 30 % de couverture de test réelle, et que vous ne le savez pas, vous n’avez aucune base rationnelle pour comprendre ce que cela implique dans la perspective d’une décision de livraison.
La véritable discussion autour des efforts QA réellement efficients et leur but ultime ne peuvent pas porter sur « zéro défaut », mais sur la « couverture de test à 100 % ». Pour la raison explicitée ci-dessus.
Le grand avantage de cette approche de la qualité logicielle est qu’elle repose sur une définition de la couverture de test jugée suffisante par le QA, avant le début des tests. Ainsi, cette définition-même peut être confrontée aux spécifications, aux exigences, aux problèmes passés rapportés par les clients, à leurs besoins, etc., puis être adaptée si besoin.
Aller de l’avant : couverture de test sans lacune
Raisonner le problème en termes de défauts est voué à l’échec, précisément parce que ce n’est pas un critère que l’on puisse définir de manière pertinente à l’avance, le nombre et la gravité des problèmes ne pouvant être connus qu’après les tests.
En outre, il n’est pas jugé selon une définition (pertinente) préexistante du seuil que pourrait représenter le « zéro ». Définir le succès à l’aide d’une variable qui, elle-même, est indéfinie et non définissable, relève de la perte de temps.
C’est pourquoi la seule manière de réhabiliter la notion de logiciel zéro défaut consiste à réorienter cette démarche et cette planification vers une couverture de test sans lacune. La motivation derrière le mantra du zéro défaut n’est pas condamnable en soi. Elle a seulement été égarée par rapport à sa cible réelle. Corrigez cela, et la définition d’une qualité logicielle acceptable devient enfin mesurable et concrète.
Si vous souhaitez en apprendre davantage, et tirer profit de l’expérience d’experts et de PDG, voici un podcast que nous pensons que vous apprécierez : COOPÉRATION, IA ET CONTENEURISATION (AVEC MICHAEL RITCHSON DE LA NASA)
À lire également : 10 MEILLEURS OUTILS DE SUIVI DES DÉFAUTS POUR LES TESTS LOGICIELS
