Automatiser simplement ses tests fonctionnels avec Microsoft Excel

L’automatisation des tests fonctionnels est un sujet complexe, demande des exigences et au moins deux compétences majeures doivent être réunies pour réussir : La compétence métier et applicative pour formaliser les tests qui ont de la « valeur » et la compétence technique proche du code pour « coder » l’exécution des actions (click sur un bouton dans un navigateur via un ID ou un xpath par exemple). Donc, soit c’est un développeur qui écrit les tests, mais il n’est pas le meilleur expert métier, soit c’est un testeur fonctionnel, mais il est limité par la complexité de l’implémentation. Soit les deux compétences travaillent ensemble… mais pour cela il faut s’appuyer sur des outils conçus pour séparer les usages tout en les gardant intrinsèquement liés dans la mise en place.

L’approche BDD est conçue dans cette optique, mais elle reste très proche du code avec un formalisme contraint (Gherkin) et une implémentation très souvent liée à Cucumber.

Pour ceux qui préfèrent une alternative et souhaitent écrire des tests encore plus simplement avec Excel, CloudNetCare propose une approche et une méthode particulière pour votre entreprise dans l’intégration des cycles de vies des tests, méthode très utile notamment dans la création de tests de non-régression.

La séparation des concepts de l’automatisation des tests fonctionnels

Comme nous venons de le décrire, deux compétences distinctes de votre environnement sont nécessaires pour réussir le développement de l’automatisation des tests fonctionnels. Rares sont les personnes pouvant prétendre à une expertise double même si elles seront optimales pour la réussite d’un projet d’automatisation. Mais alors attention au syndrome du « guru » incontournable…

Si l’on souhaite pérenniser l’automatisation dans le temps, il vaut mieux séparer les concepts et les simplifier au maximum. Pour l’implémentation de l’automatisation nous allons avoir une approche « scriptée », sans écriture de code pour une maintenance simplifiée et pour la conception métier nous choisirons un simple fichier Excel.

L’écriture des tests fonctionnels avec Excel

Comme nous l’avons décrit plus haut, CloudNetCare permet de séparer la logique de test de l’implémentation grâce à des outils. Le lien entre les deux est fait par l’utilisation de « variables » dans le fichier Excel qui seront ensuite utilisées dans l’implémentation de l’automatisation que nous étudierons plus tard. Concentrons d’abord nous sur la logique de test et voici un exemple de test écrit avec Excel :

Voici un exemple de projet utilisant notre modèle. Nous souhaitons tester un logiciel qui est un application Web qui génère des factures avec plusieurs niveaux d’habilitation. L’objectif est de vérifier le scénario suivant : c’est dire que chaque profil utilisateur a bien le niveau d’habilitation souhaité (Ex : Seuls les administrateurs auront accès à un menu « BackOffice ») et que la facture générée par l’application est conforme aux règles métier (Ex : Un administrateur a un taux de TVA de 0%, les autres 20%)

Voilà notre exemple avec l’outil Excel que l’on pourrait écrire dans ce fichier :

La première colonne comprend certaines données : celle des noms des variables, on retrouve ici les identifiants de connexion (login/password), des variables d’assertion (isXxxxVisible) et des variables de contenu (invoiceRateDisplayed/invoiceTotal)

Les colonnes suivantes correspondent aux jeux de données avec les valeurs des variables. Elles peuvent être fixes (member1@yopmail.fr), booléennes (true/false) ou évaluées (Eval(out_subTotal * 0.2 + out_subTotal))

La valeur de la variable out_subTotal remonte directement de l’interface de l’application testée.

Ce fichier Excel teste donc 3 comptes utilisateurs distincts (Admin/Member/Viewer).

Le processus de l’implémentation du test consistera donc à se loguer avec les identifiants, puis vérifier la présence ou non des différents menus, pour lire une facture et vérifier que la TVA est bien conforme.

Si la TVA du compte admin est amenée à évoluer, il suffira de changer l’expression évaluée dans la cellule B9. Il est possible d’ajouter des colonnes ou de modifier des valeurs à tout moment en fonction de certaines spécifications.

