Les bonnes et mauvaises pratiques de l’automatisation

15 septembre 2022

Par Jean-François Fresi

Cet article est une mise à jour du chapitre II.1 – Pour une stratégie d’automatisation des tests du livre Automatisation des activités de test de du CFTL que j’ai rédigé en 2021.

L’automatisation joue un rôle essentiel dans le développement d’une application mobile ou d’un logiciel. Il est important de comprendre les bonnes démarches d’automatisation à adopter pour éviter les mauvaises pratiques. Dans cet articles découvrez les mauvaises pratiques à éviter et tous nos conseils pour y remédier.

Mauvaise pratique n°1 – Vouloir tout automatiser

Une des croyances sur l’automatisation est de penser que tout est automatisable et qu’il faut tout automatiser. Cette pratique risque de générer un manque de fiabilité dans le temps et un coût de maintenance très élevé et va engendrer une perte de confiance dans le temps sur la fiabilité des tests automatisés.

Cette approche est souvent liée au doux rêve de ne plus avoir besoin de tester manuellement. Dans la plupart des cas, c’est objectif (trop ?) ambitieux passe en général par une approche shift left, TDD, clean et architecture logicielle plus proche du microservice que du monolithique qui dépend de plusieurs SI.

Il faut choisir ses combats et cibler les tests et les parcours de tests à automatiser en s’appuyant sur la modélisation. L’utilisation de la matrice des risques et de couverture pour prioriser les cas de tests est aussi à envisager afin de créer de la valeur le plus rapidement possible . Dis autrement, il faut définir une stratégie et des objectifs car vouloir tout automatiser sans analyse est voué à l’échec.

Mauvaise pratique n°2 – Automatiser comme pour le test manuel

Une autre croyance est de vouloir automatiser de la même façon que les tests manuels, avec de longs tests fonctionnels et énormément de contrôles sur chaque étape de tests. Une des conséquences de cette croyance est une maintenance dans le temps très difficile et un abandon systématique des tests automatisés.

Créer des cas de tests sur une fonctionnalité avec un minimum d’objectifs de validation, ou sur le comportement d’un parcours utilisateur avec les contrôles minimums suffisants pour valider le cas de test. Automatiser, c’est automatiser un comportement et pas tous les détails de l’application. L’objectif est bien de valider que le cas d’usage qui crée la valeur attendue en automatisant le comportement. Il ne faut pas chercher avec l’automatisation et identifier toutes les anomalies possibles.

Mauvaise pratique n°3 – Tout tester avec l’IHM

En tant que testeur, la vision bout en bout en partant de l’IHM peut laisser croire que l’automatisation doit principalement se faire avec l’IHM. Or, dans bien des contextes projets, cela implique des cas de tests trop complexes à automatiser ou lorsque cela est envisageable, une complexité et une instabilité des scripts de tests du fait des évolutions régulières des écrans et de l’ajout de nouvelles pages. De plus, automatiser uniquement au niveau de l’IHM implique une validation avec toutes les couches de l’application et de fait, une complexité trop importante.

Dans ce cas de figure, se concentrer si possible sur des cas de tests d’API avec une approche de tests automatisés plus bas niveau, en s’inspirant de la pyramide des tests et inclure un minimum de tests d’IHM automatisés uniquement sur les cas critiques, dans la mesure du possible. L’approche optimale était de faire un maximum de tests unitaires pendant la phase de développement et de tests d’intégration au préalable.

Mauvaise pratique n°4 – L’automatisation, un projet à part

