Dans le cadre de la mission qui fait l'objet de ce cas d'étude, notre objectif est d’optimiser et de maintenir toute la partie QA sur le projet d'un client, grand nom du secteur de l'assurance en pleine transformation digitale.

Le contexte

Dans ce contexte de transformation, notre objectif est multiple :

- Optimiser et maintenir toute la partie QA sur le projet de notre client qui vise la numérisation de la partie administrative et gestion, aussi bien pour les collectivités que pour les adhérents.

- Participer à la mise en place de nouveaux outils

- Améliorer les process

- Faciliter la formation des ingénieurs qualité internes dans la guilde de QA inter-projets 

Une stack process et technique est déjà en place pour la partie QA traditionnelle ainsi que pour l’automatisation. L’agilité se met en place petit à petit et les collaborateurs commencent à prendre leurs marques dans leurs rôles, mais les Sprints ne donnent pas encore tous naissance à des livrables opérationnels.

D'autre part, notre client héberge plusieurs projets dont la majorité communiquent et sont interdépendants. Cependant, les process, et notamment ceux qui régissent la communication, ne sont pas encore complétement finalisés.

Techniquement parlant, l'équipe front fait souvent appel à des web services maintenus par d’autres équipes.

Par exemple, pour afficher la liste des adhérents d’une collectivité, on peut appeler une API “Adhérents” qui fournira des données JSON pour être ensuite traitées par le front (via les frameworks React et Apollo) et affichées sous forme de tableau. Cette API externe est gérée par une autre équipe qui peut avoir une ou plusieurs API à sa charge.

Ces web services ne sont cependant pas toujours très ponctuels en terme de réponse à nos besoins, ni toujours très stables...

Il nous arrive également de laisser passer plusieurs sprints avant la livraison d’un web service qui, au final, ne correspondra pas complètement à l’expression de nos besoins et nous fera perdre un sprint supplémentaire pour adapter notre application front.

Analyse d’un point particulier

Afin de gagner du temps sur les sprints et d’avoir des livraisons cohérentes, la priorité est donnée au problème des dépendances inter-projets en collaboration avec la Dev Team, le PO, le Scrum Master, le QA Manager (Guilde QA), le coach Agile et le CTO.

Pour avancer les développements front sur nos sprints indépendamment des livraisons des web services de l’entreprise, nous devons, d'une part, demander, réviser et maintenir des contrats applicatifs entre le front et les web services et, d'autre part, être en mesure de simuler des données statiques cohérentes avec ce qui sera desservi par ces web services.

C'est donc dans le respect de ces principes que nous accompagnons notre client dans la mise en place des actions suivantes :

- Mise en place et maintien de contrats d’API de type Swagger.

- Etude de marché, POC et mise en place d’un premier serveur de Mock au sein de la feature team.

Les Mocks, c’est quoi ?

En anglais, 'to mock' signifie 'feindre' ou 'simuler'.

En production, une application front utilise les données (API) d’un ou plusieurs web services. Par exemple, si l'on souhaite afficher un tableau d’adhérents d’une collectivité, on appellera une API qui retournera une liste d’adhérents sous forme JSON qui sera à son tour traitée et affichée sous forme de tableau par l’application front de l’équipe.

Si l'on souhaite se débarrasser de la dépendance à la gestion de l’API externe, on peut 'mocker' cette API ou ses données. Il s'agit de créer ou d’utiliser notre propre système pour récupérer des données similaires à celles de l’API, mais d’une façon dont nous aurons le contrôle total.

Au lieu de passer par la 'vraie' API qui fournit les 'vraies' données, il s'agit donc de passer par un système alternatif qui fournira des données statiques ou dynamiques sensiblement identiques. Cela permet les développements front indépendamment des développements nécessaires de l’API en question. 

Cette technique, une fois les bases implémentées, peut ensuite être utilisée et remaniée autant de fois que nécessaire avec des besoins identiques ou différents.

Étude de marché et POC

Nous avons donc étudié l'offre du marché en terme de serveur de Mock, ainsi que les solutions alternatives faciles à mettre en place.

