QA Automation testing : quoi, pourquoi, comment ?

Concept généralisé du test

Pourquoi tester ?

Une bonne stratégie de test présente au moins 4 grands avantages :

• Anticiper/Minimiser les coûts d’implémentation additionnels, en identifiant les défauts au plus tôt.
• Assurer la qualité d’un produit, son efficacité, ses fonctionnalités et sa fiabilité, par rapport à l’attendu.
• Vérifier la bonne couverture d’un processus par rapport aux requirements : conforme au cahier des charges, conforme à certaines normes comme la qualité logicielle mais surtout au document métier.
• Communiquer une décision lors des GO/NO GO meetings. Grâce au rapport de test on décide d’une mise en production ou non d’un produit, de l’ajout de certaines fonctionnalités, et on est informé de la présence ou non de régression.

Il y a quatre niveaux de test (*) :

• les tests unitaires, qui sont réalisés par les développeurs (code localisé, sans dépendance - toujours automatisés),
• les tests d’intégration et les tests End-to-End, qui sont réalisés par les Qualité Assurance testeurs,
• les User Interface tests, qui sont réalisés par les business testeurs.

Les tests automatisables pour les QA testeurs sont les tests d’Intégration et les tests End-to-End.

(*) Source: https://astqb.org/assets/documents/CTFL-2018-Syllabus.pdf

Huit types de test d’intégration sont définis dans la norme de qualité Logicielle ISO – 25010. On y retrouve les tests de : Maintenabilité, Performance, Fonctionnalité, Compatibilité, Fiabilité, Sécurité, Utilisabilité, Portabilité.

Dans les tests de Fonctionnalité on trouve les tests de régression, ces fameux tests qui réexécutent des tests fonctionnels et non fonctionnels pour s'assurer que le logiciel précédemment développé et testé fonctionne toujours comme attendu, après un changement. On retrouve aussi les tests de confirmation.

Ce sont donc les tests d’intégration, dont les tests de régression et de confirmation, qui représentent la plus grosse part de tests automatisés.

Pourquoi automatiser les tests

Je pourrais citer beaucoup d’avantages quant à l’automatisation de tests, mais retenons en priorité : la réduction du temps nécessaire à l’exécution d’un test, sa reproductibilité et sa rapidité par rapport à l’être humain, la réduction des erreurs liées à des interventions humaines, mais aussi la complexité plus avancée des tests lancés. Toutes ces caractéristiques augmentent fortement la confiance envers le produit, tout en réduisant les coûts de ces phases de test, une fois implémentées.

Processus généralisé d'un test Automatisé 

Il se déroule en quatre étapes majeures :

• le Test Plan : On étudie la faisabilité, d’abord d’un point de vue manuel puis automatisé, on étudie la stratégie d’automatisation puis enfin on décide du Framework.
• le cas de test : C’est ici que l’on va définir les données nécessaires, créer les scripts et les scénarios d’utilisateurs.
• l’exécution du test : On construit et on exécute le flux, d’abord sur nos environnements de test en local, puis on déploie les suites de test dans le cloud et on exécute les scripts de test.
• le rapport de test : C’est dans cette étape que l’on formalise les résultats, les bugs et les défauts détectés.

Il est parfois nécessaire de réaliser une maintenance des tests suites en place et d’actualiser les actifs.

Architecture de test automatisé et Framework
Précondition : réaliser et valider un test manuel concernant la fonctionnalité.

Pour l’automatisation de test, l’utilisation de Framework est nécessaire. Dans la suite de cet article je vais me concentrer sur les tests automatisés front-end. Peu importe le Framework utilisé, les étapes restent généralement similaires ; ici nous parlerons d’un Framework d’architecture Java utilisant l’outil d’automatisation Maven sur l’IDE Intel IJ.

Mapping
Cette étape consiste à récupérer les objets web ou mobile avec lesquels nous allons interagir. Chaque objet possède des attributs : ID, Xpath, CSS, class … qui nous permettent de l’identifier de manière unique. On associe donc des noms à des attributs que l’on organise en classes, qui correspondent aux pages du projet. Notons que pour le web on peut directement inspecter le code avec le browser.

Pour la partie mobile, il existe plusieurs moyens d’inspecter le code : des outils comme Appium inspecteur/serveur ou XCode permettent de visualiser le code source d’une app sur un appareil connecté localement, de même des providers de device en ligne dans le cloud comme Browserstack ou Saucelabs nous permettent aussi d’inspecter le code source.

Scénario
Généralement les scénarios sont écrits en Gherkin, venant de Cucumber BDD. C’est ici que l’on va définir l’action à réaliser sur l’objet/page en question que l’on passera en paramètre. Chaque Template Gherkin appellera une ou plusieurs fonctions spécifiques définies au préalable pour réaliser cette action. Plusieurs scénarios forment un feature file, et plusieurs feature files forment une suite de test.

Définition des Fonctions
Les Fonctions sont ici définies en Java et vont directement interagir avec Selenium et/ou l’Appium. C’est ici que l’on retrouve les fonctions de connexions, d’actions de base (cliquer, écrire, lire, vérifier la présence…), d’interactions avec les bases de données, nos fonctions spéciales (upload de files, authentification forte, commande ADB, curl, récupération des traductions manquantes…), toutes liées à des templates Gherkin pour leur appel dans nos scénarios.

