Estimer la pertinence d’automatiser un test – Brice Roselier

L’automatisation d’un test est souvent vu comme la solution à tous les problèmes du testeur.

D’autres l’ont dit avant moi, un test automatisé n’est pas un simple programme qui prend 5 minutes à être analysé, conçu et implémenté et qui, une fois en place, tourne tout seul dans son coin. Non, la mise en œuvre d’un test automatisé nécessite plus de temps qu’un test manuel et cela varie selon la complexité du contexte.

Les résultats d’exécution d’un test automatisé devront être analysés. Lorsque le test échoue, il faut en comprendre la raison et envisager une action (correction ou maintenance). Il peut s’agir d’un faux positif dû par exemple à une anomalie sur l’environnement de test. Un test étant toujours en succès peut cacher un faux négatif.

Par ailleurs, sur la durée, un test automatisé doit être revu. On peut par exemple modifier les jeux de données afin de limiter les effets du paradoxe du pesticide. Enfin, en cas d’évolution de l’article de test, le test automatisé doit être mis à jour.

Pour estimer la pertinence d’automatiser un test, le calcul du ROI est une bonne approche. Toutefois, avant de vous lancer dans une étude poussée, la réponse à quelques questions simples peut suffire pour décider si l’automatisation du test est pertinente ou non.

Nous allons voir dans cet article quelles sont les questions à se poser lorsque l’on souhaite automatiser et surtout comment y répondre. L’article n’a pas la prétention de donner une réponse à tous les cas, et certaines de ces questions peuvent avoir des réponses très complexes. Toutefois elle peut donner une réponse rapidement dans votre cas.

Votre test est-il automatisable ?

Cette question peut paraitre évidente, mais avant de vous lancer dans quoi que ce soit, vous devez vous assurer que votre test peut être automatisé. Tout n’est pas automatisable même si le budget alloué aux tests automatisés est conséquent. Par exemple l’authentification à reconnaissance faciale au niveau intégration de systèmes (c’est-à-dire avec une réelle acquisition d’image et non avec un bouchon) ne se teste que si une personne est réellement présente.

Si la réponse est NON, votre test ne doit pas être automatisé.

Votre test est de niveau unitaire ou un test boite blanche ?

Selon l’ISTQB, le niveau unitaire consiste à tester isolément les éléments logiciels minimaux et individuels. Il est donc nécessaire d’avoir accès au code source du logiciel, et de vérifier les valeurs de retour ou le contenu des variables. Cela peut être fait manuellement à l’aide d’un debugger, mais la répétitivité et la fastidiosité de ces tests font que leur automatisation sera très rentable.

Si la réponse est OUI, votre test doit être automatisé.

Votre objet de test est-il une API ou Webservice ?

Les API et webservices sont des micro-applications dont le résultat est généralement une trame de données (un flux json ou xml par exemple). Pour les tester il faut donc analyser le contenu de ces trames. Pour les mêmes raisons que le niveau unitaire, l’automatisation de ces tests réduira le risque d’erreur et dégagera du temps pour d’autre tests à plus forte valeur ajoutée.

Si la réponse est OUI, votre test doit être automatisé.

Le composant est-il critique ?

Une anomalie présente dans un composant expose toujours le système à un comportement non désiré. Ce comportement peut être plus ou moins impactant pour l’utilisateur selon le composant défaillant. Il est question de définir le niveau de risque en cas d’anomalie dans ledit composant. Plus le risque est élevé, plus l’effort de test pour ce composant sera important. Il est alors intéressant d’en automatiser les tests afin de les exécuter souvent, sans monopoliser le testeur, et de réduire le risque de régression. Il est par exemple nécessaire de consolider le socle technique du système.

Si la réponse est OUI, votre test doit être automatisé.

Quel est le budget alloué aux tests automatisé ?

Cette question marque un tournant dans cet article. En fonction de la réponse, d’autres questions se poseront ou pas. Selon le projet, sa gestion et la criticité de l’application, le budget alloué aux tests diffère.

Si votre budget est faible :

Dans cette partie de l’article considérez que le budget alloué aux test est faible. On parlera qu’il est inférieur ou égal à un tiers du budget alloué aux développements.

Le test est-il un test de régression ?

La régression d’un système est la mise en évidence d’une défaillance avérée lorsque celle-ci ne l’était pas dans le passé. Un test de régression est un test exécuté après une modification et cherchant à mettre en évidence une anomalie introduite lors de cette modification. Automatiser un tel type de test est conseillé du fait de sa répétitivité.

Si la réponse est OUI, votre test doit être automatisé.

Le test est-il un test fumigatoire ?

L’ISTQB définit un test fumigatoire comme faisant partie d’un sous-ensemble de tous les cas de tests conçus ou prévus et qui couvrent les fonctionnalités principales d’un composant ou d’un système. Cela permet de vérifier que les fonctions les plus cruciales continuent de fonctionner.

