Vous préférez parler à une vraie personne ? Nos centres d'appels au Mans, à Reims et à Amiens sont là pour ça
09 77 40 66 66
(prix d'un appel local, même si vous n'habitez pas dans le coin)

Vis ma vie de QA : Automatisation de tests pour les PO

Chez ekWateur, la plus grande partie de mon travail consiste à automatiser des tests. Ces tests ont pour but principal de faire gagner du temps aux PO (Product Owner), mais également d’augmenter la qualité des applications. En effet, comme les tests sont automatisés, plus de tests peuvent être réalisés à chaque nouvelle version (MEP = mise en prod) et MEPP (mise en pré-prod = plateforme de test), ce qui permet de remarquer plus de bugs avant même que les clients ne soient impactés par ceux-ci.

Aujourd’hui, je vais vous expliquer quel est le processus menant à la création de ces tests.

28 octobre 2021

Étape 1 : le PO a un besoin

Avant mon intervention, les PO doivent tester les applications à la main. C’est une activité chronophage et répétitive d’une fois sur l’autre. Ainsi, il y a beaucoup à gagner à automatiser cette partie.

Lae PO vient donc me voir (ou bien c’est moi qui propose mon aide) et nous fixons une réunion ensemble afin de pouvoir parler du sujet plus avant.

Une personne virtuelle regardant des chiffres

Étape 2 : Discussion sur les tests à automatiser

Lors de cette réunion préparatoire, lae PO commence par me présenter l’application à tester. Iel me montre ensuite les tests qu’iel réalise à la main et qu’iel souhaiterait que j’automatise. De mon côté, j’indique ce qui sera facilement automatisable, ce qui sera compliqué à automatiser (mais faisable) et ce qui ne sera pas automatisable.

Une fois ce travail fait, nous nous mettons d’accord sur les tests qui sont à automatiser en priorité.

C’est la fin de la réunion, il ne me reste plus qu’à me mettre au travail.

Étape 3 : Automatisation des tests

La première étape lors de l’automatisation des tests consiste à mettre en place le code qui va jouer les scénarios de test. Bien souvent, cette étape est relativement rapide puisqu’il est possible de copier-coller du code d’un autre projet similaire.

Une fois cette étape faite, il faut écrire le premier scénario de test. Pour « commencer doucement », un scénario relativement court et facile est choisi pour cette étape. Ce premier scénario automatisé ne sera généralement pas conservé sur le long terme, mais il permet de s’assurer que le « set up » des tests automatiques est correct. C.-à-d. : notre robot arrive bien à aller sur l’application/site web souhaité et à y effectuer des actions simples (clic sur un bouton, vérification de présence d’un élément, etc..).

Ensuite, il ne reste plus qu’à rédiger et à automatiser un par un les différents scénarios de tests. Ces scénarios seront automatisés à l’aide de l’outil « Cucumber » et de sa syntaxe « Gherkin ».

Une fois qu’un nombre satisfaisant de scénarii de tests auront été automatisés, il sera temps de passer à l’automatisation côté GitLab (note : gitlab est notre outil d’intégration et de déploiement continu).

Offre d'électricité renouvelable

Étape 4 : Automatisation côté GitLab

L’automatisation côté GitLab se passe en plusieurs étapes.

Premièrement, il faut modifier le fichier ".gitlab-ci.yml" afin d’ajouter des jobs de tests dans les différents pipelines d’intégrations.

Deuxièmement, il faut ajouter les informations sensibles dans les variables gitlab. Cela évite que ces informations soient visibles dans le code ce qui consisterait une faille de sécurité.

Et enfin, il faut mettre en places de tests « schedules » ce qui permet :

  • De lancer les tests en prod de manière automatique toutes les nuits
  • De permettre aux PO d’avoir accès à un simple bouton pour pouvoir lancer les tests à la demande dans le bon environnement.

Étape 5 : Revue des tests réalisés

Une fois que les tests ont été automatisés côté gitlab et qu’il est donc possible pour lae PO de lancer les tests en autonomie, une réunion est planifiée entre lae PO et moi-même.

Lors de cette réunion, je commence par montre à lae PO comment lancer les tests, où voir les résultats de ces derniers et que faire en cas d’erreur.

Lae PO et moi-même passons ensuite en revue les différents tests qui ont été automatisés ainsi que les détails de ce qui a été automatisé. C’est l’occasion pour lae PO de me demander d’ajouter certaines vérifications auxquelles je n’aurais pas pensé.

Recevez notre sélection d'articles autour de la transition écologique

Laissez-nous votre adresse email pour recevoir toutes nos astuces pour un futur plus vert. 🌱🌍 

Étape 6 : Corrections

Une fois la réunion terminée, je m’attèle à apporter les modifications et améliorations demandées par lae PO. Une fois cette tâche terminée, je préviens lae PO (généralement via message Slack) avant de passer à l’automatisation des tests pour l’application suivante.

Pour conclure

Des tests automatiques sont désormais présents. Les PO peuvent et savent s’en servir. De mon côté, je reste en support afin d’aider les PO à comprendre pourquoi un test échoue et je me charge également de mettre à jour les tests existant en cas d’évolutions dans l’application.