En-tête-canalplus

Comment éviter le manque de maintenance des tests ?

Marc Hage Chahine
Blog > L'automatisation des tests
Comment éviter le manque de maintenance des tests ?

L'automatisation des tests peut échouer pour de nombreuses raisons. Aujourd'hui, nous allons examiner l'une des principales causes de ces échecs : la maintenance.

Le manque de maintenance conduit à l'échec de l'automatisation

La mise en œuvre de tests automatisés est un investissement. Il est presque toujours plus coûteux d'automatiser des tests GUI que de les réaliser manuellement. Ce principe est bien intégré par toutes les équipes et leurs responsables. C'est dans ce contexte que beaucoup de temps est alloué à la mise en place de cette maintenance, qui vise à économiser du temps et de l'argent à moyen terme.

L'automatisation des tests réduit considérablement le coût de leur exécution car la présence humaine n'est plus nécessaire.

Cependant, un facteur est régulièrement oublié ; il s'agit de la maintenance des tests. En effet, la maintenance des tests manuels n'est pas très coûteuse en temps, et si 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 des tests automatisés ! La maintenance des tests automatisés est plus coûteuse que celle des tests manuels, car les tests doivent être modifiés, ou recréés, parce qu'ils sont généralement devenus du code.

Pour réduire cette charge de travail de maintenance, Agilitest vous permet de modifier les tests directement dans l'éditeur pendant leur exécution sans avoir à les rejouer ou à les réenregistrer complètement.

Nous pouvons résumer les différents coûts des tests avec cet exemple (notez que les coûts doivent être estimés et calculés pour chaque produit) :

Charge de travail des tests manuels et automatisés

En ce qui concerne Agilitest, la grande productivité du logiciel et la facilité d'exécution des opérations sur la maintenance permettent d'atteindre le point d'équivalence beaucoup plus rapidement.

Le site de maintenance des tests automatisés est particulièrement important, car s'ils ne sont pas à jour, ils ne peuvent pas atteindre leur objectif. L'accumulation de tests non maintenus conduit à une dette technique toujours plus importante.

Cela conduit à un cercle vicieux de tests qui sont soit abandonnés de la campagne, soit pire, des tests qui échouent toujours mais qui sont ignorés par l'équipe parce qu'ils ne sont pas à jour.

Ce comportement entraîne des lacunes dans la couverture qui se traduisent par des défaillances critiques ou majeures en production qui auraient été détectées par ces tests. Le projet d'automatisation des tests devient alors obsolète et est abandonné.

Comment éviter ce problème de maintenance ?

Afin d'éviter le problème de maintenance, vous devez évidemment maintenir vos tests. Malheureusement, la non-maintenance des tests, tout comme la dette technique d'une application, n'est pas quelque chose qui se fait de bon gré. C'est pourquoi l'équipe doit mettre en place certaines bonnes pratiques pour éviter ce problème :

Limiter le nombre de tests

Ce nombre doit être limité pour que la maintenance soit supportable par l'équipe : cela oblige à faire des choix et à retirer 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é. On peut obtenir une qualité logicielle infinie avec un nombre infini de tests, mais on ne pourra pas se le permettre.

Construisez vos tests afin de limiter leur maintenance

Les tests automatisés sont du code. En tant que tel, de bonnes pratiques de code doivent être utilisées. Comme vous le savez, les tests passent régulièrement par les mêmes écrans et effectuent des actions communes. Avec une mauvaise architecture, modifier une de ces actions vous oblige à mettre à jour tous les tests. Une bonne architecture permet, au contraire, de n'effectuer qu'une seule modification qui aura un impact sur tous les tests. Pour cela, il est nécessaire de créer des sous-scripts qui forment des briques, chaque test appelant une série de briques.

Agilitest répond évidemment à ce problème en facilitant la création de ces sous-scripts qui peuvent être appelés par d'autres scripts :

Appel d'un sous-script de connexion avec Agilitest
Test guidé par les données avec Agilitest en utilisant un fichier CSV

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 formulaires, d'avoir un seul script qui permet de faire tous les tests pendant le remplissage du formulaire, et d'itérer en masse en utilisant des fichiers de données CSV ou JSON.

Vous voulez essayer Agilitest ?

Découvrez Agilitest en action. Divisez par 5 le temps nécessaire à la sortie d'une nouvelle version.

Automatiser les tests fonctionnels pour des équipes heureuses.  

  • Des tests manuels aux tests automatisés
  • De l'automatisation des tests à l'automatisation intelligente des tests
  • Trouver les bons outils
ebook-scaling-test-automation-agilitest
Marc Hage Chahine

A propos de l'auteur

Marc Hage Chahine

Partenaire Agilitest - Passionné par les tests de logiciels chez Qestit - Certifié ISTQB (Foundation, Agile, Test Manager)

logo twitter
logo linkedin

Recevez les actualités du monde du test et d'Agilitest dans votre boîte mail

Rejoignez des milliers d'abonnés. Conforme RGPD et CCPA.