Des solutions comme Postman, MockServer, Wiremock, etc., bien qu’intéressantes pour leur facilité d’implémentation, ne couvrent cependant pas tous les besoins éventuels liés au contexte client :

- Données dynamiques en fonction de la requête du front

- Manipulation des données à un instant T

- Autres complexités algorithmiques (pour ne pas casser d’autres parties de l’application)

Afin d’anticiper toute complexité future et d’éventuels besoins métier, nous optons donc pour une solution un peu plus technique qu'une solution SaaS : la création d'un serveur Node/Express.

Dans un premier temps, nous faisons le choix d'une requête faite par le front afin de remplir un tableau de cotisations pour la 'mocker' via ce nouveau serveur. Il nous faudra ensuite trouver une façon de 'brancher' le front dessus au moyen d'une méthode d’activation et de désactivation sur les environnements de développement et d’homologation.

Mise en place de la solution

QA

Afin de mettre en place notre solution côté QA, nous avons suivi les étapes suivantes :

Dans un premier temps, l'utilisation d'une librairie appelée 'express-generator' nous a permis de générer rapidement un projet Node/Express.

Nous avons ensuite créé une 'route' reprenant la même syntaxe que celle de la requête des cotisations et retourné une liste d’objets stockés dans un fichier JSON.

Nous avons également créé des 'vues', autrement dit une interface web pour la manipulation CRUD (Create, Read, Update, Delete) des données.

Pour finir, nous avons travailler en collaboration avec l'équipe DevOps interne pour héberger, intégrer et déployer le projet en suivant exactement les mêmes méthodes que les projets de développement (applications front, APIs, …)

Dev

Côté Dev, un procédé d’activation du Mock lié à une variable globale appelée 'apiSource' a été créé. L'activation de cette variable se fait via le local storage.

Sur le composant concerné, l’algorithmique a été revu pour utiliser un hostname différent sur la requête en fonction de l’activation ou non du Mock : si apiSource=mock, on utilise le hostname du serveur de mock + le endpoint de la requêt. Sinon, on utilise le hostname de l’API métier + le endpoint de la requête.

Maintenance de la solution

La maintenance de la solution est réalisée par les QA. Cette équipe possèdait déjà de bonnes bases techniques grâce à leur activité d’automatisation que nous sommes venus consolider par une formation courte.

La solution est intégrée et déployée continuellement en suivant exactement les mêmes procédés (CI, CD, Ops) que les projets de développement.

Au cours de notre mission, nous avons maintenu et amélioré ce serveur sur trois versions :

1. La première version du POC décrite ci-dessus (3 jours de dev)

2. Une seconde version pour répondre au besoin de mocker des données de cotisations pour un nouveau système de cotisations est réalisée post-développement pour les tests limites (2 jours de dev) avec les évolutions suivantes :

- Nouvelle 'route'

- Utilisation d’un algorithme pour générer un grand volume de données en fonction des paramètres de la requête (pas de fichier de stockage de données)

3. Une troisième version est lancée en même temps que le développement d’une nouvelle feature liée au suivi des demandes réalisées en ligne. Cette version nous permet de développer le front en parallèle des web services et de tester tous les cas métier avant la livraison (2 jours de dev) avec les évolutions suivantes :

- Nouvelle 'route'

- Nouveau fichier de données

- Import/Export du fichier JSON de données pour les deux routes concernées

Bénéfices et conclusion

Avec ces implémentations, l’équipe est aujourd'hui autonome et capable de :

- Développer le front durant un Sprint indépendamment des autres équipes

- Tester des cas limites non pris en charge par les données métier actuelles

- Tester des cas qui nécessitent des modifications de données sans toucher aux 'vraies' données métier des systèmes applicatifs du client

Grâce à ce procédé et à diverses améliorations des process internes, les équipes de notre client sont aujourd’hui en mesure de fournir des livrables cohérents à la fin de chaque sprint !

------------------------------

Article rédigé par Adrian, Lead QA chez ESENS | Retrouvez tous nos articles sur le Blog ESENS

Vous êtes à la recherche d'un nouveau challenge ? Rejoignez l'équipe ESENS en postulant à nos offres d'emploi !