Afin d’accélérer l’automatisation, l’idée serait de monter un projet autonome « Automatisation de tests » en parallèle de l’équipe concernée, afin d’avoir une meilleure transformation. Dans ce cas de figure, deux risques émergent : le premier est d’obtenir des cas de tests automatisés très techniques qui ne sont pas en phase avec la valeur métier, et difficilement compréhensibles et maintenables par l’équipe de test une fois le projet “test auto”“ achevé et transmis à l’équipe de test. Le second risque est une production trop importante de tests automatisés, notamment sur le bout en bout (cf #1) et qui pourraient être décorrélés de l’apport de valeur développée car les deux équipes étant sur 2 projets parallèles, ne se synchronisent pas suffisamment.

La stratégie des tests automatisés doit être incluse dans la stratégie de test. Elle doit guider le développement de tests automatisés. En se basant sur la démarche décrite précédemment, le test automatisé doit s’intégrer pleinement dans une stratégie de test globale et portée par tous les acteurs du projet.

Mauvaise pratique n°5 – Automatiser les parcours IHM d’une application en construction

Vouloir automatiser dès le début du projet est une bonne approche, cependant, inclure les tests d’IHM dès le début alors que le workflow ni les pages ne sont à minimum stables implique de redévelopper les scripts d’automatisation des tests à la même fréquence que les changements de code dans l’IHM. Cela implique un coût et une énergie importante pour l’équipe en apportant peu de valeur ajoutée et de confiance dans la qualité du produit.

Un autre cas similaire est dans le cas d’une refonte profonde du Front avec ou sans changement de technologies.

Ses changements ne veulent pas dire ne pas automatiser les tests mais plutôt adapter sa démarche en se concentrant que sur quelques cas nominaux à automatiser sur l’IHM et en se concentrant sur l’automatisation des tests d’APIs.

Mauvaise pratique n°6 – Tout le monde peut automatiser

Les solutions d’automatisation de test permettent aujourd’hui de rendre l’automatisation accessible au plus grand nombre et donc à des profils non technologiques avec des solutions codeless, de record/replay et d’utilisation de l’IA.

Même si ces briques technologiques permettent de créer rapidement des scripts automatisés, le risque sous-jacent est la maintenance et la gestion de cas un peu plus complexes à gérer.

Même si ces outils facilitent notre travail, il faut avoir conscience que nous produisons du code et la technologie associée nécessite de maîtriser des concepts et des bonnes pratiques technologiques pour garantir une maintenabilité dans le temps et intégrer les scripts dans des chaînes d’intégration continue. Au fil du temps, la maintenance non maîtrisée implique un surcoût de re-développement des scripts.

On peut être amené alors à se dire, si c’est si technique, je n’ai pas besoin de testeurs car les développeurs peuvent automatiser les scripts …

Techniquement, en effet c’est le cas, mais cette approche n’est valable que si les équipes de développement ont une forte culture de la qualité et sont formées aux tests logiciels.

Il est indispensable de former techniquement et méthodologiquement les automaticiens, quels que soient leurs profils. Il est aussi important d’avoir choisi un outil qui est en phase avec le profil cible des automaticiens que j’ai défini dans mes objectifs. Par exemple, si j’envisage de pouvoir automatiser une partie de mes parcours par mes testeurs fonctionnels expérimentés qui n’ont pas ou peu de compétences en développement, il faut choisir des outils prenant en compte cette contrainte, tout en les accompagnant avec des profils techniques en support qui leur faciliteront leur quotidien.

Mauvaise pratique n°7 – Miser sur l’outillage uniquement

Trop souvent, la première question posée dans le cadre d’une mise en place d’une démarche d’automatisation est “quel est le meilleur outil d’automatisation ?”

Or, il n’y a pas de réponse unique à cette question, cela va dépendre de plusieurs facteurs comme le type d’application à tester, le type de contrôles, les types de test à automatiser, la culture de l’entreprise, la cible des automaticiens envisagés …

Partir de cette question et essayer d’y répondre rapidement implique le risque de tomber dans l’effet de mode dans le choix de l’outil : J’entends beaucoup parler de l’outil XXX et je connais quelqu’un qui m’a dit que c’est le meilleur outil …. Tomber dans cette facilité nous expose à un choix qui n’est pas rationnel ni étayé et analysé sur les besoins du projet. De plus, l’effet de mode à un effet de bord: qui dit nouveauté, dit compétences rares à trouver !

L’outil d’automatisation est un choix très important. Pour le choisir, il faut donc savoir quelles problématiques nous voulons résoudre et quels sont nos objectifs associés à notre stratégie d’automatisation des tests.

Mauvaise pratique n°8 – Ne pas vérifier l’apport de l’automatisation

“Vous ne pouvez pas piloter ce que vous ne pouvez pas mesurer”, cette citation de Peter Drucker, qui est le théoricien du management moderne, prend tout son sens ici. Ne pas mesurer et évaluer le coût et donc, le ROI de l’automatisation des tests n’est pas une approche de pilotage moderne de projet. L’évaluation trop tardive, une fois qu’on ne voit pas les gains arrivés est déjà trop tard et dû au fait qu’aucun indicateur n’a été anticipé ou pas les plus adaptés comme le pourcentage de cas de test automatisés par rapport au nombre de cas de test.

Dans ce genre de situation, le budget d’automatisation peut vite partir en fumée et il faudra un certain moment, avant, de nouveau avoir la confiance du management pour relancer un chantier d’automatisation.

Il est indispensable de définir les KPIs dès le lancement de la démarche d’automatisation et de prévoir à intervalle régulier une évaluation ROI de l’automatisation. Il faut, certes, avoir beaucoup d’ambition mais il faut commencer par un périmètre réduit qui permet de gagner en confiance et en crédibilité avant de déployer cette stratégie de façon plus importante. Il est donc indispensable d’avoir une compréhension claire des buts et objectifs d’un tel projet avec les risques qui y sont associés.

Mais alors dans quels cas automatiser ?

L’automatisation doit répondre à une stratégie visant à maximiser et optimiser son ROI. Il y a des exceptions à tout, bien sûr, mais en général, tous les tests ne sont pas automatisables, en voici quelques exemples :

Test unique ou très peu fréquent
Test dont les résultats ne sont pas prévisibles
Test d’utilisabilité
Valeur ajoutée / impact faible
Instabilité du composant à tester
Test très (trop) complexe

À retenir : lorsque vous automatisez, automatisez les bonnes choses, avec les bons outils et de manière intelligente ; sinon, les tests automatisés peuvent prendre plus de temps que les tests manuels.

L’automatisation n’est pas une solution miracle qui peut résoudre tous vos problèmes de test. C’est un outil, et comme tout autre outil, il doit être utilisé intelligemment. L’automatisation des tests doit être appliquée aux domaines appropriés de votre application et avec les bons outils pour le travail. Vous devez vous assurer que vous automatisez de manière répétitive, mesurable, durable dans le temps et construite de manière intelligente afin que les mises à jour ou les changements n’interrompent pas les tests existants.

Trop souvent, les projets se lancent pleinement dans l’automatisation de leurs tests fonctionnels sans même avoir réalisé au préalable une stratégie de tests fonctionnels automatisés et sans prioriser les actions et identifier les cas de tests qui vont leur apporter le plus de valeur. En pensant gagner du temps, les équipes projet en perdent finalement beaucoup en devant régler une à une des problématiques qui auraient pu être évitées. Le management visuel, notamment la modélisation des parcours métier, est un outil puissant et efficace qui permet d’apporter une bonne compréhension du projet à l’ensemble des acteurs, mais aussi une bonne visibilité sur les modifications et les évolutions du projet et les impacts qui en découlent. Cela permet donc d’adapter sa stratégie de test, de prendre les bonnes décisions de manière collaborative et d’affiner les tests à automatiser, à conserver, maintenir ou mettre de côté. Cela facilite grandement la maintenabilité du référentiel de tests automatisés ou non.

Téléchargez gratuitement notre infographie

Les 4 mauvaises pratiques d'automatisations