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éfauts… mais ils ne sont pas les seuls !
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 !
Les tests exhaustifs sont impossibles… oui, mais ne partons pas défaitistes
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.
Tester tôt… oui, mais restons calmes
Il est important de tester tôt.
Il est important aussi de savoir quand il est trop tôt pour tester.
- Un produit est en cours de réflexion. Des cas d’utilisation ont été écrits. Des réunions de brainstorming ont lieu régulièrement, les plans changent au fur et à mesure… Il n’est pas trop tôt pour se pencher sur une stratégie de test, voire sur un début de conception des tests, mais il est bien trop tôt pour rédiger les cas de test en détail.
- Un MVP est en cours d’implémentation. Des interfaces sont disponibles. Cette première mouture donnera peut-être lieu à un projet à long terme, mais ce n’est pas sûr. Il n’est pas trop tôt pour réaliser des tests ad hoc, voire des tests exploratoires, mais il est beaucoup trop tôt pour se lancer dans l’automatisation des tests !
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.
Les défauts se regroupent… oui, mais il convient de qualifier ces regroupements
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 :
- Tous les bugs ne se valent pas
- Si certaines zones de l’application sont et restent buggées version après version, c’est peut-être qu’elles n’importent pas tant que ça
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.
Le paradoxe du pesticide existe… oui, mais cette image doit être bien analysée
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.
Qu’est-ce que cette histoire d’antimoustique ?
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.
Le paradoxe du pesticide dans le monde du test
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.
Les araignées n’ont que faire de l’antimoustique
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.
- Si une régression n’est pas détectée par des tests dont les jeux de données sont comparables, nous sommes en présence du paradoxe du pesticide. Il aurait été utile de modifier un peu les tests existants.
- Si cette régression n’aurait pu être détectée que par un test spécifique, qui n’a jamais été imaginé, on est tout simplement face à un problème de conception des tests.
- Si le bug n’est pas une régression, on ne peut pas parler de paradoxe du pesticide, tout simplement parce qu’il n’y a pas de notion de durée.
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 ?
Les tests dépendent du contexte… oui, mais « le contexte » n’est pas un mot magique
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 :
- « Nous avons adopté le cadre Scrum pour ce projet. Dans ce contexte, toute documentation doit être bannie. » Quelle mésinterprétation courante, et quelle aubaine pour les personnes qui détestent écrire de la documentation ! Rendez-vous quelques mois plus tard, quand de nouveaux devs arriveront et demanderont où sont le README et les règles de gestion détaillées.
- « Nous développons un produit interne, dans ce contexte nous n’avons pas besoin d’une interface responsive. » La bonne occasion d’économiser des bouts de chandelle et de râper un peu les coûts de développement. Rendez-vous à la mise en prod, quand les utilisateurs découvriront avec horreur qu’ils ne peuvent pas travailler en réduisant la taille du navigateur.
- « C’est un petit projet, on n’est que 5 dans l’équipe Scrum. Dans ce contexte, on n’a pas forcément besoin de faire un daily tous les jours… »
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 :
- « Excusez-moi, puis-je utiliser la photocopieuse ? »
- « Excusez-moi. Puis-je utiliser la photocopieuse parce que j’ai des photocopies à faire ? »
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 un risque courant… oui, et la responsabilité est partagée
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 !