Comment améliorer la qualité de ses applications web quand on part de zéro ?

La démarche qualité consiste à s’assurer que le produit développé correspond bien aux objectifs que nous nous sommes fixés, sans bugs et en garantissant la meilleure expérience utilisateur possible.

Le monde des tests et de la qualité est vaste, et on a vite fait de s’y perdre… La liste des critères qualité à prendre en compte et des tests possibles n’en finit pas de s’allonger, et il n’est pas toujours aisé de savoir par quoi débuter : tests de bout en bout, tests d’intégration, tests d’API, etc.

Chez Ekwateur, après réflexion, nous avons décidé de commencer par automatiser les tests fonctionnels, dits aussi « de bout en bout » : ce sont les tests qui permettent de reproduire le comportement d’un utilisateur qui souscrit chez nous depuis son ordinateur (quel que soit son navigateur web préféré !). Cela nous a paru être le moyen le plus rapide pour tester le plus de cas de figure possibles, couvrir un large terrain, et donc de nous assurer que notre nouvelle application aurait le moins de bugs et de problèmes possibles une fois son développement terminé.

Une fois que l’on sait par quoi commencer, encore faut-il trouver la meilleure solution technique qui nous permettra d’atteindre l’objectif fixé. En matière de choix des outils, j’ai une politique assez simple, ils doivent (idéalement) répondre à ces trois critères :

Concrètement : je commence par identifier un outil qui répond aux attentes que nous avons définies, j’effectue ensuite une recherche pour trouver les alternatives possibles et, enfin, je compare les différentes solutions entre elles pour savoir laquelle répond le mieux aux points 2 et 3.

Dans les faits, pour m’assurer de la bonne qualité et du taux d’utilisation des outils présélectionnés, je lance des recherches (sur Google et Stackoverflow.com notamment). Le nombre de résultats trouvés est un bon indicateur : plus il est important, plus je suis assurée de pouvoir trouver facilement de l’aide en cas de besoin.

Après avoir effectué mes recherches, nous avons décidé de retenir Selenium et Cucumber via le langage de programmation Java. Pourquoi Java ? Parce que ce langage de programmation est couramment utilisé avec Selenium et qu’il est également connu de l’équipe.

Choisir des outils, c’est bien beau, mais ce n’est pas pour autant que l’on sait s’en servir, et encore moins que l’on sait s’en servir correctement !

Si je connaissais Selenium, un outil qui permet de simuler les clics d’un utilisateur sur une page web, je n’avais encore jamais utilisé Cucumber. À vrai dire, je n’avais même jamais entendu parler de BDD (Behavior Driven Development ou, en français, « développement dirigé par le comportement »), qui est le fondement même sur lequel se base Cucumber.

Pour celles et ceux qui, comme moi, ne connaissaient pas Cucumber et le BDD, le principe est assez simple. Il s’agit de décrire en « langage humain » (en français, par exemple) les différentes étapes du test, selon le schéma d’écriture suivant :

Étant donné que…

Quand…

Alors…

Dans le cas de notre parcours de souscription, on pourrait par exemple écrire ceci :

Étant donné que je suis sur la page https://ekwateur.fr/

Quand je clique sur « Mon espace client »

Alors j’arrive sur la page https://mon-espace.ekwateur.fr

Et on me demande mes identifiants de connexion

Ces différentes phrases sont ensuite traduites en code (langage machine), mais cette façon d’écrire les tests a l’avantage de permettre à toute personne parlant le langage humain choisi (chez nous, pour les tests, c’est l’anglais) de lire ces tests, de les comprendre et même, potentiellement, d’en écrire de nouveaux !

Le principe du BDD veut néanmoins (entre autres règles) que ces phrases en français soient écrites avant de créer l’application et qu’elles soient, en outre, rédigées par le « Product Owner » (c’est le chef de projet qui fait office de client interne).

Dans notre cas, l’application était déjà en cours de développement lorsque je suis arrivée. Écrire les scénarios de tests avant d’écrire le code de l’application n’était donc plus possible. En outre, les Product Owners comme les développeurs ignoraient tout du principe de BDD et du fonctionnement de Cucumber, et les former sur le sujet n’était pas à l’ordre du jour.

Qu’à cela ne tienne ! Il sera toujours possible de former tout le monde plus tard, une fois qu’un certain nombre de tests auront déjà été automatisés via Cucumber. J’ai toujours pensé que la clé du succès consiste à faire les choses petit à petit… et c’est donc petit à petit que j’ai décidé d’accompagner Ekwateur vers cette démarche de Behavior Driven Development.