Exécution des tests
Après sélection des scénarios, on a la possibilité de les exécuter sur de véritables appareils ou simulateurs, localement ou à distance. Beaucoup de paramètres réseaux et système sont à régler et beaucoup de variables sont à prendre en compte durant le setup (version, dépendance, librairie, compatibilité…).

Localement : Pour la partie navigateur, seul un driver est nécessaire.

Pour la partie mobile, beaucoup d’outils ont besoin d’être installés, comme Node JS, Appium serveur/Inspecteur, ou encore AndroidSDK (test sur appareil Android dans un environnement Windows). Pour des tests IOS, un device Apple est nécessaire avec XCode et une configuration adaptée.

A distance : De la même manière qu’on inspecte le code à distance, on peut exécuter nos tests à distance, l’avantage étant que l’on dispose de tous les appareils, systèmes d’exploitation et versions souhaités. A la fin de chaque exécution les statuts des tests sont disponibles.

TIPS : Pour lancer ces exécutions de tests j’utilise un TestRunner, « TestNG ». C’est ici que je peux exécuter en parallèle, utiliser des threads, charger les dépendances (hooks, before, after)…

Rapport
Après l’exécution de chaque série de tests un rapport Cucumber est disponible, montrant le statut (passé, échoué, sauté, en attente d’envoi...) de chacun des scénarios step-by-step et une capture d’écran est disponible au moment où le test échoue. Si l’on exécute sur des solutions dans le cloud on bénéficie en plus d’une vidéo pour chaque scénario.

Intégration continue et continuité de service
Intégration continue : GIT/Azure DevOps
our garantir l’intégration continue, j’utilise GIT et Azure DevOps. Avec ces solutions, il est plus facile de mettre à jour mon code et de le maintenir face aux changements front/back du projet. Cette pratique est essentielle pour garantir une traçabilité, pour partager son code au sein de l’équipe et pour assurer la continuité de service.

Continuité de service : Jenkins avec des conteneurs Docker
Afin de garantir la continuité de service j’utilise un serveur d’exécution : Jenkins, à l’aide de pipelines que je programme en Groovy. Je peux donc programmer un déploiement de mes tests à n’importe quelle heure, et avec n’importe quel paramètre. Dans le pipeline je définis les différentes étapes du déploiement, le projet à récupérer, les paramètres systèmes à utiliser, les images à utiliser (Docker container), etc.

Pour mes projets d’architecture Java et pour recréer l’environnement propice à chaque projet j’utilise des containeurs Docker contenant des images avec Java/Maven.

Une fois mes tests automatisés rédigés, je suis souvent la même stratégie (sauf cas particulier) :

(1) Je mets à jour mes cas de test (scénarios et codes).

(2) J’exécute les tests en local ou sur le provider de device dans le cloud.

Ou

4) Je programme l’exécution de mes tests dans le cloud grâce à Jenkins qui va exécuter le conteneur Docker avec Maven/java (4), les deux en récupérant le code source de GIT (3).

Je paramètre une récurrence (6) avec le type de device, l’environnement, la version, l’OS … (5) pour assurer la continuité de service.

Je publie les statuts de test et les résultats/vidéos (7). Pour terminer j’obtiens la synthèse des résultats de tests sous forme de rapports.

Dans mon Framework d’architecture Java j’utilise l’outil d’automatisation Maven, contenant des scénarios en Gherkin appelant des fonctions code en Java.

Pour inspecter le code source et exécuter les tests en local sur la partie mobile j’utilise : XCode, Appium Inspector/Server, Node JS et Android SDK.

Pour inspecter le code d’un navigateur rien n’est nécessaire à part le navigateur en lui-même, cependant pour exécuter un test sur navigateur en local le driver de celui-ci est nécessaire ainsi que Selenium.

Pour exécuter mes tests j’utilise un TestRunner (TestNG).

Pour l’exécution de tests dans le Cloud j’utilise BrowserStack ou Saucelabs.

Pour l’intégration continue j’utilise GIT et Azure DevOps.

Pour la continuité de service j’utilise Jenkins et des conteneurs Docker.

La mise en place de toute cette chaîne doit faire partie d’une stratégie de test globale définie en amont, dans le but d'améliorer la qualité du produit final livré au client, et ce dans le respect des normes qui cadrent et définissent le développement de logiciels.

OSTERTAG Quentin - QA Automation Engineer chez AINOS

Diplômé de Telecom Physique Strasbourg

Sources :

"Syllabus du testeur certifié niveau fondation (CTFL) ", ISTQB, édité pour la dernière fois le 1er juillet 2021 :

https://istqbmain-web-prod.s3.amazonaws.com/media/documents/ISTQB-CTFL_Syllabus_2018_v3.1.1.pdf

"Test Automation Engineer", astqb, édité pour la dernière fois en 2016 :

https://astqb.org/assets/documents/Advanced-Test-Automation-Engineer-Syllabus-GA-2016.pdf

"Next Generation Java Testing", édité pour la dernière fois le 19 mai 2022:

https://testng.org/doc/