Auteur/autrice : hightest

L’automatisation des tests est une piste que vous voulez investir. Vous souhaitez, par cette démarche, maîtriser les coûts associés à la qualité, bénéficier d’une meilleure couverture des tests, ou encore mettre en œuvre des recettes plus courtes et efficaces. Très bien, mais par où commencer ? Qui affecter à ce chantier ? Quels tests faut-il automatiser ? Quels KPI suivre ? Quel outil choisir ?

Une fois qu’on a répondu « oui » à la question « faut-il automatiser les tests ? » c’est effectivement une autre ribambelle de questions qui se présentent, comme si on avait ouvert une boîte de Pandore. Pire encore : en répondant mal à ces problématiques, l’automatisation des tests pourrait se solder par un échec.

Dans l’article précédent, nous donnions 10 bonnes raisons d’automatiser les tests. Aujourd’hui, nous vous offrons des clés pour mettre en œuvre concrètement un tel chantier. Accrochez-vous, car les pièges sont nombreux, mais le jeu en vaut la chandelle !

1) Quels challenges et difficultés pose l’automatisation des tests ?

Des challenges autant techniques qu’organisationnels, et la bonne nouvelle c’est qu’il est possible d’en anticiper certains avec un minimum d’effort.

Il est important, avant de se lancer, d’avoir en tête les principales difficultés associées à l’automatisation des tests. Commençons donc par cela, en nous basant sur l’édition 2020-2021 du World Quality Report.

Selon cette source, la problématique la plus fréquente (52 %) est le manque de personnel suffisamment qualifié pour mener à bien l’automatisation des tests. C’est la question du « QUI ».

La deuxième difficulté la plus fréquente (42 %), est liée aux lacunes au niveau des environnements de test et des jeux de données. Un exemple à la fois simple et très fréquent ? L’environnement dédié aux tests automatisés est parfois aussi utilisé par des testeurs humains, qui modifient ou suppriment des ressources dont les tests automatisés ont besoin. Ces actions peuvent provoquer des faux positifs et donner du fil à retordre au moment où on analyse les résultats des tests automatisés. Cette difficulté pointe du doigt une réalité : l’automatisation des tests est un enjeu d’équipe ; si des environnements spécifiques et des données séparées sont requises, il est important d’impliquer l’ensemble des parties prenantes concernées (administrateurs systèmes, métiers…) Automatiser « dans son coin » n’est pas envisageable.

Problème suivant ? 41 % des entreprises rencontrent des difficultés à définir une bonne stratégie d’automatisation. C’est la question du « QUOI ».

D’autres challenges sont également évoqués ; le classique « on n’a pas assez de temps ! » est invoqué par 37 % des entreprises (cela prend en effet du temps de s’arrêter au bord de la route pour remplacer ses roues carrées par des rondes !), juste avant « on n’a pas les bons outils » (32 %).

Au sein de cet article, nous aborderons spécifiquement les questions du QUI et du QUOI, qui constituent la base d’une bonne stratégie d’automatisation des tests.

2) Qui est responsable de l’automatisation des tests ?

Plusieurs leaders possibles

Bien plus de personnes qu’on pourrait l’imaginer de prime abord !

Nous disions plus haut que 52 % des entreprises déclarent manquer de personnel qualifié pour l’automatisation des tests. Les « testeurs automaticiens » sont en effet comme des trèfles à quatre feuilles : ils existent (contrairement aux moutons à 5 pattes…), mais il y en a peu. Restent donc, classiquement, 3 possibilités.

• Faire monter en compétences les testeurs en automatisation des tests
  • CONTRE :
    Le développement n’est pas la tasse de thé de tous les testeurs ; une telle montée en compétences nécessite des efforts importants et une bonne dose de motivation
  • POUR :
    L’automatisation des tests produit des informations dont les testeurs seront en général les premiers bénéficiaires, et ce sont les mieux placés pour savoir ce qui doit être automatisé
