Les dérives de l’automatisation

Introduction

Nous l’avons vu dans un chapitre précédent, il y a plusieurs raisons pour lesquelles on peut vouloir automatiser.

Il est d’ailleurs primordial de toujours garder à l’esprit les raisons pour lesquelles on souhaite automatiser sous peine de dérives qui mènent l’automatisation à aller à l’encontre de son objectif initial. Cela est d’autant plus important qu’il est théoriquement possible d’automatiser au moins en partie toutes les activités de test !

Familles de dérives liées à l’automatisation

Le but de ce chapitre est de vous présenter 6 familles de dérives de l’automatisation très courantes afin de vous permettre de les éviter plus facilement. Ces familles sont :

• Vouloir trop automatiser

Cette famille de dérives est très fréquente. Elle peut être causée par divers facteurs. Ceux que j’ai rencontré le plus souvent sont l’excès de confiance suite à des succès initiaux et un changement drastique de contexte avec une diminution drastique des capacités de l’équipe en charge de l’activité d’automatisation.

Concrètement vouloir trop automatiser peut revenir à :

• Automatiser l’exécution de trop de tests

Cette erreur est une erreur très classique… et nous ramène au cœur même du métier de testeur : faire des choix.

Les tests exhaustifs, même automatisés, sont impossible. Automatiser, exécuter, analyser et maintenir des tests demande un investissement (en temps et en argent). Il ne faut pas laisser croire que l’automatisation de l’exécution des tests rend les tests « gratuits ».

Multiplier les tests c’est aussi multiplier les efforts et les coûts ! Hors, l’équipe en charge de l’automatisation a un temps et un budget limités. Les problématiques du test manuel restent avec l’automatisation. L’automatisation de l’exécution des tests scriptés permet simplement, si elle est bien faite, de gagner du temps et de l’argent sur l’exécution des campagnes.

Au final automatiser trop de test, c’est un dire un nombre trop important pour l’équipe, revient à aller contre les objectifs de l’automatisation :

• Une perte de temps : de par un investissement trop important dans l’écriture et la maintenance des tests
• Une perte d’argent : pour les mêmes raisons que la perte de temps
• Une baisse de la qualité : avec un manque de temps accordé aux autres activités de test ou une maintenance négligée
• Le développement de l’ennui : de certains testeurs étant amené à ne travailler que sur certaines tâches d’automatisation
• Une augmentation des erreurs : avec la multiplication des « flaky tests »

• Automatiser des tests trop complexes

Automatiser trop de tests n’est pas uniquement lié à un nombre. C’est aussi lié à la capacité de l’équipe à automatiser certains tests ou certaines activités. En effet l’intérêt d’automatiser un test n’est pas le même pour tous les tests et va dépendre en grande partie de la capacité technique à l’automatiser. Cette capacité technique peut être liée à l’outil de test, aux compétences de l’équipe ou tout simplement au test en lui-même demandant des actions ou un contexte bien particulier plus simple à faire à la main. Tout comme un nombre trop grand de test, automatiser des tests trop complexes nous mène à des situations ou les objectifs d’automatisation se sont plus atteints. En effet, automatiser des tests trop complexes revient à :

• Une perte de temps : sur la tâche d’automatisation du test en lui-même, sur sa maintenance, sur le temps d’analyse du test
• Une perte d’argent : lié à la perte de temps
• Un développement de l’ennui du testeur : étant amené à toujours travaillé sur les mêmes tests
• Une baisse de la qualité et une augmentation des erreurs: avec la multiplication des « flaky tests », tests dont les résultats sont peu fiables

• Automatiser des activités peu pertinentes

Cet aspect de l’automatisation est peut-être lié à la connaissance d’un outil qui offre des capacités d’automatisation de l’activité en question, à l’envie d’expérimenter ou plus simplement à des objectifs hiérarchiques peu pertinents par rapport au contexte de l’équipe.

Pour rappel, l’automatisation doit répondre à des objectifs précis comme le gain d’argent, de temps ou encore améliorer la qualité de travail des testeurs (éviter l’ennui). Le choix des activités d’automatisation se doit d’être fait en fonction de ces critères, des problématiques remontées ou anticipées par l’équipe. L’Agile propose un formidable outil pour repérer les points de douleurs, c’est les rétrospectives. Les rétrospectives permettent de mettre en place facilement l’amélioration continue en relevant des problèmes et en réfléchissant à des solutions pour les résoudre. L’automatisation n’est d’ailleurs qu’une solution parmi d’autres.

Au final, automatiser une activité qui n’a pas vocation à résoudre une problématique concrète de l’équipe cela revient à :

• Une perte de temps : avec l’investissement de l’équipe sur un sujet moins pertinent que d’autres
• Une perte d’argent : de par le manque de travail sur des problématiques vraiment gênantes pour l’équipe
• Une perte de sens lié à l’automatisation

