Automatisation des tests - les raisons de l'échec - 1. le manque de maintenance

Les raisons de l’échec de l’automatisation des tests: la maintenance

par Marc Hage Chahine | 17 février 2021

Agilitest fait équipe avec Marc Hage Chahine du blog La Taverne du Testeur pour explorer les raisons de l’échec de l’automatisation des tests: quelles sont-elles ? Comment les éviter? Et comment Agilitest peut vous permettre de surmonter ces obstacles et d’assurer une automatisation réussie? Bonne lecture!


L’automatisation des tests peut échouer pour de nombreuses raisons. Nous allons aujourd’hui nous pencher sur une des causes majeures de ces échecs, la maintenance.

Le manque de maintenance aboutit à l’échec de l’automatisation

L’implémentation des tests automatisés est un investissement. Cela coûte quasiment toujours plus cher d’automatiser des tests IHM que de faire ces tests manuellement. Ce principe est d’ailleurs bien intégré par l’ensemble des équipes et de leurs managers. C’est dans ce cadre que beaucoup de temps est alloué pour la mise en place de cette maintenance qui a pour but de faire gagner du temps et de l’argent à moyen terme.

L’automatisation des tests permet de diminuer fortement le coût d’exécution de ces derniers car une présence humaine n’est plus requise.

Néanmoins, un facteur est régulièrement oublié, c’est celui de la maintenance des tests. En effet, la maintenance des tests manuels est peu coûteuse en temps et dans le cas où les tests ne sont pas maintenus entre chaque campagne il est toujours possible de les maintenir pendant les exécutions manuelles. Ce n’est pas le cas avec les tests automatisés !

La maintenance des tests automatisés coûte plus cher que celle des tests manuels car il faut modifier les tests qui sont généralement devenus du code. Pour réduire cette charge de travail de maintenance, Agilitest permet de modifier directement les tests dans l’éditeur pendant leur exécution sans avoir à les rejouer ou réenregistrer complètement.

On peut résumer les différents coûts des tests avec cet exemple (attention les coûts sont à estimer et calculer pour chaque produit):

Charge de travail tests manuels vs tests automatisés

Concernant Agilitest, la grande productivité du logiciel et la facilité de réalisation des opérations de maintenance permet d’atteindre le point d’équivalence beaucoup plus rapidement.

La maintenance des tests automatisés est particulièrement importante car s’ils ne sont pas à jour ils ne peuvent répondre à leur objectif. L’accumulation des tests non maintenus engendre une dette technique de plus en plus importante ce qui mène à un effet boule de neige.

Le cercle vicieux s’enclenche alors avec des tests qui sont soit sortis de la campagne ou pire, soit des tests qui sont toujours en échec mais qui sont ignorés par l’équipe car pas à jour. Ce comportement mène à des failles dans la couverture ce qui engendre des défaillances critiques ou majeures en production qui auraient été détectées par ces tests. Le projet d’automatisation de test se retrouve alors obsolète et abandonné.

Comment éviter ce problème de maintenance ?

Afin d’éviter le problème de maintenance il faut évidemment maintenir ses tests. Malheureusement, la non maintenance des tests, tout comme la dette technique d’une application ne se fait pas de gaieté de cœur. C’est pourquoi l’équipe doit mettre en place certaines bonnes pratiques pour éviter ce problème :

Limiter le nombre de tests :

Il faut limiter ce nombre afin que la maintenance soit soutenable par l’équipe : cela force à faire des choix et à supprimer des tests des campagnes mais cette décision sera toujours connue et les tests non exécutés seront choisis en fonction de leur utilité. Vous pouvez obtenir une qualité logicielle infinie

Architecturer les tests afin de limiter leur maintenance.

Les tests automatisés sont du code. A ce titre il faut utiliser les bonnes pratiques du code. Comme vous le savez les tests passent régulièrement par les mêmes écrans et effectuent des actions communes. Avec une mauvaise architecture, la modification d’une de ces actions force à mettre à jour tous les tests. Une bonne architecture permet, au contraire, de ne faire qu’une seule modification qui impactera tous les tests. Pour cela il faut créer des « sous-tests » qui forment des briques, chaque test appelant une série de briques.

Le produit Agilitest répond évidemment à cette problématique en permettant facilement de créer ces sous-scripts qui peuvent être appelés par d’autres scripts :

Appel de sous-script en variabilisant les paramètres de connexion
Appel d’un sous-script pour variabilisé en masse le renseignement d’un formulaire

De plus chaque script (et donc sous-script) peut être variabilisé. Cela permet de centraliser encore plus d’actions et même dans certains cas comme les tests de formulaire d’avoir un unique script qui permet de faire l’ensemble des tests lors de la complétion du formulaire, et d’itérer en masse en utilisant des fichiers de données.