Bonnes pratiques pour l’automatisation des tests fonctionnels

6 Août 2020
bonnes-pratiques-automatisation-tests-fonctionnels
On voit souvent l’automatisation des tests comme le sésame vers la qualité, des coûts réduits et des tests lancés magiquement sur chaque fonctionnalité sans aucune intervention. Ce n’est cependant pas toujours le cas

 L’automatisation des tests nécessite une vue d’ensemble du/des projets, de l’analyse, des ateliers avec le métier, le tout encadré par des bonnes pratiques que nous détaillerons par la suite. Il ne faut pas sous-estimer l’effort de la mise en place de tests automatisés, il comprend :

  • le temps de compréhension ;
  • le temps de développement ;
  • le temps de mise en place ;  
  • le temps d’analyse des résultats ;
  • la maintenance des tests automatisés.

On comprend donc qu’automatiser chaque fonctionnalité d’un applicatif prend plus de temps que de les analyser et de les tester manuellement. Dans ce cas l’automatisation n’a aucune plus-value. Mais alors, y a-t-il un réel intérêt à automatiser des tests logiciels ?

 

L’automatisation oui, mais dans quels cas ?

L’automatisation des tests sert à conforter les chemins critiques des applicatifs, ainsi que les régressions, afin de trouver au plus tôt les anomalies et réduire le coût des correctifs. On peut dire que l’automatisation prend tout son sens dès lors que nous abordons le sujet de la régression. Il arrive que sur des projets conséquents, des modifications, ajouts ou corrections, engendrent des anomalies qui entravent d’autres fonctionnalités validées précédemment. On parle alors de régression.

On peut alors, mettre en place des tests automatisés de non-régression et les jouer avant chaque déploiement sur les machines dédiées, afin de détecter le plus tôt possible les éventuelles régressions. La mise en place de tests automatisés permet un gain de temps, de coût et de ressources. Plusieurs critères vont nous permettre de faire le choix, ou non, de la mise en place de ces tests :

  • Premièrement, la taille du projet : sur un petit applicatif non critique ou avec peu d’évolutions, des tests de non-régression peuvent être effectués manuellement, ce qui n’est pas le cas sur un applicatif conséquent. Les tests automatiques permettront de ne pas perdre de temps à refaire les même tests plusieurs fois.
  • Deuxièmement, le nombre de tests à mener et la répétition des tâches : une personne qui a l’habitude de répéter un geste ou une action plusieurs dizaines, centaines voire milliers de fois, ira beaucoup plus vite qu’une autre qui n’a pas l’habitude de ces gestes. En revanche, le risque de voir l’individu habitué réaliser des erreurs dû à la répétition importante des tâches, est beaucoup plus élevé également. S’il y a trop de tests répétitifs à mener, la meilleure décision sera de les automatiser, car un robot ne se trompera jamais.
  • Troisième critère, la durée du projet et sa complexité : sur un projet de courte durée, inférieure à 2-3 mois, il ne sera pas forcement judicieux d’allouer des ressources à la mise en place des tests automatisés. Le temps passé à analyser, paramétrer l’environnement et écrire les cas de tests peut engendrer des coûts plus importants qu’un testeur fonctionnel. Il faut donc déterminer la fréquence nécessaire des tests automatisés et évaluer l’apport qualitatif par rapport au coût.

Pour résumer, l’automatisation des tests devient nécessaire dès que :

  • Plusieurs personnes développent conjointement.
  • Le projet a une durée et une complexité conséquente nécessitant une base fiable.
  • Le projet est considéré comme critique.
  • Le projet a un besoin qualitatif de haut niveau.
  • Il y a des régressions à presque chaque déploiement.
  • Il y a un besoin de vérifier l’envoi de data vers une autre application (intercommunication d’applicatifs).

 

L’automatisation selon AUSY :

Nous vous proposons de vous exposer ici quelques bonnes pratiques, indispensables à la réussite des tests automatisés.

 

1. Modélisation du projet 

AUSY recommande dans un premier temps de passer par une étape de modélisation des parcours métiers puis par une étape de modélisation orientée test. Elles permettent de définir des modes de communication adaptés pour que l’attendu corresponde au résultat final, mais surtout, pour que les tests automatiques reflètent cet attendu. Cela se traduit par la mise en place d’un langage commun et d’une documentation vivante, pour faciliter la collaboration entre les différents acteurs d’un projet. Cela permet d’avoir une vision macro des applications métiers d’une part, et d‘autre part des parcours critiques applicatifs qui illustrent l’expérience utilisateur.

