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

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.

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.

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).

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 :

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é.

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.

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.