Le testeur fonctionnel n’aura que son fichier Excel à maintenir et bien entendu qualifier tous les défauts lorsqu’ils apparaissent.

C’est lui qui écrira les « spécifications » de l’implémentation des « variables ».

Le développeur aura en charge d’implémenter la logique « bas niveau » du test. Par exemple la lecture de la variable out_subTotal ou les éléments à vérifiés pour in_isBackOfficeMenuVisible.

L’implémentation du test avec une approche « no code »

Comme il n’y a pas de magie, il va falloir exécuter le test dans un contexte réel. Reprenons l’exemple de l’application Web qui génère des factures. Voici la recette à suivre pour mettre en développement cette implémentation technique. Il faut lancer un navigateur, taper l’url de l’application, se loguer, …

Dans notre approche « no code », nous utiliserons le plug-in SELENIUM IDE pour enregistrer le parcours tout simplement en naviguant sur le site en mode « Record ». Chaque interaction avec le navigateur est enregistrée étape par étape avec 3 entités (Command/Target/value) qui peuvent être représentées au format Json, voici le scprit :

{

« command »: « click »,

« target »: « //span[class=’menu-test’]/h1/p »,

« value »: «  »

},

Tous les éléments « bas niveaux » (Chemin xPath pour les Targets) sont automatiquement générés par le Plug-in SELENIUM IDE que ce soit initialement ou lorsque l’on modifie l’étape du plan.

L’exécution d’une étape peut être conditionnée à la valeur True d’une variable, pour par exemple n’exécuter une étape que pour un jeu de données particulier.

Le lien entre le fichier Excel et l’implémentation passe par l’utilisation de variables in_ et out_.

La première étape consiste à préparer son scénario avec les variables à « injecter » en utilisant la syntaxe SELENIUM suivante : ${in_NomVariable, ValeurParDéfaut}.

Le « in_ » permet d’indiquer que la variable sera remplacée par un jeu de donnée en « entrée » en provenance du fichier Excel (sinon la valeur par défaut sera utilisée).

Exemple 1 : Click sur une barre de menu définie par in_menu

Exemple 2 : Vérification d’un texte dans in_menuName

Il est également possible de récupérer des valeurs depuis l’interface avec les commandes de type Store de SELENIUM et des variables préfixées par « out_ ». Par exemple il est possible de lire une valeur sur l’écran d’un site web et de l’utiliser dans une expression pour « calculer » une valeur qui remplira une variable « in_ ». C’est précisément ce qui est fait dans la cellule C9 de l’exemple :

in_invoiceTotal = Eval(out_subTotal * 0.2 + out_subTotal)

La variable in_invoiceTotal va être remplie avec l’expression évaluée « out_subTotal * 0.2 + out_subTotal » qui correspond au calcul du total avec la TVA de 20%, la variable out_subTotal ayant été lue sur l’interface de l’application.

Toute la logique de test est alors entièrement décorrélée de la partie scripting SELENIUM.

Sur un gros projet d’automatisation, en termes de gestion, la séparation des compétences et des responsabilités et un facteur de succès dans le temps afin de détecter les anomalies et de performer dans les résultats du test.

Le développeur automaticien reste concentré sur la maintenance des scritps SELENIUM et le testeur fonctionnel fait évoluer ses cas de tests avec un fichier Excel, tout simplement sans avoir à faire de l’intégration de code en particulier.

Conclusion

Pour garantir la pérennité d’une couverture de tests fonctionnels dans le temps (évolution des équipes) et sa maintenabilité (prise en compte rapide de nouvelles règles métier), la meilleure réponse est surement la séparation des responsabilités dans une approche BDD pour une meilleure gestion et un travail d’équipe de qualité.

Le testeur fonctionnel (idéalement certifié ISTQB) est responsable des scénarios de tests et donc de la logique métier (écrits dans un fichier Excel).

Le développeur automaticien est responsable de l’implémentation technique de cette logique via des scripts automatisés grâce à l’utilisation de variables en entrée ou en sortie sans écrire une ligne de code.

L’approche de séparation de la logique de test de l’implémentation des scripts permet de minimiser la maintenance du système et en maximiser la couverture testée par l’outil lors de vos tests techniques d’application mobile ou web.