Dans un second temps, la modélisation de parcours métier est élargie aux parcours de tests en consultant les experts métier et les utilisateurs pour déterminer les points sensibles ou les régressions récurrentes.

Afin d’animer les ateliers de modélisation, nos choix se portent sur quatre outils :

  • Entreprise Architect, développé par Sparx Systems, est un logiciel complet pour toutes les modélisations. Nous utilisons cet outil comme une plateforme sur laquelle échanger les fichiers ou méthodes autour des divers ateliers avec le client.  

 

  • draw.io est une application qui contient déjà des modèles de BPMN. Elle est très facile d’utilisation et nous la conseillons pour sa simplicité, son prix mais aussi pour son intégration possible à JIRA.

 

  • Yest, couplé avec Jira, permet de faciliter les interactions entre le métier et les équipes de tests. Yest permet au PO ou Business analyst de créer les parcours de tests depuis Jira, puis, sera étoffé dans Yest par un testeur qui lui, valorisera les jeux de données et rajoutera les contrôles nécessaires. Yest permettra de créer le canevas du test automatique au travers de keywords, déjà existant ou à développer, et alors exécuter les tests automatiques.

 

2. Le BDD

Une fois que la modélisation a été effectuée, il est très facile de l’adapter à l’automatisation. Les automaticiens sont en mesure d’écrire des parcours de tests automatisés cohérents, évitant ainsi le piège d’automatiser des parties inutiles ou instables.

Cette étape de modélisation facilite donc grandement le choix des tests à automatiser, et ceux à garder en fonctionnel. Elle permet un gain de temps important, et nous y accordons une grande importance. L’une des erreurs les plus communément commise est de vouloir automatiser l’intégralité des tests fonctionnels. Cela peut engendrer une perte de temps et de coûts qui n’est pas forcément nécessaire. Sensibiliser les équipes internes sur cet aspect est l’une de nos plus grandes préoccupations.

Afin de faciliter l’automatisation des tests, AUSY recommande l’utilisation du BDD (Behavior Driven Development). Les équipes AUSY s’appuient sur la méthodologie agile BDD qui a pour but de créer des tests fonctionnels avec un langage naturel compris de tous (Gherkin). Les trois principes majeurs du BDD sont :

  • La participation des équipes non techniques au projet grâce à un langage facile à comprendre et à utiliser. Nul besoin d’avoir des compétences poussées en langage de programmation ou développement.
  • Des scénarios automatisés pour décrire des comportements utilisateurs, comme le montre l’exemple ci-dessous :  

langage-gherkin-bdd
  • Grace au langage Gherkin, les utilisateurs finaux sont en mesure de décrire très précisément ce qu’ils désirent. Cela permet ainsi aux équipes techniques d’avoir une meilleure compréhension du besoin. Un outil de type RobotFramework permet aux développeurs de transformer du langage en code de développement.

Soit dans notre cas : (exemple avec RobotFramework)

langage-gherkin-bdd

 

Le lien entre les comportements décrits et les fonctions est fait, le test peut être exécuté.

Si AUSY a fait le choix de s’appuyer sur cette méthode, c’est parce qu’elle permet une meilleure compréhension entre les différentes équipes, une meilleure collaboration, une meilleure vue d’ensemble sur le projet et donc forcément, une amélioration de la qualité des livrables, au travers des différentes phases d’itérations.

Coupler l’automatisation au plus tôt avec du BDD et de la modélisation permet de mieux maitriser la compréhension du produit final à chaque étape, de gagner en confiance et en qualité, pour stabiliser les versions et permettre des évolutions sereines.

 

3. Analyse technique et faisabilité 

Une autre bonne pratique à respecter, est celle du choix des outils collaboratifs de gestion des tests et de l’automate.

 

a. Lister de manière exhaustive les différentes technologies

Certains outils d’automatisation et frameworks ne fonctionnent que pour les web apps, d’autres que pour les clients lourds et certains ne peuvent pas faire de test API ni SOAP. Il est donc important de bien analyser toutes les technologies et de déterminer les composants indispensables à l’automatisation, en fonction de l’environnement de travail.

 

b. Déterminer les meilleurs outils d’automatisation selon les spécificités techniques du projet

Il est possible de jongler avec plusieurs outils. Cela demande cependant des profils avec des compétences multiples, et des soucis de configuration inhérents à chaque outil peuvent apparaître, ce qui multiplie le nombre potentiel de points d’attention.