• Déléguer l’automatisation aux développeurs
  • CONTRE :
    L’automatisation des tests est une activité de test, les développeurs peuvent avoir du mal à adopter l’état d’esprit critique qui rend les tests efficaces
  • POUR :
    L’automatisation des tests est une activité de développement, les développeurs sont naturellement en mesure de s’y adonner
• Externaliser la mise en place de l’automatisation des tests
  • CONTRE :
    Cette démarche peut être moins féconde si vous la décorrélez totalement des autres activités de test ; même « externes », les automaticiens auront besoin de s’immerger dans la vie du projet
  • POUR :
    Les prestataires aguerris connaissent les principaux écueils et les évitent plus facilement ; leur œil extérieur leur permet de questionner la démarche et de proposer une solution sur mesure.

Mais il ne suffit pas de répondre à cette question pour se tirer d’affaire ; c’est un arbre qui cache une forêt. Il faut ouvrir un autre tiroir de questions !

Des responsabilités multiples

En effet, l’automatisation des tests recouvre une multitudes d’activités, et l’implémentation des tests automatisés n’est qu’une d’entre elles.

Nous préconisons de réaliser une matrice des responsabilités (ou matrice RACI) afin d’établir, en amont du projet, qui interviendra sur quoi, et de répondre aux questions suivantes :

• Qui choisira les tests qu’il faudra automatiser ?
• Qui implémentera les tests automatisés ?
• Qui lancera les tests automatisés ?
• Qui analysera les résultats et rapportera les anomalies ?
• Qui consommera les reportings des tests automatisés ?
• Qui maintiendra les tests automatisés ?
• Qui assurera la disponibilité des environnements dédiés aux tests automatisés ?
• Qui produira les jeux de données nécessaires ?
• (Et enfin, la question qui tue !) Qui sera responsable de la réussite de la démarche d’automatisation des tests ?

Il est important de répondre à ces questions, car elles permettent également de se rendre compte qu’il y a souvent plus de personnes qu’on l’imagine qui sont impliquées dans la démarche.

3) Quels tests faut-il automatiser ?

Pour trouver la meilleure liste de tests à automatiser, il faudra encore une fois se poser les bonnes questions.

Cette partie est dédiée aux 41 % qui peinent à établir une stratégie d’automatisation efficace !

Comme de bons tests prennent leur source dans de bonnes questions, voici celles que nous préconisons pour aider à définir le périmètre des tests automatisés :

Quels tests sont les plus critiques ?

Cette question est la plus évidente. Les tests révélateurs de la santé de l’application sont souvent les premiers que l’on souhaite automatiser. On les appelle les « smoke tests », par analogie à des tests que l’on ferait sur une machine industrielle par exemple : si vous appuyez sur le bouton de marche et que de la fumée sort de la machine, vous aurez détecté un bug bloquant en quelques secondes.

Quels sont les modules ou fonctionnalités qui, historiquement, sont les plus buggées ?

Cette question vaut surtout quand on initie tardivement le projet d’automatisation, et qu’il faut sécuriser les « nids à bugs ».

Quand on lance le projet d’automatisation en même temps que le projet de développement (une bonne pratique permettant de maximiser le ROI des tests automatisés), on peut se baser sur son expérience de projets similaires, puis étudier a fil de l’eau les modules où les bugs se concentrent.

Quels sont les tests les plus répétitititititi…tifs ?

Vous avez peut-être en tête ce formulaire qui compte 36 champs, ces champs pouvant être remplis de diverses manières, et chacune de ces manières devant être testée. L’œil est vigilant au premier remplissage, il persiste au deuxième, tient encore bon au troisième, puis il se perd, on ne sait plus ce qu’on a déjà rempli, on se trompe, on s’ennuie, et on a vraiment envie de passer à autre chose. Dommage, c’est à ce moment-là qu’on aurait pu détecter un joli bug.

Ces problèmes sont étrangers aux scripts de tests automatisés, c’est pourquoi les tests très répétitifs sont souvent de bons candidats à l’automatisation.

Quels sont les tests les plus rejouables ?

