REX : Mise en place d’une solution d’automatisation des tests – Cathy Blache

 Retour d’expérience : Mise en place d’une solution d’automatisation des tests de régression sur des applications métiers : Robot-Framework interfacée avec SquashTM & Autom

Après une analyse préalable et l’étude des différents types d’automatisations, en tenant compte de la complexité de nos applications à tester, nous avons choisi une approche d’automatisation par mot clés, en se basant sur les éléments suivants.

Après plusieurs POC (preuve de concept), nous nous sommes orientés vers robot framework assez rapidement car Open source, avec une grande diversité de librairies compatibles, une communauté active, il répondait à nos exigences et permettait d’aller beaucoup plus vite que si nous développions nous même nos scripts en python. Nous avons débuté les développements en 2021. Les scripts robot framework sont robustes, et plus facilement maintenable qu’une solution d’enregistrement / rejeu, ce qui faisait de lui un bon candidat pour l’automatisation dans notre contexte. Nos exigences étaient les suivantes : pouvoir maintenir facilement les scripts pour nos application dont nous devions également accroitre la testabilité (gros effort en maintenance nécessaire au départ), récupérer des fichiers générés par nos applications et les stocker à des endroits choisis (enregistrement / déplacement / renommage de tout types de fichiers : xml, pdf, txt…) et pouvoir créer des fichiers Excel de données permettant d’implémenter les bases de tests, et par la suite pouvoir s’interfacer avec un référentiel de tests…

L’équipe de développement des tests automatiques créée est composée uniquement de testeurs fonctionnels connaissant bien le métier et les applications à tester, ayant une appétence pour le développement mais n’y étant pas forcément formés.

La formation a été principalement réalisée à l’aide des tutos vidéo disponibles sur youtube, notamment la suite de tutoriel de la chaine software testing mentor pour les 2 premières personnes ayant commencé les développements, elles se sont ensuite chargées de documenter, les différentes installations nécessaires, librairies utilisées, bonnes pratiques à mettre en place. Un groupe projet comprenant des développeurs a également été créé pour nous aider définir les outils et les normes de développement utilisés.

Nous utilisons :

  • Visual studio code pour le développement des scripts robot framework, notre norme de développement prévoit des dossiers pour les fichiers de données, les scripts, les fichiers ressources : mots clés / objets, l’auto complétion fonctionne bien. (Cela aurait pu également être avec PyCharm avec lequel cela fonctionne tout aussi bien : nous avons simplement gardé l’outil déjà utilisé en interne)
  • Les librairies standard de robot framework sont suffisantes pour le développement de tous nos tests à ce jour, nous utilisons principalement :
  • Selenium library
  • BuitIn pour la création d’un mot clé spécifique pour télécharger des documents pdf au lieu de les ouvrir dans le navigateur chrome (entre autres : cette librairie est très utile)
  • OperatingSystem pour les manipulations de fichiers
  • Process pour lancer des commandes javascript quand nécessaire : contournement d’une testabilité à améliorer.

Un effort a également été fait avec les développeurs pour la testabilité des produits et la stabilité des tests automatiques : Mise en place de datatest-id.

  • Gitlab pour la sauvegarde et le partage des sources des différents projets de tests automatiques

Après la mise en place de Robot framework, il a été nécessaire de créer un environnement dédié aux tests automatiques, nos exigences, pour cette seconde phase, étaient les suivantes :

  • Exécution des tests sur des « postes clients » conformes aux environnements de nos clients (pas de linux, exécution dans un docker non souhaitée)
  • Interfaçage avec un référentiel de tests permettant de lancer et de récupérer automatiquement les résultats de tests pour une utilisation simple par des testeurs ne connaissant pas l’automatisation

Notre choix s’est dirigé vers : Squash TM* et Autom* qui répondent à nos attentes.

Notre service informatique a été également mis à contribution pour la mise en place de cette infrastructure ainsi que les équipes Squash très réactives pour répondre à nos interrogations.

Nous avons donc désormais une infrastructure de tests automatiques qui s’articule comme suit 

(L’intervention humaine n’est nécessaire que sur les actions en bleu)

Squash TM et Autom évoluent et proposent de nouvelles fonctionnalités intéressantes : pour exemple dans sa version 6.0.0 sortie fin décembre 2023 : le testeur peut suivre en direct l’avancement et les résultats des tests automatiques :

Comme suit sur un scénario enchainant 4 cas de test, les résultats et leur rapport apparaissent au fur et à mesure de la fin de leur exécution.

* Plus d’informations sur l’évolution de l’offre Squash en 2024

À propos de l’auteur : Cathy BLACHE

Titulaire d’un Master Ingénierie du Test et de la Validation Logiciels et Systèmes (ITVL).

Référente Qualité et chef de projet d’automatisation des tests au sein de son entreprise.

3 réponses

    1. Normalement (ce n’est pas moi qui ai fait le REX) oui!

      Je ne vois pas pourquoi cela ne serait pas le cas

  1. Un super travail de ta part qui a permis à l’équipe de pouvoir apprendre à développer des scripts en Robot dans les meilleurs conditions possibles.

    Merci encore pour ton savoir et ton envie de le partager

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Non régression or not

Certains en font beaucoup, d’autres pas du tout. Pourquoi cette différence de traitement en ce qui concerne la non régression. Quel est son objectif ? Pourquoi certains en font, quand d’autres non ? Le principe même d’une anomalie est de ne pas savoir où elle va advenir, ou sinon il n’y en

Lire la suite »
culture générale

Les tests exploratoires

On entend beaucoup de choses sur les tests exploratoires, la définition donnée est rarement la même selon les personnes avec qui on discute… Cela va du très compliqué avec l’utilisation de « charter » au simpliste « quelqu’un qui fait n’importe quoi sur l’application ». Voici celle que j’utilise maintenant : Les tests exploratoires c’est

Lire la suite »
Image représentant le test et de nombreux éléments liés
Campagnes

Le test en image (6)

Image utilisée pour le bandeau du blog La taverne du testeur : Les étapes d’une campagne de test (ce n’est bien sûr pas que l’exécution) : Les différences entre Intégration, livraison et déploiement continu (extrait de ma présentation avec Audrey Menargues à la STLS) : L’intégration continue va jusqu’à l’environnement de recette, la

Lire la suite »