Pour ce qui est du choix de l’automate, AUSY recommande l’utilisation de RobotFramework car il permet de tester aussi bien les applications web, les APIs et les clients lourds. De plus il donne la possibilité d’utiliser de nombreuses libraires Python existantes, ou d’en développer le cas échéant, sans une trop grande complexité. De plus, Robot Framework utilise le langage Python, qui est très en vogue, très ouvert et permissif et repose sur une communauté importante permettant de solutionner tous types de problématiques. Enfin, l’utilisation du langage Python permet de pallier au manque de ressources humaines. Il est alors tout à fait possible de rapidement recruter des développeurs Python ayant une parfaite maîtrise du langage, et qui seront formés sur les bonnes pratiques d’automatisation.

Nous reviendrons plus en détails sur l’utilisation de RobotFramework et ses avantages dans un prochain article.

 

4. L'étape de scripting 

Une fois le choix des outils de gestion des tests et de l’automate effectué, place au développement, que ce soit en JAVA, PYTHON, GHERKIN, SQL… Peu importe le langage choisi, c’est à ce moment que l’on détermine la maintenabilité des scripts et de l’automatisation. Il devient alors important de conserver une structure cohérente avec le projet et la structure des tests : Campagne -> Plan de test -> Suite de test -> Cas de test -> Test.

Le développement des scripts et des artéfacts associés est nécessaire, pour permettre l’exécution du test, afin qu’il soit en phase avec les résultats attendus dans les exigences ainsi qu’avec les critères d’acceptation. Afin de mener à bien cette étape, AUSY conseille de respecter les bonnes pratiques de développement, telles que :

 

     a. L’organisation des tests automatisés comme un projet de développement

L’organisation des tests ainsi que les nomenclatures associées sont un point névralgique lors de la conception des tests automatisés. Le volume des tests grandissant très vite, il est indispensable de conserver une organisation ordonnée. De plus l’intégration des tests dans un processus de développement nécessite aussi de tester ces tests automatiques et par conséquent de passer par une phase de tests unitaires, d’autant plus facile à mettre en place dans une hiérarchie de projet de type Dev.

 

     b.  La variabilisation des données et des objets

Les différents objets avec lesquels on a besoin d’avoir des interactions se multiplient au fur et à mesure que l’on avance dans les étapes des parcours d’automatisation.

Trop souvent, des données indiquées directement dans le code nous amènent à une énorme perte de temps en maintenabilité, ainsi qu’un souci lors de répétitions d’exécution sur jeux de données différents. À l’inverse, on comprend bien que l’on ne peut pas écrire un cas de test par jeux de données différent.

 

  • Choix du/des attributs

 

i. Les Web Apps

Les possibilités que l’on a sont les identifiants par id, CSS, attributs spécifiques d’une balise et bien entendu, les Xpath. Les recommandations portent bien évidement sur les id qui sont des données stables et non vouées à des changements fréquents. Lorsqu’ils ne sont pas présents il y a les autres attributs qui eux sont déjà moins stables, et le risque d’effectuer une maintenance importante sur ces objets est fort.

Il reste donc la solution du Xpath. Cette solution n’est pas populaire auprès des développeurs car la version XPATH 1.0 et ses premières utilisations dépendaient de l’arborescence absolue. Le moindre changement (ajout d’une colonne, d’un menu, d’un CTA…) nécessitait une maintenance sur les objets. Les évolutions du Xpath permettent aujourd’hui de localiser des objets directement par un attribut, un bout de texte ou en relatif dans un tableau, et ainsi d’avoir un point d’entrée et d’aller vérifier la donnée correspondante de la énième colonne, sans avoir besoin d’effectuer une maintenance sur l’intégralité des objets.

 

ii. Les clients lourds

Pour les clients lourds on utilise un inspecteur (inspect.exe) présent sur les dernières distributions Windows. Il récupère toutes les informations de l’objet dont son nom, sa classe ou un id.

Tous ces choix restent stables et ne nécessitent que très peu de maintenance.

 

  • Complexité

Il faut parfois bien analyser le DOM (Document Object Model) pour déterminer si la complexité est nécessaire ou si l’on peut mettre en place une autre solution. Il peut arriver de se retrouver dans le cas où seul un Xpath est possible et où tous les attributs amènent plusieurs résultats. Dans ce cas il peut être nécessaire de contacter l’équipe de développeurs pour ajouter des id aux balises pour éviter d’avoir des dépendances qui ne sont pas stables. Parfois un recours à une modification du développement est nécessaire.

Nous préconisons de tenir un fichier à jour avec un identifiant de l’objet, une version de l’applicatif et un petit imprime-écran permettant de retrouver rapidement l’objet en question pour le maintenir.

 

  • Robustesse