Afin d’éviter les problématiques liées à « trop d’automatisation » il faut être capable de suivre et analyser les résultats de l’automatisation.

• Ne pas suivre et analyser les résultats de l’automatisation

Automatiser des activités c’est bien ! Savoir ce qu’apporte l’automatisation de ces activités c’est mieux. Nous n’automatisons pas juste pour le plaisir d’automatiser, nous automatisons pour répondre à des objectifs. Pour savoir si ces objectifs sont remplis ou si nous sommes dans la bonne direction pour remplir ces objectifs il est essentiel d’assurer un suivi de notre « projet d’automatisation », car oui, l’automatisation d’une activité c’est un projet à part entière.

Comme tout projet l’automatisation d’une activité nécessite un suivi : quel est l’avancement ? Sommes-nous dans les temps ? Respectons-nous les coûts ? Quels sont les résultats ?… Bref un bilan est nécessaire. Il est d’ailleurs intéressant de noter que ce bilan et suivi des actions prises est particulièrement mis en avant en Scrum avec les Rétrospectives mais aussi le rôle de Scrum Master qui est là pour assurer un suivi.

Concrètement, pour l’activité d’automatisation de l’exécution, une dérive trop fréquente est de multiplier les exécutions et de ne pas analyser les résultats des tests exécutés. Pour d’autres activités comme l’automatisation des bilans cela peut revenir à éditer automatiquement des bilans sans vérifier que les résultats remontés sont exacts. On peut également imaginer l’intégration d’outils pour générer les environnements et les données de test sans vérifier que ce qui est généré correspond à notre besoin.

Bref, ne pas suivre ni analyser les résultats liés à l’automatisation revient à être dans l’incapacité de savoir si nos actions sont pertinentes si l’automatisation répond à ses objectifs ou qu’elle sera en mesure d’y répondre un jour.

• Le manque de maintenance ou d’évolution

Ce point est particulièrement visible sur la tâche d’automatisation de l’exécution des tests scriptés. Il est d’ailleurs important de noter qu’il est souvent lié au fait que l’équipe a « trop de tests » à gérer.

L’automatisation de l’exécution des tests scriptés permet de réduire grandement (sans pour autant le rendre gratuit) le coût d’exécution des tests. Cependant il y a un coût « caché » qui est beaucoup plus élevé avec des tests automatisés qu’avec des tests manuels. Ce coût c’est le coût de maintenance. Même s’il existe des bonnes pratiques comme la factorisation des étapes de test, le coût de maintenance peut vite devenir très important… voire dépasser les capacités de l’équipe.

De même, par maintenance des tests il faut aussi penser à la maintenance de la campagne qui se fait en la faisant évoluer. On ajouter des tests, on en retire, on en modifie certains. Cet aspect trop souvent négligé répond pourtant à un des 7 principes du test : le paradoxe des pesticides. Pour éviter l’impact de ce dernier nous nous devons de modifier cette campagne.

Le manque de maintenance ou d’évolution est particulièrement impactant par rapport à l’objectif d’amélioration de la qualité :

• Le manque de maintenance des tests automatisés c’est la voie ouverte à des tests qui ne sont plus à jour et qui ne détectent plus rien.
• Le manque d’évolution de la campagne est la voie ouverte au paradoxe des pesticides et à une multiplication des tests non détectés

• Abandonner les activités manuelles

Les activités d’automatisation ne sont qu’un outil dans la main du testeur. Cet outil apporte de l’aide au testeur mais ne dispense pas de faire des tâches manuelles. En fait, les activités d’automatisées sont complémentaires des activités manuelles. J’oserai presque aller plus loin en disant que l’automatisation de certaines activités permet de faire plus de tâches manuelles à forte valeur ajoutées. La libération du temps apportée par l’automatisation peut en effet permettre de passer plus de temps sur l’amélioration continue, le test exploratoire, la conception des tests.

L’abandon des tâches manuelles revient à l’abandon de l’humain, du ressenti mais aussi à l’abandon de la capacité des testeurs à aller plus loin que ce qui est demandé et se rapprocher des utilisateurs. D’expérience, même en déploiement continu il reste des tâches manuelles à exécuter, dans mon cas c’était la multiplication des tests exploratoires et le suivi de la production. Au final l’abandon des activités manuelles va à l’encontre de plusieurs objectifs de l’automatisation avec:

• Une baisse significative de la qualité : avec une perte de l’humain, de son point de vue, de son ressenti
• Une perte d’argent : en automatisant trop
• Un sentiment d’ennui : avec un rôle de « presse bouton »
• Une perte de temps à moyen terme : à court terme on gagne beaucoup de temps mais la réalité nous rattrape ensuite avec de nombreuses anomalies non détectées à corriger ou des aspects du logiciel à reprendre