Il y a des tests qu’on ne peut jouer qu’une fois par an, qu’une fois par trimestre, ou encore une fois par jour. Il y a le fameux « batch de 4 heures du matin », la « moulinette du dimanche soir » et le « programme du 31 décembre ». Est-il vraiment intéressant d’automatiser les tests associés ? Pas sûr. Autant que possible, il est intéressant d’automatiser les tests facilement rejouables.

Quels sont les tests les plus difficiles à comprendre ?

Dans l’article précédent, nous parlions du fait que les tests automatisés constituent une documentation vivante du fonctionnement de l’applicatif. C’est un avantage quand ce fonctionnement est complexe. Un test difficile à comprendre sera peut-être mal effectué par un humain néophyte ; en l’automatisant, on se prémunit contre ce risque, et on donne en même temps plus de visibilité sur le fonctionnement précis du système à tester. Coup double !

Quels sont les tests qui seraient les plus faciles à implémenter ?

Il est souvent mal vu de commencer par le plus facile, de « choisir la facilité ». Ce n’est effectivement pas le premier critère à prendre en compte, mais la facilité d’implémentation est tout de même un élément important à avoir en tête. On veut des quick wins, pas des challenges insurmontables qui pourraient décourager l’équipe !

Synthèse des 6 questions

Comment utiliser efficacement ces 6 questions ? Afin de définir le périmètre à automatisés, il est nécessaire de :

• Pondérer l’importance de chacune des questions
• Répondre, pour chaque test ou suite de tests, à ces questions (sur une échelle de 1 à 5 par exemple)

En faisant une moyenne de ces scores, pondérée par l’importance des questions, on est alors en mesure de construire un périmètre à automatiser de manière solide et argumentée.

Chez Hightest, nous nous servons d’un modèle de tableur afin d’effectuer ce travail ; nous le partageons avec plaisir sur simple demande.

Tant d’autres questions…

Au sein de cet article, nous nous sommes concentrés sur QUI intervient dans la démarche d’automatisation des tests, et QUOI automatiser.

Nous pensons sincèrement que ces trois questions sont trop peu souvent posées, et que cela constitue une source importante d’échecs dans les projets d’automatisation des tests.

D’autres questions viendront ensuite, mais attention à ne pas mettre la charrue avant les bœufs ! En voici quelques-unes :

• Quels KPI mettre en œuvre pour mesurer l’efficacité de la démarche d’automatisation des tests ?
• Quelles mesures qualitatives surveiller en complément ?
• Et le grand classique, la question qu’on a tendance à poser en premier et qui détrône toutes les autres… Quel outil choisir ?

« Quel outil choisir »… Il faudrait un article dédié (voire, plutôt, une série d’articles) pour répondre à cette question ! En attendant, voici quelques articles de notre blog qui vous donneront des éléments.

• Selenium, ses logs, ses relative locators et sa certification.
• HP UFT, et sa comparaison avec Selenium
• Cypress, un concurrent redoutable de Selenium
• Jenkins, sa gestion des paramètres, son intégration avec JMeter
• Katalon, outil d’automatisation des tests mobiles
• Pywinauto, outil gratuit et open source d’automatisation des applications lourdes

Nous espérons que cet article vous aura apporté des éléments utiles à votre démarche. A bientôt pour de nouveaux articles sur ce sujet passionnant qu’est l’automatisation des tests !

Nos organisations reposent d’ores et déjà presque toutes sur des systèmes d’informations ou d’autres outils numériques sans qui elles ne peuvent clairement plus fonctionner correctement.

Au-delà des enjeux professionnels, quand une population entière repose sur un logiciel, les enjeux deviennent parfois des enjeux de santé publique (santé, énergie, télécommunication, etc).

C’est de cette dépendance aux outils numériques et aux risques associés qu’est née la notion de qualité logicielle et la discipline du test logiciel.

Pourquoi automatiser ses tests ?