On peut mesurer la robustesse d’un identifiant d’objet en fonction de sa capacité à résister aux modifications du code. L’évolution du Front d’une Web App est souvent à l’origine d’une maintenance nécessaire pour que les tests automatisés restent fonctionnels. On peut donc travailler la robustesse de nos identifiants d’objets soit en ajoutant un id, soit en ajoutant un nouvel attribut dans les balises utilisées pour l’automatisation (très chronophage) ou en modifiant nos Xpath. Récupérer un Xpath nous amène souvent un chemin absolu qui est, comme nous l’avons indiqué précédemment, très instable et par conséquent déconseillé.

Par exemple : si nous identifions le champ de recherche sur le site https://www.google.fr, on obtient :

/html/body/div/div[4]/form/div[2]/div[1]/div[1]/div/div[2]/input

Le moindre changement sur cette page et notre Xpath est à refaire, alors que si l’on analyse les attributs du champ qui nous intéresse on obtient :

Une classe, un nom, un type, un titre, un label ….

Maintenant il suffit de déterminer et de vérifier si ces informations sont uniques. Il n’existe qu’un seul champ input de type « text » dont l’attribut name est « q ». On peut donc choisir ces deux éléments pour définir un Xpath robuste, puisqu’il est très peu probable que deux identifiants uniques soient changés en même temps. Ce qui donnerait : //input[@type= « text »]|//input[@name= « q »]

PS : il y a un pipe | entre les deux expressions pour indiquer le OR

 

  • Maintenabilité

En termes de maintenabilité, le cauchemar des automaticiens est de devoir passer trop de temps à modifier les cas de tests déjà écrits, « juste » pour faire fonctionner quelque chose qui fonctionnait auparavant.

Au-delà de l’ironie de la régression sur des tests de non-régression, il faut penser maintenabilité dès la première brique posée :

  • Variabiliser chaque objet ;
  • Séparer les fichiers où se trouvent les objets, par exemple un général avec le menu de la page et les URL, un autre pour la page accueil ;
  • Utiliser une nomenclature compréhensible ;
  • Bien ordonner son projet pour retrouver de suite où se trouve chaque partie ou objet.

 

Le risque, en ne procédant pas à une telle classification, est de faire appel à des variables qui ne sont pas les bonnes lors des tests, car elles n’ont pas été clairement catégorisées et définies. Solutionner ce type de problème entraîne alors une perte de temps importante.

 

5. Utilisation de "bouchons" ou "mock"

Nous conseillons l’utilisation des « bouchons » ou « mock » qui permettent de créer un environnement clos et de tester l’intégration au plus tôt. Des libraires Python permettent de créer des mocks pour les tests d’APIs. Dans des cas plus complexes une solution de bouchon développée en Java, Python ou tout autre langage doit être envisagée afin de pouvoir exécuter les tests de façon isolée.

 

6. Le partage collaboratf d'informations et de résultats

Enfin, AUSY conseille d’utiliser des logiciels ou outils collaboratifs (Jira/Xray) permettant le partage des résultats avec tous les membres, et potentiellement le client. Cela permet à tous les acteurs travaillant sur le projet, d’avoir une vue d’ensemble des résultats, et savoir instantanément ce qui a été opéré. Encore une fois, le gain de temps est considérable.

 

Les bénéfices de l’automatisation

Au fil de cet article on peut s’apercevoir que l’automatisation des tests a plusieurs utilités. Inutile de rappeler que les tests au plus tôt, au plus proche du développement, améliorent la qualité et l’efficacité des solutions, et réduisent le coût et le temps passé aux correctifs de régression. Les bénéfices de l’automatisation résident dans une meilleure couverture de vos tests, un testing plus régulier et plus important, une diminution du risque d’erreurs et la réduction des délais entre l’expression des besoins et la mise en production.

Bien entendu il faut pouvoir maitriser toutes les étapes et les adaptations nécessaires à ce bon fonctionnement. AUSY se démarque par sa volonté d’accompagner pas à pas ses clients dans leur projet de transformation digitale et d’automatisation de leurs tests. Pour cela, AUSY s’appuie sur la mutualisation des compétences complémentaires de nos coachs test. Leurs longues années d’expérience leur permettent d’exprimer une réponse immédiate à un grand nombre de problématiques complexes et apportent ainsi un gain de temps non négligeable sur le projet. Leur savoir-faire en coaching et leur bonne capacité d’adaptation facilitent la formation et l’acculturation des équipes internes sur les bonnes pratiques d’automatisation, afin de les accompagner, s’ils le désirent, vers une autonomie totale.

 

Aussi n’hésitez pas à visiter notre offre Tests Logiciels

Parlons ensemble de vos projets.

contactez-nous AUSY