Si la réponse est OUI, votre test doit être automatisé, sinon il ne doit pas.

Si votre budget est moyen ou élevé :

Pour la suite de cet article considérez que le budget alloué aux test est moyen ou élevé. On parlera qu’il est supérieur à un tiers du budget alloué aux développements.

Le test est-il un test fumigatoire ?

Ce type de test est expliqué plus haut dans cet article.

Si la réponse est OUI, votre test doit être automatisé.

Quelle est la durée de vie du système à tester ?

Il est plus évident d’investir dans l’automatisation d’un test si le système va perdurer dans le temps. Si votre système est réalisé pour un besoin ponctuel, par exemple un évènement, et qu’ensuite, le projet est abandonné, il est moins intéressant d’investir dans l’automatisation du test.

Pour cette question on mettra un seuil à 3 ans.

Si le système va disparaitre avant 3 ans, il faut se poser la question de l’effort d’automatisation. Si l’automatisation du test demande un effort important (et que votre application aura disparu dans 3 ans), votre test ne doit pas être automatisé.

Si l’effort n’est pas important, votre test devrait être automatisé.

On admet dans la suite des questions que l’application va continuer à être utilisée plus de 3 ans.

L’article de test est-il fortement sollicité ?

En principe, tous les composants d’un système ont leurs rôles et intérêts. Toutefois, certains composants sont plus sollicités que d’autres à la fois dans la conception (fonction appelée plusieurs fois dans le code) qu’à l’exécution (fonction souvent exécutée même si peu appelée dans le code).

Si l’article de test fait partie des composants les plus sollicités, votre test doit être automatisé.

Le test est-il chronophage ?

Le temps nécessaire pour tester l’article de test comprend à la fois la préparation (par exemple le rassemblement des prérequis) et son exécution. Dans certains cas, cette préparation peut être longue et difficile à réaliser. Selon la complexité du système le testeur doit peupler sa base de données de façon conséquente et d’une façon particulière, l’application doit être paramétrée conformément à la condition de test. Etc.

Si la réponse est OUI, votre test doit être automatisé.

Le test est-il souvent exécuté ?

Dans la lignée de la question précédente, un test souvent exécuté, à l’instar des tests de régression, devrait être automatisé. En effet, plus un test est souvent exécuté, plus il est chronophage dans la durée. Par ailleurs, le testeur étant un être humain, va se lasser à force de répéter les mêmes actions. Cela augmente également le risque d’erreur et la valeur ajoutée du testeur peut poser question.

Si la réponse est OUI, votre test doit être automatisé.

Le test est-il répétitif ?

En fonction du scénario exécuté, les actions à réaliser peuvent être répétitives et comme pour la question précédente, avoir un effet lassant pour le testeur. Si le test en question présente des mêmes actions qui reviennent plusieurs fois, la question de l’automatisation mérite d’être posée.

Si la réponse est OUI, votre test doit être automatisé.

L’article de test va-t-il évoluer à l’avenir ?

Pour cette dernière question, attardez-vous à l’évolution de votre système testé. On va considérer qu’il est stable (pas de défaut remonté par les utilisateurs) et donc aucune évolution ni correction ne sont prévu à moyen terme. On m’a récemment posé la question s’il fallait automatiser des tests (voire ajouter de nouveaux tests) sur un système qui est stable et n’évolue plus. Ma réponse a été négative. Le fait que le logiciel (appelé legacy) n’évolue plus représente un risque trop faible de régression pour y consacrer une charge de test. Nous serions dans de la sur-qualité. Cela n’empêche pas de tester son utilisation à partir d’autres systèmes, mais dans ce cas, ce n’est plus l’article de test en question qui est testé.

Le jour ou un nouveau défaut est détecté dans l’article de test, une correction sera probablement envisagée. La réponse à cette question ne sera plus la même et celle concernant l’automatisation du test également.

SI la réponse à cette question est NON votre test ne doit pas être automatisé sinon il devrait l’être.

Conclusion

Cet article dresse une liste de questions non exhaustive qu’il est intéressant de se poser avant de s’engager dans une étude lourde quant à l’intérêt d’automatiser ses tests manuels. Bien certaines réponses se basant sur un seuil, propose les mêmes conclusions l’on soit à la limite ou largement supérieure, cela donne une orientation à la stratégie d’automatisation. En cas de doute, il vous reste toujours la possibilité de mener votre étude de ROI.

De façon schématique voici un diagramme d’aide à la décision :

A propos de l’auteur: Brice Roselier

Depuis plus de 7 ans, je suis impliqué dans le testing et l’assurance qualité logicielle. J’aime à la fois résoudre les problématiques en lien avec l’automatisation, mais aussi structurer (professionnalisation) et piloter (planification, suivi et contrôle) les activités de test.