Un avis ? Un commentaire ?
Cet espace est pour vous.
Dans le métier du test, les 7 principes généraux du test logiciel sont un peu comme les 7 nains de Blanche Neige ; sympathiques, familiers, on s’amuse parfois à tous les citer.
Toutefois, ces principes peuvent donner lieu à des extrapolations parfois dangereuses ; cet article vise à mettre en garde contre celles-ci.
Les tests montrent la présence de défaut dans l’applicatif, et il est impossible de prouver l’absence de défaut. Très bien, vous connaissez maintenant ce refrain par cœur ! C’est d’ailleurs un refrain consolant, un peu comme « personne n’est pas parfait » ou « l’erreur est humaine ».
Et maintenant, si on changeait de perspective ?
Les défaillances d’un applicatif en production montrent la présence de défauts… dans les tests. Dans cette optique, il est logiquement impossible de prouver que des tests sont dénués de défauts, et sont parfaitement adaptés à une application.
Il est donc dommage de penser « Une défaillance a eu lieu en production, mais ce n’est pas notre faute, car les tests montrent la présence de défaut, pas leur absence. »
Il est plus utile de se dire « Une défaillance a eu lieu en production, les défaillances montrent la présence de défauts dans les tests ; corrigeons maintenant notre façon de tester. »
Comme le dit la locution, l’erreur est humaine, mais persévérer dans l’erreur est diabolique !
Ce deuxième principe, au même titre que le premier, peut être utilisé comme un bouclier pour contrer les attaques de décideurs ou de clients mécontents.
Les tests exhaustifs sont impossibles, certes. Le périmètre des tests est limité, car le temps alloué à la qualité est limité.
Mais ce temps est-il utilisé au mieux ?
Les tests exhaustifs sont impossibles, mais des tests pertinents sont possibles.
Il est important de tester tôt.
Il est important aussi de savoir quand il est trop tôt pour tester.
Le principe « Tester tôt » doit toujours être conditionné par l’exigence de « Tester utile ». Il est infiniment utile de décortiquer des spécifications avec un œil de QA avant l’écriture de la moindre ligne de code. Il est infiniment inutile d’écrire des tests qui ne seront peut-être jamais exécutés.
Tu préfères rapporter 1 bug ou 10 bugs ?
Formulée comme ça, « la question elle est vite répondue ». Voici maintenant une variante :
Tu préfères rapporter 1 bug majeur qui importe vraiment aux parties prenantes, ou 10 bugs mineurs qui n’embêteront que toi et qui seront corrigés à la Saint-Glinglin ?
Quand on tombe sur un « nid à bugs », il est tentant d’y passer du temps et de remonter consciencieusement tout ce qu’on trouve anormal. Pour autant :
Autre point à noter : il arrive que l’on croie tomber sur un « tas de bugs », alors qu’il s’agit d’un même défaut qui provoque plusieurs défaillances.
Un champ entier d’orties est moins dangereux qu’un seul piège à loup.
EDIT du 23/02/2024 : avec la nouvelle version du syllabus ISTQB Fondation (2023), le principe du paradoxe du pesticide a été remplacé par la notion d’usure des tests.
Rappelons d’abord ce qu’est le paradoxe du pesticide, un principe qui n’est pas si simple à comprendre.
En France actuellement, l’été arrive, avec son lot agréable de soleil, sorbets et transats, et aussi son lot désagréable de moustiques.
Mettons qu’un laboratoire mette au point un antimoustique révolutionnaire, le Blanuin3000, qui dissuade 99,99 % des moustiques de piquer les humains qui s’en aspergent la peau. Cet antimoustique fait ses preuves, et pendant tout l’été les humains sont quasiment débarrassés des nuisances associées.
En parallèle, les 0,01% de moustiques résistants profitent d’un avantage certain : comme ils peuvent profiter des proies humaines, ils sont moins susceptibles de mourir de faim ou de manquer des éléments nutritifs qu’apporte le sang humain.
L’été suivant, une nouvelle génération de moustiques arrive. Certains ont légèrement muté, et ne sont plus indisposés par l’odeur du Blanuin3000. Quant aux descendants des 0,01%, ils sont un peu plus nombreux, grâce à l’avantage évoqué. Le Blanuin3000 n’est donc plus efficace qu’à 70 %. Scandale !
Le paradoxe est le suivant : on ne peut pas se contenter d’une solution, même si celle-ci est efficace à près de 100% à un instant T.
Mettons qu’un cas de test vérifie 100 configurations sur 1000 configurations possibles. Ces 100 configurations auront été sélectionnées pour être les plus représentatives possibles, par exemple en réduisant la combinatoire avec des techniques de type Pairwise.
A la première exécution des tests, 10 configurations sont en échec ; toutes donnent lieu à un correctif.
Après la découverte des bugs de la version 1 et leur correction, des tests unitaires ont pu être mis en place pour vérifier les cas ayant donné lieu à des défaillances ; il est donc extrêmement improbable de retrouver les mêmes défaillances sur les jeux de données. Il serait profitable de couvrir d’autres jeux de données, de même que le Blanuin3000 pourrait contenir de nouveaux principes actifs pour repousser encore plus de moustiques.
A la deuxième exécution, après correction, les 100 mêmes configurations sont vérifiées avec succès. Félicitations, enfin un « logiciel sans bug » ! Ou pas. La vraie question à se poser : parmi les 900 cas non testés, est-il possible que certains soient en mesure de trouver des régressions non identifiées par les tests existants ? Si oui, alors nous sommes face au paradoxe du pesticide.
Bien que les bugs ne se multiplient pas à la manière des moustiques, ils se cachent parfois dans des jeux de données particuliers.
Mais quand un bug passe entre les mailles du filet, cela peut être à cause du paradoxe du pesticide… ou bien à cause d’une mauvaise conception des tests.
Le paradoxe du pesticide se comprend dans la durée ; de même, une régression est un écart qui se constate dans la durée, d’une situation A en succès à une situation B en échec.
Bref : à chaque bug son pesticide. Modifier un test X ne sert à rien quand il faudrait écrire un nouveau test Y. Les deux prennent du temps : à quoi choisirez-vous de vous consacrer ?
Avez-vous déjà participé à un projet adoptant des processus et méthodes brinquebalantes, utilisant des termes Scrum à tort et à travers, et dont les membres se félicitaient d’avoir mis l’agilité à leur sauce ? (Avant de se rendre compte quelque mois plus tard que cela ne tenait pas, et de conclure avec amertume que « finalement l’agilité ce n’est pas si efficace que ça »…) « Le contexte » est souvent pris comme excuse pour se laisser aller à des pratiques peu efficaces, mais qui offrent une satisfaction immédiate.
Quelques exemples :
En 1977, à Harvard, Ellen Langer a démontré le pouvoir du « parce que ». Un complice devait s’adresser à des personnes faisant la queue devant une photocopieuse en formulant une de ces deux phrases :
La première phrase a obtenu 60 % de succès, contre 93 % pour la suivante. Bien que totalement redondante, l’excuse « parce que j’ai des photocopies à faire » est quasiment aussi efficace que « parce que je suis pressé » (94 % de réussite).
De même que « parce que », le « contexte » semble agir comme un mot magique permettant de faire tomber les objections alors même qu’il reste très vague. Restons à l’affût : apprêtons-nous toujours à demander des précisions sur ce contexte, et interrogeons-nous nous-mêmes sur sa véritable signification au moment où nous invoquons cette raison.
L’illusion d’absence d’erreur est celui des 7 principes qui est le moins contestable. Non seulement il permet à chaque membre de l’équipe de garder un œil critique sur l’applicatif en cours de développement, mais il permet aussi de guider les tests. L’illusion d’absence d’erreur met le focus sur les utilisateurs finaux et leurs besoins réels ; avoir à l’esprit ces personnes à tout moment nourrit la conception et la priorisation des tests.
Cette notion gagne à être connue ; elle n’est pas seulement un principe général du test logiciel, mais de manière plus large, un principe général du monde de l’IT.
Et vous, avez-vous déjà constaté des dérives possibles des 7 principes généraux des tests logiciels ? Si oui, indiquez-les en commentaire !
Cet espace est pour vous.