Les raisons de l’échec de l’automatisation des tests: un coût trop élevé de l’automatisation ou vouloir tout automatiser.

par Marc Hage Chahine | 8 mars 2021

L’automatisation des tests peut échouer pour de nombreuses raisons. Nous allons aujourd’hui nous pencher sur une cause récurrente de ces échecs : une automatisation trop chère ou vouloir tout automatiser.

Un coût trop élevé de l’automatisation aboutit à un échec de l’automatisation

L’implémentation des tests automatisés est un investissement… Et comme tout investissement on en attend un retour. Ce retour sur investissement (dans le cas où l’on automatiser pour gagner de l’argent) doit donc être atteignable !

Il est d’ailleurs bon de noter que ce principe s’applique également au test en général. En effet, dépenser 50 000€ dans les tests pour une application qui ne pourra en rapporter que 40 000€ est une grave erreur. A ce prix-là (si seul le prix rentre en compte), il est préférable de ne pas sortir l’application !

Revenons à l’automatisation des tests. Le coût de l’automatisation peut être simplifié avec cette équation : CA = I + n*X où :

  • CA = Coût de l’automatisation
  • I = investissement (coûts des études préalables, des licences, des formations, de l’écriture des tests, mise en place des environnements…)
  • X = coût d’une campagne (exécution (souvent proche de 0), analyse, maintenance…)
  • n = nombre de campagnes

De même, le coût des tests manuels peut être simplifié avec une équation semblable : CM = I’ + n*X’ où :

  • CM = Coût des tests manuels
  • I’ = investissement tests manuels (écriture, conception…)
  • X’ = coût d’une campagne (exécution (souvent proche de 0), analyse, maintenance…)
  • n = nombre de campagnes

Le coût d’investissement pour l’automatisation est supérieur à celui pour les tests manuels. Afin d’assurer un retour sur investissement positif il faut, en plus d’avoir un investissement raisonnable, avoir un coût unitaire de campagne des tests automatisés inférieur à celui des tests manuels (dans le cas contraire les courbes ne se croiseront jamais) mais aussi avoir un nombre « n » suffisamment grand pour que les courbes se croisent.

On remarque donc ici que réussir un projet d’automatisation de test c’est savoir et identifier jusqu’où on peut aller en investissement mais aussi automatiser des tests qui seront ré-exécutés assez souvent pour devenir rentables. Vouloir automatiser tous les tests IHM s’avèrera dans une très grande majorité des cas un investissement très coûteux qui ne sera pas rentabilisé.

Comment assurer la rentabilité de l’automatisation des tests ?

Afin d’éviter ce problème de coût trop élevé il faut maintenir le coût d’investissement de ses tests automatisés à un niveau acceptable mais aussi automatiser les tests qui pourront être rentabilisés car suffisamment ré-exécutés. Pour assurer cette rentabilité l’équipe peut mettre en place certaines bonnes pratiques comme :

Automatiser les tests qui ont vocations à être ré-exécutés :

Le critère principal de rentabilité pour les tests automatisés est la faculté à pouvoir les ré-exécuter. En effet, actuellement le coût d’écriture d’un test automatisé reste généralement nettement supérieur à celui d’un test manuel. Afin de limiter le coût général des tests il est d’ailleurs également possible de limiter le coût des tests manuels qui ne seront pas ré-exécutés en ne les scriptant pas et en faisant du test exploratoire. On arrive alors à une stratégie de test où les tests de régressions sont automatisés et les tests de validation des fonctionnalités supplémentaires faits en exploratoire. Cela permet de stabiliser les nouveautés du logiciel et de se donner un peu plus de temps pour réaliser les tests automatisés sur ces nouveautés. Pour les équipes qui font de l’Agilité, on peut envisager de ne réaliser le test automatisé de non-régression que lorsqu’on a obtenu l’ensemble des développements d’une epic, et ne pas se situer au niveau de la user-story, dont la granularité est trop fine.

Architecturer ses tests de manière à limiter la maintenance.

Comme vu dans la première partie, un axe très important pour rentabiliser ses tests c’est le coût de chaque campagne. Ce dernier doit être aussi faible que possible afin d’atteindre le point de rentabilité le plus rapidement possible et ensuite faire le maximum de gain. Une part importante du coût des campagnes de tests automatisés est la maintenance des cas de test. Afin de limiter cette maintenance il est primordial de bien penser à l’architecture de son automate, de factoriser un maximum les étapes communes à plusieurs tests afin de ne devoir modifier qu’un seul script lorsque qu’une modification affecte plusieurs tests. Agilitest a bien sûr pensé à cette problématique c’est pourquoi il propose des « sous-script » qui peuvent être appelés par chaque test mais aussi paramétrés. On peut par exemple penser au test d’une page de formulaire avec 10 champs à remplir qui se transformerait en 1 seul sous script avec autant de paramètres et qui serait réutilisé dans 20+ tests.

Automatiser les tests dont le coût de l’automatisation est acceptable

Certains tests sont techniquement compliqués à automatiser. Cela peut être parce que l’outil peut difficilement ou pas du tout le faire (comme passer un captcha), qu’il est compliqué d’assurer un test stable et fiable, que le résultat est difficilement « quantifiable » et que l’on préfère un œil humain, que le parcours est complexe (comme par exemple l’accès à une machine sécurisée) ou pour toute autre raison. Dans ce cas le coût d’investissement pour écrire ce test peut s’avérer trop élevé pour pouvoir être rentabilisé et il est alors préférable (si c’est possible) de ne pas l’automatiser. Il suffit par la suite d’assumer un coût de « stabilisation » destiné à rejouer l’ensemble des tests manuels avant de permettre le déploiement de la version.

Limiter le coût d’analyse des tests automatisés

On est ici encore sur le coût unitaire d’une campagne. Comme nous l’avons vu dans un article précédent, il est primordial, pour la réussite de l’automatisation, d’analyser le résultat des tests. Cette analyse n’est pas gratuite et peut vite s’avérer très coûteuse si les bons outils ne sont pas mis en place. Un coût d’analyse trop élevé peut rendre le coût unitaire d’une campagne trop élevé pour espérer un retour sur investissement. Afin d’éviter cela il faut être capable de comprendre rapidement et simplement pourquoi un test est en échec et donc avoir à sa disposition des informations sur l’exécution permettant d’analyser le problème aussi vite que possible. L’équipe d’Agilitest est particulièrement consciente de cette problématique c’est pourquoi, il est possible d’avoir des screenshots pour chaque étape mais aussi des vidéos des tests exécutés. Voir ce qui s’est vraiment passé lors de l’échec d’un test est un vrai apport pour analyser cet échec lorsque l’on n’a pas assisté à l’exécution ce qui est généralement le cas avec les tests automatisés.

Conclusion

Avoir un projet de test rentable n’est pas toujours aisé. Il faut faire attention à plusieurs paramètres et savoir s’arrêter au bon moment sur ce que l’on souhaite automatiser. Ce point d’arrêt dépend de nombreux paramètres et du contexte, c’est pourquoi il est généralement préférable de faire une étude sur le périmètre à automatiser, d’élaborer une stratégie sur les tests à automatiser mais aussi établir un suivi tout au long de la vie de ces tests.