Recettes à rallonge, coûts non maîtrisés, testeurs épuisés, résultats de test insatisfaisants, difficiles à interpréter, incomplets… Sortir une application ou un logiciel est trop souvent douloureux au sein des organisations.

L’automatisation des tests a le vent en poupe et fait fantasmer un avenir où les bugs seront gommés, sans aucun effort. Au-delà de l’utopie, de nombreuses raisons peuvent effectivement interroger sur la pertinence de cette démarche dans un contexte d’amélioration de sa qualité logicielle.

Vous êtes impactés au quotidien par la non-qualité et cherchez désespérément une solution pour limiter ses effets sur votre équipe et votre portefeuille ? Cet article liste 10 bonnes raisons d’engager une démarche d’automatisation des tests.

Les 10 raisons d’automatiser ses tests

L’automatisation des tests est une pratique susceptible de décupler l’efficacité des tests, de multiples façons différentes. Si l’on reprend le document de référence de la certification d’automatisation des tests A4Q Selenium Tester Foundation, ainsi que l’édition 2020-2021 du World Quality Report, les avantages de l’automatisation des tests sont les suivants :

#1 – Réduction du temps nécessaire à l’exécution des tests

C’est le plus évident, et le plus impactant pour les structures où les compétences et la charge coûtent cher, avec des délais pas forcément en adéquation avec les ressources ! Certaines vérifications longues et répétitives qui seraient effectuées en quelques heures par un humain, peuvent l’être en quelques secondes par un robot.

Le World Quality Report, qui se base sur 1750 témoignages d’entreprises du monde entier, tous secteurs confondus, a démontré que 65 % des entreprises constataient un réel gain de temps grâce à l’automatisation des tests.

#2 – Réduction des erreurs humaines

Lors de la répétition des tests de régression notamment (vous savez, ceux qu’il faut jouer et rejouer à chaque fois pour s’assurer que les nouveaux développements n’ont pas cassé les anciens !), des erreurs peuvent être commises par des testeurs lassés ou distraits. On ne peut d’ailleurs pas leur jeter la pierre, des biais cognitifs puissants sont à l’œuvre, qui rendent très difficile de se concentrer sur des tâches répétitives ! Par chance, les scripts de tests automatisés répètent inlassablement et minutieusement les mêmes actions, avec un meilleur résultat : 57 % des organisations constatent une meilleure détection des défauts grâce à l’automatisation des tests (World Quality Report 2020-2021).

#3 – Réduction des coûts alloués aux tests

La réduction des coûts : cette raison fait partie des motivations récurrentes pour se lancer dans l’automatisation des tests ; selon le World Quality Report, ce bénéfice est constaté par 62 % des organisations.

Attention, cela ne signifie pas que le test dit « manuel » soit rendu caduc par l’automatisation des tests ; simplement, l’automatisation va aider à se concentrer sur les tests des nouvelles fonctionnalités, tester de manière plus ciblée et plus créative.

#4 – Augmentation de la confiance envers le produit

Une version testée automatiquement permet d’augmenter la confiance que nous portons au produit. Ce niveau de confiance évoluera au fil du temps : les premiers tests automatisés permettront en quelques minutes de confirmer qu’une version est testable ; un arsenal plus complet pourrait aller jusqu’à justifier un déploiement continu.

#5 – Exécution de tests impossibles à jouer manuellement

C’est le cas, par excellence, des tests de charge ou de performance. L’automatisation rend presque infinie les possibilités de scenarios de test, sans à avoir à se soucier de la charge humaine.

#6 – Gain de valeur pour les testeurs humain

Eh oui, l’époque où les machines domineront le monde est encore loin. Néanmoins, libérés d’une partie des tests de régressions, les testeurs peuvent exécuter des tests manuels plus intéressants et plus complexes. Ils peuvent par exemple s’adonner à des sessions de test exploratoire, qui permettent de quadriller l’application à tester de manière ciblée et intelligente.

#6 – Exécution des tests plus tôt