Ça y est, les premiers tests Cucumber étaient lancés et automatisés ! Mais comment informer le reste de l’équipe de l’existence de ces tests et leur permettre de les utiliser au mieux ?

Le premier défi a été de communiquer sur les tests qui avaient déjà été réalisés. Mais demander à chacun de lire les tests afin de savoir ce qui avait été effectué ou non n’était pas une solution. Il nous fallait un process plus rapide, quelque chose qui permette de voir, au premier coup d’œil, si la fonctionnalité que l’on voulait avait bien été testée ou non.

La première solution qui m’est venue à l’esprit a été un tableau Excel, ou un simple document Word, pour répertorier les tests réalisés. Après tout, c’était ce que nous utilisions jusqu’à présent… Mais il n’est pas toujours facile de s’y retrouver dans un tel document, et c’est pourquoi cette solution, loin d’être optimale, a été abandonnée.

Après moult recherches, on m’a suggéré d’utiliser une « carte mentale », et c’est cette solution que nous avons retenue.

L’avantage d’utiliser une carte mentale, c’est que la représentation se fait de manière très visuelle et relativement synthétique, d’autant plus lorsque le logiciel utilisé permet de replier/déplier une branche afin de n’afficher que les informations nécessaires. En outre, la carte mentale permet d’obtenir facilement à la fois une vision globale et une vision plus détaillée (il suffit, pour cela, de lire les branches les plus éloignées du centre).

Permettre à tout le monde de savoir quels tests ont déjà été automatisés ou non est une première étape. Ensuite, il faut permettre à ceux qui en ont besoin d’utiliser ces tests, c’est-à-dire de pouvoir :

Pour que toute l’équipe puisse lire les tests Cucumber et les comprendre, j’ai organisé une présentation. J’ai également créé un « Dictionnaire des phrases Cucumber » pour le projet qui expliquait, pour chaque phrase, dans quels cas il fallait l’utiliser, quelles étaient les données d’entrées attendues et donner un exemple d’utilisation.

Une fois que cela a été fait, j’ai pu demander aux Product Owners d’écrire elles-mêmes les scénarios de tests pour les prochaines fonctionnalités qui allaient être développées. Charge à moi de vérifier ensuite les scénarios rédigés et de leur faire mes retours. Je m’assurais par exemple qu’une phrase nouvellement créée n’existait pas déjà sous une autre forme, que les phrases étaient bien utilisées comme elles étaient supposées l’être et que les scénarios de tests portaient bien sur l’aspect fonctionnel et non sur l’aspect graphique (c’est-à-dire : « un bouton est-il bien présent ? », et non pas « le bouton est-il bien rouge ? »).

À l’époque, nous n’avions pas encore mis en place l’intégration continue avec les tests qui nous aurait permis de vérifier automatiquement, après chaque mise à jour, qu’il n’y avait pas eu de régression (perte de fonctionnalités). Cela veut dire que les tests automatiques ne pouvaient être lancés que par moi, ce qui posait problème.

J’ai donc commencé par m’assurer que la commande pour lancer les tests était simple, puis j’ai écrit un guide pour expliquer comment lancer les tests en question. Face au nombre important de prérequis nécessaires pour lancer les tests (avoir un JDK, JRE, Maven et un driver Firefox/Chrome installé), il m’a tout de même fallu prendre un moment avec les Product Owners pour tout configurer avec elles et leur expliquer comment lancer les tests.

Et voilà précisément le point où nous en sommes aujourd’hui !

Qu’avons-nous prévu pour la suite ? Du BDD dans les règles de l’art ! Product Owners, développeurs et service Q&A (moi) rédigeant les tests mains dans la main ! Des tests codés avant même d’avoir ajouté la fonctionnalité !

Tout cela implémenté au sein d’une chaine d’intégration et de déploiement continue. Avec des tests unitaires (créés en utilisant la technique du « Test Driven Development »), des outils de contrôle de la qualité (tel que SonarQube), de la « documentation vivante » et pleins d’autres choses encore !

(Imaginez-vous une seconde un enfant dans un magasin de bonbons, et vous aurez une bonne idée de ce à quoi je ressemble quand je parle de ce futur hypothétique 😉).

« Des ids, s’il vous plait, donnez-moi des ids ! »

Ou comment bien expliquer ses besoins à l’équipe de développeurs ?

Pour pouvoir tester au mieux une application, il peut être parfois nécessaire d’en modifier le code-même.