• Adopter de mauvais indicateurs

C’est une problématique récurrente dans le test mais plus généralement dans toutes les activités en entreprise : il faut être capable de suivre et d’analyser l’impact de nos actions. Pour cela nous bénéficions d’un outil très polyvalent que sont les indicateurs.

Les indicateurs permettent de mesurer des points spécifiques dans un contexte définis. Néanmoins, les indicateurs restent uniquement des outils de mesures. Seuls ils ne veulent rien dire, mal choisis ils peuvent mesurer des points non pertinents.

Prenons l’exemple d’un thermomètre. Cette outil propose un indicateur qui est la température et est souvent utilisé pour savoir si quelqu’un est malade. Néanmoins une température de 38,5° ne veut pas forcément dire que l’on est malade (on peut par exemple sortir d’un sauna) et une température de 37,5° ne veut pas forcément dire que nous sommes en bonne santé (ex : une température de 37,5° avec un cancer).

Les indicateurs doivent dont être choisis en fonction de ses objectifs et d’un contexte particulier. De même il est toujours préférable d’avoir un ensemble d’indicateurs que l’on analyse et éviter autant que possible des objectifs précis sur des indicateurs afin d’éviter de tomber dans les travers de la loi de Goodhart.

Pour l’automatisation je suis tombé sur un indicateur en particulier qui s’est avéré contre-productif, il était lié à un nombre de tests automatisés. Au final nous nous sommes retrouvé à automatiser des tests simples à automatiser mais peu pertinents. De même nous automatisions tous les tests d’une fonctionnalité avant de passer à une autre. Notre couverture de tests automatisés était alors catastrophique.

Comme on peut le voir sur l’exemple précédent le choix d’indicateurs non pertinents dans le contexte peut impacter négativement plusieurs objectifs de l’automatisation comme :

• Une perte de temps et d’argent : en ne concentrant pas ses efforts là où c’est le plus pertinent
• Une perte de qualité : avec la concentration des efforts au mauvais endroit et une mauvaise priorisation
• Le développement de l’ennui : avec une perte de sens pour le testeur

• L’excès de confiance

L’excès de confiance est, de manière générale, un piège à éviter pour le testeur qui doit faire une preuve constante d’un certain scepticisme professionnel. Il faut entendre par là qu’il faut continuellement tester, explorer, tenter d’aller plus loin sans faire une confiance aveugle à ce qui a été mis en place. Ce scepticisme est une arme du testeur afin de lutter contre les effets négatifs de certains principes comme le paradoxe des pesticides et l’illusion d’absence d’erreur… mais aussi un outil essentiel lors de l’automatisation de toute activité du test. En effet l’automatisation des activités fait perdre, au moins en partie, le contrôle humain. Il est alors fréquent de (trop) se reposer sur les résultats de cette automatisation. Le testeur ne doit pas faire une confiance aveugle aux personnes avec qui il travaille (on teste le code d’un développeur, on fait une revue des spécifications…) il doit encore moins accorder cette confiance à une machine qui donne des résultats. Il est d’ailleurs important de noter que cet excès de confiance se voit beaucoup avec des algorithmes d’intelligence artificielle (car on ne sait pas encore assez bien les tester ?) ce qui engendre des cas d’école d’échec des intelligences artificielles comme dans le système juridique américain.

Au final, l’excès de confiance est plus une cause des points précédents qu’une cause directe des tests en tant que tel. En effet cet excès de confiance peut mener à :

• Vouloir trop automatiser : en pensant que l’automatisation peut tout
• Le manque de suite des résultats : en laissant faire la machine
• Le manque de maintenance ou d’évolution : en pensant que ce qui est fait est parfait
• L’abandon des activités manuelles : en partant du principe qu’au final la machine fait tout au moins aussi bien que l’homme
• La sélection de mauvais indicateurs : en ne prenant pas le temps de bien les sélectionner

Conclusion

L’automatisation est un outil très puissant que l’on utilise instinctivement depuis l’enfance. Dans le cadre du test c’est également un outil formidable ! Néanmoins cette automatisation (de toute activité de test) reste un outil. Et, comme tout outil elle est efficace uniquement dans certaines situations et dans le cas où l’on sait comment s’en servir. Afin de bien utiliser l’automatisation des activités de test nous nous devons donc, de bien déterminer dans quels contextes cette dernière est intéressante à utiliser mais aussi veiller à bien s’en servir, notamment en évitant certaines dérives communes liées à son utilisation.

Vouloir automatiser les activités de test pertinente tout en connaissant les pièges les plus fréquents à utiliser permet de partir sur de bonne base dans cette activité d’automatisation. Cela ne reste que des bases, pour le reste, seule l’expérience et l’expérimentation permettra de continuer à s’améliorer et de maîtriser l’automatisation dans un contexte précis.

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.