Grâce à l’automatisation, les tests peuvent être exécutés plus tôt dans le processus. C’est typiquement le cas quand les tests sont joués dans la chaîne d’intégration continue ; si on le souhaite, dès que de nouveaux « bouts de code » sont déployés, immédiatement des tests sont déclenchés. Cela répond à un des 7 principes généraux du test logiciel : « Tester tôt » !

#7 – Tester en-dehors des heures de travail !

Il est satisfaisant de commencer sa journée sachant que des tests ont « tourné » pendant la nuit et qu’il n’y a plus qu’à analyser leurs résultats. En outre, il peut être commode de libérer un environnement en journée, pour n’y effectuer de tests que lorsque personne ne travaille dessus.

#8 – Augmentation de la fréquence d’exécution des tests

Le temps imposé aux tests peut contraindre à laisser certains cas de côté quand les délais sont courts ; les tests automatisés permettent d’éviter ou raréfier ces raccourcis. Ils permettent même d’augmenter le périmètre de ce qui est testé (c’est ce qu’on appelle la couverture des tests).

Selon le World Quality Report, 58 % des organisations interrogées constatent que l’automatisation des tests leur a permis d’augmenter la couverture de leurs tests.

#9 – Transparence accrue des activités de test

Les tests automatisés produisent des rapports de test générés à la volée, qui sont souvent partagés automatiquement aux parties prenantes concernées. Le niveau d’information est alors le même pour tout le monde et cela contribue à créer un climat de confiance au sein de l’équipe. Ce gain est constaté par 69 % des organisations interrogées pour le World Quality Report.

#10 – Création d’une documentation vivante

Les tests automatisés ne se contentent pas de constituer un inestimable filet de sécurité ; ils représentent aussi, à un instant T, une documentation fine de la façon dont une application est censée fonctionner. Convenablement mis à jour et versionnés, les tests automatisés gardent ainsi la trace des différentes façons de fonctionner du système concerné. Un bénéfice inattendu, qui peut s’avérer bien utile !

L’automatisation des tests, une pratique désormais standard

La discipline a déjà derrière elle des dizaines d’années, puisqu’il existait déjà des outils d’automatisation des tests à la fin des années 1990. Astra Quicktest, l’ancêtre d’UFT, un des logiciel d’automatisation des tests les plus connus, a été créé en 1998.

A ce jour, selon le State of Testing de 2020, 89 % des entreprises ayant une démarche qualité logicielle pratiquent l’automatisation des tests.

Bien que les formations initiales en automatisation des tests soient rares, il existe des certifications qui permettent de standardiser les pratiques. La certification A4Q Selenium Tester Foundation, créée en 2018, en est un bon exemple, de même que les certifications ISTQB Analyste technique de test et Automatisation des tests.

L’automatisation des tests est donc aujourd’hui une pratique fortement implantée dans le paysage de l’IT, et on comprend pourquoi.

Comment initier l’automatisation des tests dans ma structure  ?

Si vous souhaitez vous lancer, de nombreuses ressources sont disponibles pour vous aider. Nous recommandons la lecture du syllabus A4Q Selenium évoqué plus haut, car ce document fournit une première vue d’ensemble des problématiques propres à l’automatisation des tests.

Prochainement sur notre blog, nous partagerons des bonnes pratiques pour mettre en œuvre l’automatisation des tests au sein de votre structure.

Et surtout n’oubliez pas, la question n’est pas de savoir si l’automatisation fournit réellement des avantages, mais plutôt de savoir quels sont les objectifs que vous souhaitez atteindre au sein de votre projet en utilisant l’automatisation des tests. Tous les bénéfices ne s’appliquent pas, ou du moins pas immédiatement, à tous les projet. C’est en les ciblant spécifiquement que vous multiplierez vos chances de les atteindre !

A bientôt !

Crédit image : Miguel Á. Padriñán

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 :

1. « Excusez-moi, puis-je utiliser la photocopieuse ? »
2. « 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 !

Autres articles sur les 7 principes généraux

• Les 7 principes généraux du test logiciel illustrés par la pandémie
• Les 7 principes généraux du test en illustrations médiévales