Automatisation: Architecture modulaire, la clé pour limiter la maintenance ?

Les problèmes de maintenance sont récurrents avec les tests automatisés. C’est même une des raisons majeures de l’échec de l’automatisation des tests.

La maintenance doit être effectuée à chaque changement applicatif impactant un ou plusieurs cas de tests.  Cette maintenance, si elle est mal gérée peut très vite devenir très gourmande en temps dès lors où l’on multiplie les cas de test.

Comment limiter cette maintenance ?

Revenons à la base et prenons une application simple. Comment peut-on implémenter les tests ci-dessous et quel sera l’impact de ce choix sur la maintenance ?

Test 1 :

Test 2 :

Test 3 :

On peut implémenter ces tests de 2 façons.

·        Solution 1 : Solution généralement utilisée, chaque test est développé indépendamment. Les étapes sont directement écrites au sein du test, certaines parties étant fréquemment répétées. De plus, si l’affichage du mail est modifié, il faut alors maintenir les 3 tests précédents, en faisant, pour ces 3 tests les mêmes modifications.

·        Solution 2 : Solution par module. On parle alors d’architecture modulaire. Dans ce cas les tests « appellent » les modules. La mise à jour d’un module entraine la mise à jour de l’ensemble des tests faisant appel à ce module. Si l’affichage du mail est modifié il faut alors pour maintenir ces cas, une seule modification sur le module approprié. Il faut par contre travailler en amont sur l’architecture de l’automate.

L’architecture modulaire serait-elle une solution pour limiter efficacement la maintenance ?

Tout d’abord : qu’est-ce qu’un module ?

On peut par exemple faire 1 module par écran (même s’il existe différentes manières de procéder et niveaux de modularité). Dans le cas de mes tests en exemple on aurait alors 4 modules (car 4 écrans parcourus par les tests):

·        Le module ou écran « Téléphone » : pour ouvrir l’application => Module 1

·        Le module ou écran « Liste des mails » : pour toute vérification ou action sur cet écran => Module 2

·        Le module ou écran « Affichage Mail » : pour toute vérification ou action sur un mail affiché => Module 3

·        Le module ou écran « Composeur » : pour toute vérification ou action sur l’écran pour écrire un mail => Module 4

A noter : ces modules pourront être utilisés pour tout nouveau test développé.

Un Module peut être considéré comme une fonction avec plusieurs variables. Prenons le Module 2 : La liste des mails.

Ce Module peut avoir comme entrée des variables de vérifications et d’actions :

·        Exemple de variable: présence de bouton, d’un mail (en fait vérifier la présence d’un objet avec un ID) ou simplement vérifier l’affichage de cet écran (Vérification nom de la page)

·        Une action : un clic

Ici, pour simplifier on pourrait avoir l’appel au comme suit : Module_1(A,B,C) où A vérifie la présence d’un ID, B compare le nom de la page à la page attendue et C clique sur l’ID voulu. Ces 3 variables pouvant être vide si on ne veut pas d’action (ex : Module_1(12, ,13), voudrait dire que l’on vérifie la présence de l’ID 12 et que l’on clique sur l’ID 13).

Tout cela doit être pensé et développé en amont. Dès lors où ce module est développé, il est alors possible de l’utiliser pour l’ensemble des tests.

Maintenant que nous avons les modules, comment les articule-t-on pour avoir une architecture modulaire ?

Reprenons le test 2 (le seul qui passe par les 4 modules). Avec une architecture modulaire cela pourrai donner cela :

Pour chaque étape, on a bien 1 Action => 1 Résultat.

Ici, on appelle les modules en donnant les variables que l’on souhaite (cliquer sur un ID, vérifier la présence de boutons, les valeurs de champs…).

Pour résumé, les 3 cas de tests définis initialement peuvent ressembler à cela avec une architecture modulaire :

Avec pour chaque appel de module, l’action ou la vérification souhaitée. Vous remarquerez, qu’à l’exception des variables, les tests 1 et 3 sont identiques, la différence se fait donc avec uniquement les variables utilisées lors de l’appel.

Enfin, au niveau maintenance, si le module 2 est affecté, il suffit alors de mettre à jour ce module pour mettre à jour les 3 tests et potentiellement 8 occurrences dans l’ensemble des 3 tests.

Conclusion :

Les automates à architecture modulaire sont une autre façon de penser l’écriture des cas de tests automatisés. Cela demande de la réflexion en amont et une bonne organisation. Par contre, lorsque les modules sont développés, les coûts de maintenance deviennent dérisoires par rapport à une architecture plus classique. De plus la multiplication des tests n’engendre plus une multiplication des coûts de maintenance. Si 2 modules sont affectés, il suffit de mettre à jour ces 2 modules. La maintenance sera la même qu’il y ait 5 ou 500 tests affectés.

J’aimerai finir en faisant une petite digression sur l’histoire des tests automatisés. Initialement les tests automatisés étaient un enregistrement d’action. A chaque modification d’une seule étape, il fallait jeter le cas de test et tout refaire. S’en est suivi un développement des tests de façon à ne pas avoir à les jeter au moindre changement afin de réduire les coûts de maintenance. L’architecture modulaire est simplement la suite logique dans l’évolution de l’automatisation et la diminution de la maintenance.

Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles