Skello Tech Team
Published in

Skello Tech Team

Comprendre l’automatisation des tests et ses avantages pour l’équipe QA

Au sein de Skello, le travail de la QA peut s’avérer être complexe au vu du nombre de fonctionnalités qui existent aujourd’hui sur les différents services. En conséquence pour un QA, cela représente beaucoup de travail à effectuer et cela devient vite compliqué de savoir quoi prioriser 😰. Dans ce contexte, un projet a vu le jour: l’automatisation de tests système.

Au sens de l’ISTQB (International Software Testing Qualification Board), les tests système sont les tests qui nécessitent une interaction directe avec l’application afin de vérifier si le comportement constaté est conforme aux spécifications définies.

Enjeux de l’automatisation

Dans le monde de la QA, les tests automatisés (aussi appelés tests end-to-end) désignent des tests que l’on cesse d’effectuer manuellement pour les retranscrire dans un script qui le fera à notre place. Quand l’automatisation est bien faite, cela peut avoir de nombreux effets bénéfiques. Tout d’abord, elle permet une couverture de test plus large et plus sure. Il arrive qu’un humain fasse une erreur de manipulation lors de la réalisation d’un cas de test, contrairement à la machine qui reproduira toujours ce scénario de manière identique. Sur le long terme, cela diminue la charge de tests non régression que les équipes QA / Devs / Produit peuvent avoir à effectuer tout en sécurisant la stabilité du produit 🤩.

Pour autant, il n’est pas pertinent d’essayer d’automatiser tous les tests. Chez Skello, nous commençons à envisager l’automatisation d’un test à partir du moment où l’on sait qu’il sera effectué de manière quasi-systématique. Le choix d’automatiser un test ou non dépendra de la criticité du test et cette variable doit être définie en se concertant avec les équipes dev et produit 🤝. Pour chaque feature, il faut penser aux scénarios que nous souhaitons assurer via de l’automatisation. Dans la mesure du possible les règles fonctionnelles doivent être automatisées via les tests unitaires que font les développeurs, le rôle des tests end-to-end est de s’assurer que toutes les briques (back, front, infra) communiquent bien ensemble au travers de cas métier.

Par exemple, il est indispensable pour Skello que la fonctionnalité de login et les Users Stories qui en découlent soient toujours fonctionnelles.

Dans le cadre du Login, on peut imaginer 3 cas de tests en relation avec cette fonctionnalité :

  • Si j’essaye de me connecter en renseignant un identifiant mais en omettant le mot de passe, alors je ne suis pas en mesure de me connecter;
  • Si j’essaye de me connecter en renseignant un identifiant et un mot de passe mais que j’ai laissé une erreur dans l’identifiant, alors je ne suis pas en mesure de me connecter;
  • Si j’essaye de me connecter en renseignant la bonne association d’identifiant et de mot de passe, alors je suis en mesure de me connecter.

Aussi, d’autres cas de tests pertinents à automatiser sont ceux liés à des nouvelles fonctionnalités. Faire cela a permis de nous éviter d’être focalisé à tester uniquement pendant le développement puis de ne plus s’en préoccuper une fois la release effectuée. Le risque étant de ne pas constater une régression avant qu’elle soit remontée par quelqu’un d’autre (bien souvent le client 😅).

Pour préciser en quelques mots, voici les principaux éléments dont nous avons besoin pour se lancer dans l’automatisation:

  • Des scénarios et cas de tests que l’on sait incontournables à valider (c’est-à-dire les tests qui touchent au bon fonctionnement attendu par une feature);
  • De préférence, des tests dont la complexité et/ou la durée n’est pas trop conséquente pour éviter un test instable (les fameux “flaky” test 😠);
  • Savoir localiser des éléments sur une page web via le HTML, le CSS ou les XPATHS (avec une priorité accordée aux attributs uniques à un élément comme les ID ou les data-test)
  • Des connaissances sur quelques concepts basiques de programmation sont généralement recommandées (ou une grosse envie de monter en compétences là-dessus ! L’équipe QA est toujours prête à filer un coup de main et c’est normal de ne pas être à l’aise d’entrée 😉).

Choix de la stack