Dans ce cas, c’est aux développeurs d’effectuer ces modifications. Les développeurs et les testeurs ont des objectifs parfois différents, c’est pourquoi il est important d’expliquer aux développeurs l’intérêt des modifications à apporter. Une bonne communication dans l’équipe est donc primordiale : dire « J’ai besoin d’id sur tous les éléments cliquables » n’est pas suffisant ! Je dois expliquer que ce dont j’ai vraiment besoin, c’est une manière unique, constante et fiable d’identifier un élément.

« Qui a (encore) cassé la qual¹ ? »

Ou les inconvénients de travailler sur un environnement instable

L’application que nous avons développée faisait appel à de nombreuses autres API internes. Mais ces API avaient chacune leur propre vie, évoluant au gré du temps et, parfois, elles cessaient de fonctionner comme attendu.

Ce qui avait le fâcheux effet de rendre l’application non-fonctionnelle pour mes tests dans l’interface de qual ! Logique : lorsque vous ne pouvez pas accéder à une page, il devient évidemment impossible d’automatiser les tests dessus… Pour réaliser les tests, il est important de pouvoir travailler sur un environnement stable. Alors pour permettre à chacun d’avancer en parallèle, notre solution a été de mettre en place plusieurs environnements de travail : un pour le développement, un pour les tests, etc.

« Ah bon, vous, ça fait une semaine que vous avez poussé ça en qual ? »

Ou le challenge de bien communiquer quand on intègre une équipe

Quand on débarque au sein d’une équipe, il est important de bien expliquer son rôle, surtout quand, en plus, il est très différent de tous les autres membres de l’équipe !

La solution, c’est de bien identifier ses besoins et d’arriver à les exprimer (clairement) aux autres.

Dans notre cas, pour la bonne transmission de l’information « Est-ce que cette fonctionnalité est en qual ? », il a suffi d’ajouter une colonne dans le tableau Agile entre celle de « en test dév » et celle de « validé ».

« Comment ça, ils ne sont pas clairs mes tickets ? »

Ou comment savoir quelles informations sont nécessaires aux autres quand tout nous paraît évident ?

Au tout début, lorsque je remontais un bug, j’indiquais simplement la page sur laquelle l’erreur était survenue, quelques informations utiles (de mon point de vue !) ainsi qu’une (très brève) description de l’erreur.

J’étais persuadée que c’était suffisant. Je pensais, en toute naïveté, que les autres membres de l’équipe avaient tous les données et connaissances nécessaires pour se rendre sur la page en question, par le même chemin que moi (ah bon, on peut se rendre sur cette page différemment ?) et qu’ils constateraient comme moi que « ça marche pas ». Je me trompais lourdement !

Se tromper n’est pas un problème. En revanche, se rendre compte longtemps après que les développeurs perdent du temps parce que vos tickets sont beaucoup trop vagues en est un.

Le problème ici était, encore une fois, la communication. On ne m’avait pas informée qu’il y avait un problème, et je n’avais même pas imaginé qu’il pouvait y en avoir un.

Si cette mésaventure peut apporter une leçon, ce serait celle-ci : il faut toujours s’assurer que l’autre comprend bien notre façon de communiquer. Si ce n’est pas le cas, alors il faut changer sa méthode de communication !

« Hein ? Chrome peut faire ça, mais pas Firefox ? »

Ou la joie du multi-plateforme

Vous avez écrit vos tests avant de les lancer sous Chrome. Tout fonctionne parfaitement bien et vous décidez de mettre en place le multi-plateforme qui vous permettra d’exécuter ces mêmes tests sous Firefox, Edge, etc. Impensable en effet que notre nouvelle application ne fonctionne pas correctement (et aussi bien que la version actuelle) sur tous les navigateurs web !

Vous vous êtes bien renseigné au préalable, vous avez fait toutes les modifications nécessaires… Plein de confiance, vous lancez l’un de vos tests. Et là, (mauvaise) surprise ! Il y a un comportement inattendu et le teste échoue.

Et oui, les commandes Selenium n’ont pas le même effet d’un driver à l’autre. Le « elementToBeClickable » de Firefox n’assure pas toujours que l’élément soit vraiment cliquable (par exemple, s’il est caché par un autre élément) et, alors que Chrome permet de récupérer les logs de la console Javascript, ce n’est pas le cas de Firefox.

C’est un point important à garder en tête pour rester vigilant et anticiper des difficultés !

¹ Dans notre jargon à nous, la « qual » est notre environnement de qualification.