Il existe de nombreuses librairies en open-source pour faciliter l’écriture des scripts d’automatisation. Grossièrement, elles mettent à disposition des méthodes qui permettent d’interagir plus simplement avec une interface web via des fonctions pour cibler des éléments et réaliser des actions basiques comme un utilisateur (faire des cliques, pouvoir rentrer du texte ou déplacer la souris…).

Au sein de Skello, nous avons choisi la librairie WebDriverIO qui nous permet d’écrire nos tests en TypeScript. L’avantage est que nos tests restent également compréhensibles par l’équipe de développeurs. Nous avons aussi recours au framework Mocha qui est utile à la description des scénarios de tests.

Toujours dans un souci de clarté ☀️, nos tests sont structurés en respectant le Page Object Patern. Le Page Object est un design pattern où l’on va chercher à différencier chacune des pages que l’on souhaite tester sur notre application.

Illustrons ce modèle avec notre exemple sur Skello de la page de Login:

  • On va premièrement faire un fichier login.page.ts dans lequel on codera une classe où l’on indiquera tous les sélecteurs des éléments que l’on souhaites cibler ainsi que des méthodes qui retraceront des actions à effectuer. Ici, les sélecteurs correspondront aux champs où l’utilisateur doit renseigner son adresse mail et son mot de passe ainsi que le bouton pour valider la soumission. Dans les méthodes, on y décrira des actions comme le fait de taper ses identifiants puis de les valider à l’aide des sélecteurs préalablement établis.
  • *On héritera ensuite cette classe dans un autre fichier login.ts pour utiliser les méthodes données par Mocha et ***qui permettent d’organiser la User Story testée dans un block describe(). On y cherchera à retranscrire les cas de tests en usant les méthodes issues de login.page.ts puis de décrire le résultat attendu.

Pour résumer, le Page Object Patern apporte plusieurs avantages:

  • Il permet de facilement réutiliser des classes et des méthodes dans le cadre des tests;
  • Il permet de réduire la duplication du code entre les tests;
  • Le code est plus visible pour la prise en main de futurs développeurs;
  • Le code peut-être maintenu plus facilement en cas de modification de l’UI qui impacterait les sélecteurs définis dans les classes.

WebDriverIO donne aussi la possibilité d’effectuer des tests pour différents types de navigateurs (Chrome, Firefox et Safari) ainsi que pour des applications Desktop et Mobile. C’est un facteur qui a son importance pour Skello car nos clients utilisent ces navigateurs et que Skello possède une application SaaS, une application mobile et une application pour tablette (la Badgeuse).

Nous utilisons également une pipeline AWS pour la CI/CD qui lance l’intégralité des tests automatisés deux fois par jour afin de s’assurer qu’aucune régression n’a été introduite 🥷.

Prochaines étapes

Aujourd’hui, l’automatisation des tests reste à un stade modeste au sein de Skello. Nous avons ciblé quelques points afin d’aller encore plus loin:

  • Dans le cadre des scripts de tests, ce que l’on fait aujourd’hui nous permet de reproduire les actions que ferait un utilisateur dans Skello. Mais cela implique aussi que pour chaque chose que nous voulons simuler, nous sommes obligés de reproduire toutes les actions préalables telles que la connexion à l’application, cliquer sur le Planning, utiliser une fonctionnalité du Planning… Cela peut entraîner de la longueur dans l’exécution d’un test ainsi que le risque que le test échoue avant même d’arriver à l’étape que l’on souhaite tester. Une solution pour ce problème serait de mettre en place des appels aux endpoints adéquats des APIs de Skello et ainsi sauter ces étapes superflues.
  • Pour le moment, nous n’utilisons pas encore WebDriverIO à son plein potentiel dans la mesure où nos tests sont écrits uniquement pour l’application SaaS. Sur le court terme, nous allons commencer à faire des tests pour l’application mobile et l’application pour tablette.

Une chose est sûre en tout cas, l’utilisation des tests automatisés est amenée à continuer à s’accroître au sein de Skello. Plus nous parviendrons à gagner en compétences sur le sujet et plus la QA s’en verra renforcer.

Victor — QA Engineer — Skello Tech Team

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store