Embed Size (px)
Citation preview
Amélioration d’un outil de reporting Patrick BINTCHA Master Informatique
Spécialité Infrastructures Applicatives et Génie Logiciel
2018 - 2019
Référent entreprise : Florian VANDENBULCKE
Référent université : Lionel SEINTURIER
2
Table des matières
Abréviations ....................................................................................................... 4
Glossaire ............................................................................................................ 5
Introduction ....................................................................................................... 6
Chapitre 1 L’encaissement et le reporting ......................................................... 7
1.1 Adéo Services .............................................................................................................. 7
1.2 ORION .......................................................................................................................... 7
1.2.1 L’encaissement en magasin ................................................................................. 7
1.2.2 Un peu d’histoire ................................................................................................. 8
1.2.3 Architecture globale............................................................................................. 8
1.3 Vers une nouvelle solution ........................................................................................ 10
1.3.1 ORION Report .................................................................................................... 11
1.3.2 VM ...................................................................................................................... 13
1.4 ORION Web Manager ................................................................................................ 13
1.4.1 Socle technologique ........................................................................................... 14
1.4.2 Fonctionnement ................................................................................................. 15
Chapitre 2 L’équipe ORION .............................................................................. 16
2.1 L’équipe avant la transformation : Un monde de silos ............................................. 16
2.2 L’équipe après la transformation : Vers de l’agilité .................................................. 17
2.3 Vers de la livraison continue ..................................................................................... 18
Chapitre 3 La Feature Team Satellites .............................................................. 19
3.1 Une Feature Team agile ............................................................................................ 19
3.2 Une Feature autonome de bout en bout… ou presque ............................................ 19
3.2.1 Planification ....................................................................................................... 19
3.2.2 Intégration continue .......................................................................................... 19
Chapitre 4 Rapport Suivi des bons d’achat ....................................................... 22
4.1 Les bons d’achat dans ORION ................................................................................... 22
4.2 Le rapport .................................................................................................................. 23
4.3 Choix technologiques ................................................................................................ 23
4.3.1 Spock, une autre façon de tester ....................................................................... 23
4.4 Mise en œuvre .......................................................................................................... 25
4.4.1 Web services REST ............................................................................................. 25
4.4.2 Tests unitaires des web services ........................................................................ 26
4.4.3 Affichage des sous rapports ............................................................................... 26
4.5 Résultats .................................................................................................................... 28
4.6 Indicateurs de validation ........................................................................................... 30
Chapitre 5 Rapport Bilan Caisse et Hôtesse ..................................................... 31
3
5.1 Le rapport .................................................................................................................. 31
5.2 Choix technologique .................................................................................................. 31
5.3 Mise en œuvre .......................................................................................................... 31
5.3.1 Analyse de l’existant .......................................................................................... 31
5.3.2 Une migration sans régression .......................................................................... 32
5.3.3 Une migration attentive..................................................................................... 32
5.3.4 Procédures stockées .......................................................................................... 33
5.4 Résultats .................................................................................................................... 33
Chapitre 6 Accompagner le changement ......................................................... 34
6.1 Une automatisation des tests fonctionnels .............................................................. 34
6.2 Choix technologiques ................................................................................................ 34
6.2.1 Selenium ............................................................................................................ 35
6.2.2 Geb, un Framework qui réunit le meilleur ........................................................ 36
6.3 Mise en œuvre .......................................................................................................... 37
6.3.1 Des tests fonctionnels structurés ...................................................................... 37
6.3.2 Gestion des Drivers ............................................................................................ 38
6.4 Résultats .................................................................................................................... 39
6.5 Perspectives d’évolution ........................................................................................... 40
6.5.1 Intégration continue .......................................................................................... 40
6.5.2 Industrialisation ................................................................................................. 40
Conclusion ....................................................................................................... 41
Références ....................................................................................................... 42
4
Abréviations
BdD Base de données
BDD Behavior Driven Development
BU Business Unit
OR ORION Report
OWM ORION Web Manager
5
Glossaire
Framework Ensemble d’outils servant de socle pour atteindre un but
précis.
ORION Solution d’encaissement utilisée par des enseignes
d’Adéo
ORION Report Outil de reporting en fin de vie
ORION Web Manager Solution de reporting et de paramétrage destinée pour
remplacer ORION Report
6
Introduction
De nos jours, le numérique fait désormais partie intégrante de notre quotidien et est
amené à se développer massivement dans les prochaines années. Un tel changement impose
aux entreprises à transformer leurs systèmes d’information avec pour objectif d’intégrer les
nouvelles technologies au sein de leurs activités. Pour ce faire, celles-ci font appel à des
sociétés de services qui vont leur fournir des prestataires pour les accompagner dans la
transformation digitale de différents axes de leurs métiers.
J’ai effectué mon stage de fin d’études au sein de SII, une entreprise de Services du
Numérique, partenaire technologique de nombreux grands comptes en France et à
l’International. J’ai rejoint plus précisément l’agence de Lille ayant plus de 130 collaborateurs.
L’agence constitue l’unité de base de l’organisation du groupe, elle offre une meilleure écoute
et un service de proximité aux clients locaux. Elle procure aussi les avantages d’une société à
taille humaine pour les collaborateurs.
Le stage s’est déroulé chez Adéo Services, client de SII, en pleine transformation
digitale de son système d’information. J’ai rejoint l’équipe ORION chargée de maintenir un
outil d’encaissement utilisé par différentes enseignes du groupe Adéo. Celle-ci entamait une
transformation agile de son organisation.
Durant ce stage, j’ai participé à l’évolution d’un outil de reporting. Cette évolution a
consisté en un développement de nouvelles fonctionnalités et à la réalisation de tests
fonctionnels automatisés.
7
Chapitre 1
L’encaissement et le reporting
1.1 Adéo Services
Adéo est un groupe mondial de la vente aux particuliers et professionnels de biens de
consommation dans les secteurs du bricolage, de l’outillage et de la décoration. L’entreprise
fédère plusieurs BU fonctionnant en autonomie et développant chacune une marque
enseigne propre.
Une BU (Business unit) représente une enseigne exerçant son activité dans un pays.
Le groupe est doté d’une entité possédant la même autonomie que celle des Business Unit.
Cette entité est Adéo Services, qui a pour mission de fournir différents services aux BU en
répondant à leurs besoins spécifiques et ainsi participer au développement de chacune
d’entre elles. Adéo Services va donc jouer le rôle de société de services des enseignes du
groupe. Celle-ci va regrouper les services IT et autres services internes dédiés aux BU. Les
équipes du service IT ont pour mission de maintenir, améliorer les différentes solutions
applicatives et fournir par la même un support utilisateur.
D’un point de vue organisationnel, Adéo services est composé de différentes communautés
couvrant différents périmètres métiers des enseignes du groupe. Ces communautés
regroupent des domaines et chacun des différents domaines se composent de produits.
1.2 ORION
1.2.1 L’encaissement en magasin
Pour pouvoir enregistrer les achats des clients, les magasins recourent à des caisses
enregistreuses qui sont des appareils capables de calculer, imprimer des reçus de paiement,
stocker des espèces et bien plus encore. A travers ces machines, les magasins peuvent ainsi
encaisser, c’est-à-dire percevoir les ventes sous divers moyens, que ce soit en espèces,
chèques ou carte bancaire.
Avec le développement des technologies de l’information, les caisses sont à présent capables
de bien plus dont notamment le stockage et le traitement des données.
Pour cela, les magasins se dotent de solutions d’encaissement faîtes sur mesure pour
répondre à leurs besoins métiers.
8
ORION est l’une de ces solutions d’encaissement utilisées par les enseignes de proximité et
décoration du groupe Adéo. Elle est aujourd’hui déployée chez 5 enseignes (Weldom,
Bricocenter, Bricoman, Zodio, Aki), dont 7 BU (Weldom France, Zodio France, Zodio Italie,
Bricocenter Italie, Bricoman Italie, Aki Espagne, Aki Portugal).
ORION couvre les périmètres fonctionnels de l’encaissement à la comptabilité magasin, en
passant par le reporting fonctionnel.
1.2.2 Un peu d’histoire
ORION est issu d’une stratégie d’entreprise des années 2000 nommée « ProgiMerlin » dont
l’objectif était pour Adéo Services de construire son propre système d’information à partir de
solutions du marché. Les sources étaient rachetées pour pouvoir être autonome sur les
développements nécessaires afin d’adapter ces solutions aux besoins du groupe et ainsi,
devenir à terme indépendant des éditeurs.
Faisant partie de cette stratégie, ORION est issu du rachat des sources de « BeanStore »,
solution d’encaissement développée en Java par la société britannique PCMS. BeanStore a
donc servi comme base à ORION et est encore à ce jour commercialisé sous le même nom.
Les deux solutions ayant évolué séparément, elles ne se ressemblent probablement plus
beaucoup de nos jours.
1.2.3 Architecture globale
ORION est caractérisé par les principaux éléments suivants.
1.2.3.1 Un logiciel sur chacune des caisses
Sur chacune des caisses physiques en magasin, est installé ORION « POS », l’application
utilisée par les caissiers ou caissières pour saisir les transactions de vente. Les caisses ont la
faculté de fonctionner en mode autonomie afin de pouvoir continuer à encaisser en cas de
coupure réseau. Pour cela, l’ensemble des données nécessaires à son fonctionnement
déconnecté est stocké dans une base de données locale. ORION POS regroupe un très grand
nombre de fonctionnalités couvrant le périmètre de l’encaissement. Dont notamment la
vente d’article, la gestion des retours, émission de bon d’achat/carte cadeau, les sorties
d’espèces ou encore la gestion client. La Figure 1.1 fournit un aperçu de cette application.
9
1.2.3.2 Un serveur d’encaissement par magasin
ORION est construit sur un modèle client-serveur. Les caisses à travers « POS »
communiquent avec le serveur « BeanStore Server ». BeanStore Server est une application
web qui fournit l’accès à POS aux données de référence telles que les produits et leurs prix,
ainsi que les transactions ventes réalisées dans le magasin. Il comprend aussi divers
composants internes aidant à la diffusion des données entre les caisses du magasin ou encore
au traitement des données.
1.2.3.3 Une plateforme
Plusieurs applications gravitent autour d’ORION et vont répondre à des besoins spécifiques
• Une application de paramétrage d’ORION et de gestion comptable du magasin
appelée VM (Vision Maintenance).
• ORION Report qui a pour but de faire du reporting sur le système d’encaissement.
• ORION Web Manager, outil ayant pour objectif de remplacer VM et Orion Report.
C’est sur cet outil que s’est consacré principalement mon stage. Il sera abordé plus
en détail par la suite.
Figure 1.1 - L'application ORION POS
10
ORION communique aussi avec des applications n’ayant pas pour périmètre l’encaissement
mais en lien avec celui-ci, tel que SCR qui est un référentiel pour la gestion client ou FidLight,
un référentiel pour la fidélité.
ci-dessous un schéma illustrant de manière simplifiée la solution d’encaissement ORION.
Figure 1.2 Architecture globale de ORION
1.3 Vers une nouvelle solution
ORION Web Manager est une application web périphérique à ORION dont l’objectif est de
regrouper les fonctionnalités de Reporting (ORION Report), de paramétrage et gestion
comptable présentes dans VM. Pour comprendre les raisons de l’établissement de cette
nouvelle solution, nous devons décrire en premier lieu les deux outils que sont ORION Report
et VM.
11
1.3.1 ORION Report
ORION Report est une application web dont le but est faire du reporting sur le système
d’encaissement. En d’autres termes, cette application fournit des résultats d’activité des
magasins utilisant ORION comme système d’encaissement. Ces résultats vont servir comme
source d’informations et d’outil d’aide à la décision. Ces données sont consultables sous
forme de rapports au format pdf. Il existe une dizaine de rapports différents, on y trouve
notamment des rapports opérationnels, rapports financiers et des rapports d’audit.
Figure 1.3 Exemple de rapport généré sur ORION Report
OR est développé en Java avec le framework GWT [1] depuis 2009. La particularité de ce
framework est de pouvoir transpiler du code Java en JavaScript (ainsi qu'en HTML et CSS),
permettant ainsi aux développeurs d'écrire des applications web en utilisant un langage
principal : Java.
Le choix d’utiliser GWT a été fait car la plupart des développeurs du service de l’époque n’était
pas spécialisés en technologies web mais en Java. Il était donc moins coûteux de partir sur un
langage déjà connu et maîtrisé par l’équipe.
GWT a été publié pour la première fois en 2006. Il a été créé pour aider les équipes de Google
à développer leurs applications web complexes. En 2006, les navigateurs web (et donc les
interpréteurs JavaScript) étaient loin d'être standardisés. La partie cliente était lente, boguée
et difficile à utiliser de façon fiable. Il y avait un manque presque total de bibliothèque de
qualité pour faire du développement web. Ainsi, pour pouvoir développer des applications
web à grande échelle, les ingénieurs de Google ont décidé de s'appuyer sur les compétences
et outils existants. Java était le langage le mieux adapté à leurs besoins, étant bien connu et
ayant un écosystème varié, GWT a donc ainsi vu le jour.
12
L'objectif de GWT était de masquer les différences entre les navigateurs, et d'encapsuler les
éléments nécessaires à la génération d'un code JavaScript efficace dans un « compilateur »
Java, laissant les développeurs libres de la tyrannie des spécificités des navigateurs web.
Aujourd’hui, ce n’est plus vraiment le cas, le Web à bien changé, les navigateurs ont convergé
vers des implémentations standard et beaucoup de bibliothèques de bonne qualité ont vu le
jour, comme Angular ou le langage Dart (créé pour remplacer Javascript) développé par
Google.
GWT est toujours maintenu à ce jour mais la fréquence d’apparition des nouvelles versions a
drastiquement chuté1, mettant ainsi en cause la pérennité de celui-ci. A cela s’ajoute le fait
que la plupart des composants permettant de faire fonctionner ORION Report sont très
endettés techniquement.
En plus d’avoir un retard technologique évident, son interface (voir Figure 1.4) n’est pas
adaptée à un usage web, ce qui rend ainsi son utilisation laborieuse.
Figure 1.4 Interface d'ORION Report
En raison de toutes ces difficultés, c’est ainsi qu’est né le projet de migrer les fonctionnalités
de ORION Report dans un nouvel outil : ORION Web Manager.
1 http://www.gwtproject.org/release-notes.html
13
1.3.2 VM
VM permet la gestion des utilisateurs (création, droits d’accès,), le paramétrage de la caisse
et la gestion comptable du magasin. C’est une application bureau écrite en Java. La raison de
son remplacement est dû à une remontée des utilisateurs se plaignant de son interface
vieillissante et difficile à prendre en main.
1.4 ORION Web Manager
Comme décrit précédemment, ORION Web Manager (OWM) est une application web
destinée à remplacer ORION Report et VM. Son évolution passe ainsi par un redéveloppement
des fonctionnalités existantes dans les précédents outils dont notamment les différents
rapports présents dans OR. L’idée aussi est de produire une interface plus moderne et
facilement utilisable pour chacune des fonctionnalités migrées.
OWM est composé d’un front s’occupant de l’interface web et d’une partie fourniture de
services nommée WSOWM.
WSOWM permet un accès par API aux données de la BdD du serveur d’encaissement magasin
ou d’autres applications périphériques à ORION.
Figure 1.5 OWM
14
1.4.1 Socle technologique
OWM est développé en Java et utilise le Framework Spring [2] comme socle applicatif. Spring
fournit un cadre solide à l’application et facilite l’utilisation des technologies standard JEE
telles que JPA, JDBC entre autres.
La librairie JQuery [3] est utilisé pour simplifier l’utilisation de Javascript dont notamment la
sélection et la manipulation d’éléments html ainsi que les appels Ajax.
En complément, un plugin de JQuery : JqGrid [4], est utilisé pour l’affichage dynamique de
tableaux dans une page web. JqGrid fournit une panoplie de primitives facilitant la génération
et la manipulation de tableaux dynamiques.
La récupération de données des différents rapports se fait en questionnant la base de
données ORION. Plus précisément en appelant des procédures stockées en base de données.
Une procédure stockée est un ensemble d’instructions SQL désignées par un nom enregistré
dans la base de données.
L’utilisation des procédures stockées procure de nombreux avantages dont :
• L’encapsulation de la logique métier dans des objets nommés. Au lieu d’avoir des
bouts de code SQL éparpillés dans le code client (c’était le cas dans ORION Report),
on peut centraliser ce code dans des objets spécifiques et les exécuter au besoin.
Cette approche favorise la production de code modulaire et donc facilement
maintenable.
• Les procédures stockées apportent de meilleures performances. Celles-ci sont
compilées et demeurent dans le cache de la base de données. Ainsi au lieu
d’envoyer une large suite d’instructions SQL du client à la BdD, on peut envoyer
qu’une seule commande indiquant l’exécution de la procédure qui à son tour
exécutera la suite d’instructions SQL. Cela évite ainsi une surcharge du trafic
réseau.
• En utilisant des procédures stockées, cela permet plus facilement au RUN (support)
d’intervenir à la suite d’un bug ou incident en production sur OWM. Prenons
l’exemple suivant : Une BU remonte un bug présent dans un rapport dans OWM.
Les équipes du RUN ayant les accès aux bases de données de production, ceux-ci
peuvent investiguer les requêtes (à travers les procédures stockées) et produire un
correctif (temporaire) rapidement en remplaçant la procédure erronée. Et cela
sans devoir attendre qu’une nouvelle version embarquant le correctif soit faite et
que celle-ci soit ensuite installée sur le serveur de production.
15
1.4.2 Fonctionnement
Prenons l’exemple suivant. Un utilisateur souhaite avoir le rapport financier du magasin sur
une période. Celui à travers l’interface d’OWM va sélectionner la période voulue, puis ensuite
cliquer pour générer le rapport avec les données voulues. Celui-ci peut consulter le rapport
directement sur la page web. En complément, il peut l’imprimer et l’exporter au format Excel.
Lorsqu’un utilisateur clique sur le bouton de génération d’un rapport, une requête
paramétrée est émise à WSOWM lui demandant d’appeler le service correspondant au
rapport demandé par l’utilisateur. Ce service va s’occuper d’appeler une procédure stockée
dans la base de données ORION. Cette procédure est chargée de récupérer les données
nécessaires au rapport. Une fois les données récupérées, celles-ci vont être transformées de
manière à pouvoir être affichées dynamiquement à l’aide de la librairie JqGrid. Le schéma ci-
dessous illustre ce fonctionnement.
Figure 1.6 Fonctionnement général d'OWM
16
Chapitre 2
L’équipe ORION
Adéo Services est en pleine transformation, cette transformation touche aussi le domaine
Paiement qui regroupe l’ensemble des solutions de paiement/encaissement du groupe.
L’équipe ORION faisant partie du domaine Paiement, elle a aussi subi une restructuration de
son organisation en se dirigeant vers de l’agilité.
2.1 L’équipe avant la transformation : Un monde de silos
Avant la transformation, l’équipe était organisée sous un modèle de cycle en V. Elle était
composée de différents pôles avec un rôle bien précis. Le Tableau 2.1 définit les
responsabilités de chacun des pôles.
Pôle Responsabilité
FONCTIONNEL(AMOA)
Récolter et analyser les besoins métiers
Rédiger les spécifications fonctionnelles
Tester les fonctionnalités avant la mise en production
DEVELOPPEMENT
Développer les fonctionnalités
Résoudre les bugs
Conception et chiffrage
INTEGRATION Paramétrer et installer les environnements ORION
Automatiser les processus de déploiement et packaging
RUN
Assurer la continuité du service en magasin
Suivre les incidents en production.
Assurer les déploiements en production.
Tableau 2.1 Responsabilités des pôles ORION
Les pôles ont été mis en place dans une optique d’utiliser au mieux les ressources en
regroupant les individus en fonction de leur spécialité et domaine d’expertise. Cependant,
une telle approche est source d’apparition de silos de compétences dans l’équipe. Comme on
peut le voir dans le Tableau 2.1, chaque pôle prend en charge une phase du cycle de vie du
projet. Par exemple, le pôle fonctionnel prend en charge l’analyse et la rédaction des
exigences fonctionnelles et les développeurs de réaliser le code remplissant ces exigences,
puis l’intégration s’occupera du packaging et ainsi de suite.
17
On peut observer que chaque étape se fait de façon séquentielle. Le temps qui s’écoule entre
chacune des phases varie ainsi proportionnellement à la taille du projet.
Un autre élément est que les équipes de chaque pôle n’interagissent pas forcément entre les
différentes phases. Par exemple, les compétences et le savoir-faire des équipes techniques
(Développement et Intégration) ne sont pas exploités durant la phase de rédaction des
exigences. Elément utile car l’AMOA n’a pas connaissance de la difficulté technique des
exigences émises. En incluant les développeurs durant la phase de définition du besoin,
l’AMOA a un feedback et peut fixer des exigences plus réalistes.
2.2 L’équipe après la transformation : Vers de l’agilité
L’équipe ORION a effectué un remaniement de son organisation. Cette restructuration a
abouti à la création de Feature Teams. L’objectif des Feature Teams est d’avoir des équipes
multifonctionnelles et autonomes sur un périmètre bien défini.
Par multifonctionnelle, on entend une équipe qui va regrouper toutes les compétences
nécessaires à la réalisation du produit, soit, du besoin à la mise en production. À la clé, une
équipe pluridisciplinaire et colocalisée pour une meilleure communication.
Figure 2.1 Organisation agile de l'équipe ORION
Comme on peut le voir sur la Figure 2.1, l’équipe ORION a été découpée en 4 Features
couvrant chacune un périmètre fonctionnel. Nous n’allons pas décrire chacune d’entre elles,
hormis la Feature Satellites, dans laquelle j’étais durant le stage. Celle-ci sera abordée en
18
détail dans le chapitre suivant qui lui est dédié. La Squad DevOps s’occupe de
l’industrialisation des processus de déploiements et packaging. Les guildes regroupent
différents acteurs transverses partageant un intérêt commun. Cette organisation à base de
Features Team, Squads, Guildes s’inspire du modèle utilisé et popularisé par Spotify2.
2.3 Vers de la livraison continue
La réorganisation de l’équipe vers l’agilité s’inscrit dans une démarche globale du domaine
Paiement qui est la réduction du temps de mise sur le marché ou Time to market. En plus
d’avoir une organisation agile, l’optimisation du Time to market implique une automatisation
des processus. Dont une automatisation des phases d’intégration, de tests et de déploiement.
À noter qu’une majorité de ces processus dans l’équipe implique une opération manuelle.
Processus pouvant être répétitifs et ainsi sujet aux erreurs. L’automatisation des processus
donnera l’opportunité à l’équipe de livrer plus fréquemment et donc d’avoir un feedback au
plus tôt des BU.
2 https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
19
Chapitre 3
La Feature Team Satellites
Durant le stage, j’étais dans la feature Satellites. Elle a pour périmètre de maintenir et faire
évoluer les briques applicatives gravitant autour D’ORION. En effet, comparé aux autres
Features Team, Satellites n’intervient pas directement sur le système encaissement ORION
mais sur des applications communiquant avec ORION. Elle prend notamment en charge
OWM.
3.1 Une Feature Team agile
Comme chacune des Features Team d’ORION, Satellites a appliqué Scrumban qui est une
combinaison de Scrum et Kanban.
Scrum fournit une boîte à outils aidant les équipes à adopter une mentalité agile.
Kanban est utilisé pour faire du management visuel.
L’application des rituels agiles s’est faite de façon progressive dans l’équipe.
3.2 Une Feature autonome de bout en bout… ou presque
3.2.1 Planification
Pour la planification de nos sprints, nous utilisons l’outil Jira3 mis à disposition par Adéo
Services pour l’ensemble des équipes. Cet outil est adapté à nos usages car il permet à
l’ensemble de l’équipe de suivre l’état d’avancement (à travers des tableaux personnalisés)
sur le sprint. En plus de Jira, nous utilisions un tableau Kanban physique. L’avantage d’un
tableau physique est qu’il fournit une visibilité constante sur ce qui reste à faire et amène un
côté coloré et fun. De plus, il nous sert de lieu de discussion et de réflexion lors des Daily
Meeting.
3.2.2 Intégration continue
3.2.2.1 Git
Pour versionner nos sources, nous utilisons Git et la plateforme Gitlab. Pour mieux collaborer
entre développeurs sur Git, nous utilisons une approche s’inspirant de GitFlow4. Bien sûr,
3 https://www.atlassian.com/fr/software/jira 4 https://nvie.com/posts/a-successful-git-branching-model/
20
nous nous efforçons d’appliquer les bonnes pratiques d’utilisation de Git telles que des
messages de commits clairs ou encore le nommage des branches avec l’identifiant du ticket
créé sur Jira de manière à avoir un historique Git pertinent.
3.2.2.2 Revue de code
Lorsqu’un développeur termine le développement d’une fonctionnalité ou la résolution d’un
bug, nous effectuons des revues de code entre développeurs. Un tel processus nous permet :
d’assurer la lisibilité du code produit, de détecter et corriger le code pouvant causer des bugs.
Les séances de revue de code sont aussi un moyen de passage de connaissances entre
l’équipe.
Cependant, c’est un exercice qui peut être délicat. En effet, un commentaire sur le code peut
être interprété comme une critique personnelle. Pour cela, l’équipe doit encourager une
culture de partage de code et d’amélioration continue. Aussi, privilégier la communication en
face en face pour notamment éviter tout malentendu.
Etant une Feature Team composée de jeunes développeurs, il est possible que nous n’ayons
pas le recul suffisant sur le code audité et ses implications. Sur cet aspect, l’intervention d’un
Tech Lead serait un élément bienvenu dans l’amélioration de nos revues de code.
3.2.2.3 Outils
Jenkins est l’élément central de notre chaine d’intégration continue. Il permet de fabriquer
en continu les livrables de OWM. SonarQube est utilisé pour mesurer la qualité de code de
OWM. Il nous permet d’avoir un retour sur les éléments à revoir sur le code, et surtout d’avoir
une évaluation de la dette technique.
Pour créer les livrables, Jenkins va procéder comme suit :
a) Récupération des sources sur Gitlab
b) Compilation des sources du projet avec Maven qui lancera aussi les jeux de tests
unitaires et d’intégration. Cette phase va aboutir à la génération d’un fichier WAR5 qui
pourra être déployé sur un serveur d’application Tomcat.
c) Vient ensuite la phase de génération des livrables qui se fait par BU. Ayant 8 BU à
notre charge, nous aurons ainsi 8 livrables séparés. Le but d’avoir des livrables séparés
est de pouvoir apporter des modifications spécifiques à chaque BU.
Les livrables générés sont des archives RPM6. Ces archives vont contenir les fichiers
nécessaires (fichiers WAR, fichiers de configuration, fichiers spécifiques à une BU, …) à
l’exécution du programme dans un environnement donné.
5 https://fr.wikipedia.org/wiki/WAR_(format_de_fichier) 6 https://fr.wikipedia.org/wiki/RPM_Package_Manager
21
3.2.2.4 Mise à disposition aux utilisateurs
Avant la mise en production, on va déployer dans un premier temps cette version dans un
environnement KU (Key Users). Sur cet environnement, la BU va pouvoir tester OWM et
vérifier que tout fonctionne correctement. On peut noter que ce type d’environnement est
une sorte de préproduction. Et c’est uniquement après validation des tests en environnement
KU que la mise en production pourra être faite.
Les mises en production sont prises en charge par le RUN.
3.2.2.5 Release en fin de Sprint
A la fin de chaque sprint, on réalise un incrément de la version actuelle d’OWM. L’objectif
c’est d’embarquer les fonctionnalités développées durant le sprint et de toujours avoir une
version potentiellement délivrable à mettre à disposition.
3.2.2.6 Tests fonctionnels
Les tests fonctionnels d’OWM sont fait manuellement. C’est un processus long notamment
dû aux tests de non-régression à effectuer. Les tests de non-régression sont nécessaires pour
s’assurer que des fonctionnalités précédemment implémentées n’aient pas de bug qui aurait
intégré par l’ajout de nouvelles fonctionnalités.
Pour cela, une automatisation des tests fonctionnels permettrait de gagner du temps à
l’équipe sur ces phases de tests. Une solution à cet égard est décrite dans le Chapitre 6.
22
Chapitre 4
Rapport Suivi des bons d’achat
Pour fidéliser leur clientèle, les magasins utilisent différents dispositifs. L’un de ces dispositifs
est de mettre en place des moyens de paiement supplémentaires tels que les bons d’achat et
les cartes cadeaux.
4.1 Les bons d’achat dans ORION
En plus des moyens de paiement habituels (espèces, carte bancaire,), ORION permet
l’encaissement d’un article en utilisant d’autres moyens de paiement tels que les bons
d’achat, cartes cadeaux ou encore acomptes7.
De manière générale, les différentes transactions effectuées sont stockées dans le serveur
d’encaissement du magasin.
Cependant, pour les transactions ayant pour moyens de paiement des bons ou cartes
cadeaux, celles-ci sont stockées en plus dans une brique qu’on appelle Support Paiement.
Support Paiement est une application permettant le stockage des données de paiements
dématérialisés. On y retrouve les bons d’achat, les cartes cadeaux ou encore les acomptes.
Comme illustré sur la Figure 4.1, Support Paiement est installée sur un serveur centralisé
auquel tous les serveurs de chaque magasin ont accès. C’est ainsi qu’un client peut utiliser un
bon d’achat obtenu dans un magasin et l’utiliser dans un magasin autre que celui l’ayant émis.
Figure 4.1 Communication entre Orion et Support Paiement
7 https://fr.wikipedia.org/wiki/Acompte
23
4.2 Le rapport
Le premier rapport que j’ai migré de ORION Report à OWM est le rapport de suivi des bons
d’achat. D’un point de vue métier, ce rapport est utilisé par la comptabilité et permet d’avoir
un état des lieux des bons d’achat sur une période donnée.
Ce rapport est constitué de différents sous rapports :
- Vue détaillée : Affiche les bons d’achats avec leurs informations détaillées (date
d’expiration, montant,).
- Vue par opérateur : Affichage du nombre de bons créés dans la période sélectionnée
par opérateur.
- Vue par état : Affichage des types de bons par état.
L’objectif étant de retrouver l’ensemble des fonctionnalités de ce rapport dans OWM tout en
apportant une interface remaniée améliorant l’expérience utilisateur.
4.3 Choix technologiques
Le développement de ce rapport s’est reposé sur le socle technologique de OWM. Une partie
a consisté au développement de services web et l’autre à l’affichage des tableaux avec le
plugin JQuery, JqGrid.
En complément, j’ai initié une démarche de réalisations de tests unitaires avec pour objectif
d’assurer la validité des différents web services développés.
Outre l’habituel JUnit utilisé pour l’écriture de tests en Java, le Framework de tests Spock a
été choisi pour cette tâche. Passons en revue les éléments qui ont orienté mon choix d’utiliser
Spock.
4.3.1 Spock, une autre façon de tester
Spock [5] est un Framework de tests permettant de tester du code Java (et Groovy). Les tests
Spock sont écrits en Groovy mais servent à tester aussi bien du code Java et Groovy. Spock
amène de nouvelles idées facilitant l’écriture des tests concis, lisibles et donc facilement
maintenables.
4.3.1.1 Un Framework favorisant la collaboration
Spock adopte le paradigme Behavior-Driven Development (BDD), un processus agile de
développement encourageant la collaboration entre les développeurs, Business Analyst (BA)
et autres intervenants métiers participant à un projet. Et cela en promouvant un vocabulaire
spécifique permettant de documenter les spécifications fonctionnelles et les critères de
validation de celles-ci. Spock embrasse ce modèle et en fait son socle.
24
def "A client should have a bonus if he spends more than 100 euros"() {
given: "A client and credit card billing"
def client = new Client();
def billing = new CreditCardBilling();
when: "a client buys something with at least 100"
billing.chargeClient(client,170);
then: "Client should have the bonus option active"
client.hasBonus() == true
}
Figure 4.2 Exemple de code8 écrit avec Spock
Comme on peut le voir dans l’extrait de code ci-dessus, les tests ont une structure à base de
Given/When/Then s’inspirant du BDD. Ces blocs permettent de structurer nos tests en isolant
les différentes phases de déroulement du test. Il suffit de lire le commentaire associé à chaque
bloc pour comprendre ce que le test effectue.
On peut noter aussi le fait qu’on peut nommer les méthodes de tests à base de phrases
complètes. Les développeurs ne sont plus ainsi limités par une convention de nommage Java
et peuvent décrire le plus clairement possible le test. En conséquence, on se retrouve avec
un code auto-documenté.
4.3.1.2 Facilité de débogage
Trouver la cause de l’échec d’un test peut parfois être complexe, impliquant du temps de
débogage. Lorsqu’un test échoue, Spock ne va pas juste afficher un message d’erreur avec les
résultats finaux ne correspondant pas. On aura en plus un aperçu des résultats intermédiaires
de manière à mieux comprendre le contexte global.
Figure 4.3 Exemple de message d'erreur affiché par Spock
8 Source : https://github.com/kkapelon/java-testing-with-spock
25
4.3.1.3 Framework de mock inclus
En programmation orienté objet, le fait que deux objets fonctionnent correctement
individuellement ne signifie pas que ceux-ci fonctionneront également lorsqu'ils sont
connectés l'un à l'autre. L’inverse est également vrai.
La conséquence est que tester un logiciel va consister en général à couvrir deux couches
principales dont : la couche d’intégration où les tests vont vérifier le système dans son
ensemble (tests d’intégration) et la couche unitaire où les tests vont vérifier qu’une classe
isolée du reste du système fonctionne correctement.
Pour vérifier le fonctionnement d’une seule classe et l’isoler du reste du système, on a besoin
d’un environnement contrôlé. En outre, on va se concentrer sur une classe et supposer que
le reste du système fonctionne correctement. La raison d’une telle approche est que tester
une classe avec l’ensemble du système est difficile car lorsqu’un bug apparait, il n’est pas
évident de déterminer si celui-ci a pour cause la classe testée ou l’environnement en lui-
même.
Pour cela, un Framework de mocks [6] est nécessaire pour fausser ou simuler le reste du
système et n’avoir que la classe testée à être authentique.
JUnit ne gère pas les mocks, on doit donc utiliser une librairie externe spécialisée tel que
Mockito, ou encore PowerMock.
A l’inverse, Spock est inclus avec son propre Framework de mock.
4.4 Mise en œuvre
4.4.1 Web services REST
La première étape a été d’analyser le fonctionnement du web service SOAP [7] de Support
Paiement. Ce type de web service fait usage de XML, qui est le format des messages échangés
entre le consommateur et le fournisseur de web services.
Pour pouvoir consommer un service web, l’on a besoin de son WSDL qui fournit une
description et les informations nécessaires à l’invocation de ce service au format XML.
Le WSDL est une importance capitale car son contenu va servir à la génération des classes
requises pour consommer le web service. Le code généré va masquer les détails du protocole
utilisé et des message échangés. Le développeur va pouvoir ainsi implémenter la
consommation du web service avec des classes Java et donc sans devoir s’occuper de créer
manuellement le XML correspondant aux échanges.
26
L’étape suivante est le développement de web services REST dans WSOWM. Ces web services
REST ont pour but de consommer les web services SOAP de Support Paiement. Ensuite vient
une phase de transformation des données récupérées pour n’avoir que les données
nécessaires à l’affichage des vues du rapport.
4.4.2 Tests unitaires des web services
Chacun des web services REST développés pour les sous rapports ont été testés unitairement
avec Spock. La communication avec le web service SOAP de Support paiement a été mocké
de manière à ne tester que le code métier des web services. La partie « mocking » s’est
appuyé sur les primitives fournies par Spock permettant de mocker des dépendances
externes avec simplicité. En plus d’apporter de la qualité, ces tests unitaires jouent aussi un
rôle de documentation interne au code, et permet aux développeurs qui prendront le relai de
saisir rapidement ce qui était attendu au moment du développement précédent.
4.4.3 Affichage des sous rapports
Les web services REST étant à disposition dans WSOWM, la phase suivante sera de
consommer ces services pour afficher les données dans des tableaux. Pour ce faire, la librairie
JQuery et ces primitives d’appels Ajax est utilisée. Le plugin JqGrid intervient pour la
manipulation des tableaux.
Une attention a été portée à ce que l’interface soit la plus simple d’utilisation possible. On
peut l’illustrer avec le scénario suivant :
Un utilisateur souhaite avoir le récapitulatif des bons d’achat de type « Manuel » (c’est-à-dire
créé spontanément par un opérateur sur la caisse) qui ont expirés sur une période.
Dans Orion Report, cela impliquera les étapes suivantes :
1) Sélectionner la période
2) Sélectionner le type « Manuel »
3) Sélectionner le statut « Expiré »
4) Générer le rapport
Si celui-ci souhaite ensuite avoir les bons d’achat « Retour » utilisés dans la période, il devra
refaire une recherche avec le type et statut correspondant, puis regénérer le rapport.
27
Figure 4.4 Mécanisme de recherche pour le rapport SBA dans ORION Report
Dans OWM, cette phase a été simplifiée. En reprenant le scénario précédent on aura :
1) Sélectionner la période
2) Générer le rapport
Et ensuite l’utilisateur peut filtrer au besoin les données qu’il souhaite garder comme décrit
dans les captures ci-dessous.
Figure 4.5 Aperçu du mécanisme de filtrage des données
28
Figure 4.6 Après que le filtre est appliqué
4.5 Résultats
Ci-dessous un aperçu de chacun des sous rapports développés.
Sous-rapport Détaillé
Figure 4.7 Aperçu du sous-rapport détaillé
29
Sous-rapport par Opérateur
Figure 4.8 Aperçu du sous-rapport par opérateur
Sous-rapport par Etat
Figure 4.9 Aperçu du sous-rapport par Etat
Recherche d’un bon d’achat
Figure 4.10 Aperçu de la recherche de bon d'achat
30
4.6 Indicateurs de validation
Ce rapport a pu être testé et validé en recette interne d’une BU italienne. Celui-ci a été
embarqué dans une nouvelle version d’OWM. Une démonstration a été faite à la BU Weldom
pour leur donner un aperçu de ce rapport. Les retours de la BU Weldom ont été positifs. En
effet, ils ont émis une demande de mise à disposition de ce rapport.
31
Chapitre 5
Rapport Bilan Caisse et Hôtesse
5.1 Le rapport
Le rapport bilan caisse et hôtesse a pour but de récapituler les informations nécessaires au
traitement des caisses. Il fournit des données chiffrées permettant l’analyse des transactions
effectuées et des moyens de paiements utilisés. Les données sont récupérées dans la base
données ORION. Il peut être généré pour l’ensemble du magasin ou pour un opérateur donné.
Comme les différents rapports, il est généré sur une période donnée.
Il est composé de plusieurs sections :
- Montant par transactions : Cette section regroupe les différents types de transactions
réalisées associées à leurs montants.
- Chiffre d’affaire : Affiche le chiffre d’affaire réalisé.
- Montants par moyens de paiements : Affiche les différents types moyens de paiement
associés aux montants des transactions réalisées avec ceux-ci.
- Liste des articles services : Affiche le récapitulatif des services fournis par le magasin
(par exemple une livraison à domicile).
5.2 Choix technologique
Les données de ce rapport étant stockées dans la BdD ORION, le mécanisme de récupération
se fait à l’aide de procédures stockées. PostgreSQL est le moteur de gestion de la base de
données. En conséquence, le langage procédural PL/pgSQL est utilisé pour écrire ces
procédures.
5.3 Mise en œuvre
5.3.1 Analyse de l’existant
Avant d’entamer le développement en lui-même, la première phase a été d’effectuer une
analyse du rapport.
L’objectif est de comprendre les différentes sections du rapport, dont les apports
fonctionnels, le pourquoi de ces sections de manière à ne pas passer à côté de certains détails.
32
ORION Report est un outil ancien, certaines informations telles que des spécifications
détaillées sont difficiles à trouver. Pour cela, je m’appuie sur mon équipe Satellites pour la
récupération d’informations fonctionnelles sur le rapport. Lorsqu’il n’est pas possible d’avoir
ces informations à travers l’équipe, la démarche ici consiste à analyser le code d’ORION
Report et de déceler la logique fonctionnelle du rapport.
5.3.2 Une migration sans régression
Puisqu’il s’agit d’un redéveloppement du rapport (existant dans OR) dans OWM, l’un des
points à prendre en compte est de ne pas introduire de régressions. En d’autres termes,
l’utilisateur doit pouvoir retrouver les mêmes fonctionnalités qu’il avait dans ORION Report
dans OWM.
Cela implique une vigilance accrue durant les développements. Le développement passe donc
par une phase de compréhension du code existant de ORION Report, phase très complexe dû
à l’aspect « legacy » de l’application. Le code de celui-ci étant très rarement documenté, cette
phase est d’autant plus compliquée.
Cependant, une démarche consistant à analyser l’historique SVN (utilisé pour versionner les
sources) de ORION Report permet de faire un bond dans le passé et fournir de nouvelles pistes
pour comprendre le code.
En outre, lorsqu’un point de blocage apparait dû à une incompréhension du code, la
démarche consiste à regarder les commits du périmètre du code en question. À travers ces
commits, on peut retrouver à quel ticket il correspond et ainsi s’en référer pour en savoir plus.
On peut aussi retrouver l’auteur du commit et si cette personne est toujours dans l’équipe,
s’en référer à elle dans le but de collecter des informations qui pourront servir au déblocage.
Les commits s’ils sont lisibles peuvent aussi servir à comprendre les changements effectués
dans le code.
Cela montre l’importance d’utiliser des gestionnaires de version et de maintenir un historique
lisible durant le développement d’un produit.
5.3.3 Une migration attentive
Un redéveloppement implique aussi d’analyser la cohérence de l’existant. L’objectif étant de
ne pas faire de suppositions sur l’exactitude avéré de ORION Report mais plutôt d’être dans
une approche de compréhension et vérification de l’existant. Il faut donc s’assurer de ne pas
introduire de nouveaux bugs et aussi de ne pas laisser ceux existants qui n’auraient pas été
identifiés, se retrouver dans OWM.
33
5.3.4 Procédures stockées
Pour l’affichage de chacune des sections du rapport, des procédures stockées ont été
développées. L’objectif est d’avoir pour chacune des sections une procédure globale
renvoyant les données nécessaires à leur affichage. La Figure 1.6 illustre le fonctionnement
global du rapport.
Pour récupérer les données des différentes sections du rapport, j’ai dû manipulé différentes
tables de la BdD ORION, appliquer différentes jointures, filtres. Ecrire de telles requêtes
requiert une compréhension du schéma de données. La BdD ORION étant relativement large
cette étape n’est pas la plus évidente.
Une démarche portant à mettre à disposition les rapports d’OWM aux BU ukrainiennes et
roumaines a été initiée au début du lancement des Features Team. Cependant les BU
ukrainiennes et roumaines sont basées sur un modèle de données qui diffère sur certains
points par rapport à d’autres BU.
Pour ce rapport, il a donc fallu mettre en place des procédures stockées spécifiques à ces BU.
5.4 Résultats
Ci-dessous un aperçu de ce rapport avec les sections développées.
Figure 5.1 Aperçu du rapport Bilan caisse et hôtesse
Le développement de ce rapport n’a pas pu être terminé dans son ensemble. Il reste une
section à développer.
34
Chapitre 6
Accompagner le changement
Dans une démarche d’améliorer notre time-to-market, nous avons remarqué que l’un des
processus qui demandait beaucoup de temps était les tests de non-régression. Ces tests sont
effectués manuellement. En ce sens, j’ai mis en place une solution qui nous aiderait sur ce
point.
6.1 Une automatisation des tests fonctionnels
Pour réduire le coût de réalisation des tests manuels, une solution consiste à les automatiser,
notamment avec des tests unitaires. Cependant, les tests unitaires ne permettent de vérifier
qu’une partie du code (classes, méthodes, …) isolé du reste du système avec notamment
l’utilisation de mocks.
L’avantage des tests unitaires c’est qu’ils sont faciles à écrire et s’exécutent rapidement. Or
ce que l’on recherche dans notre cas, c’est de pouvoir tester l’application, tel un utilisateur
réel le ferait.
Dans le cas d’une application comme OWM, cela impliquerait de pouvoir émuler dans nos
tests, les interactions de l’utilisateur avec l’interface.
Ce type de tests se nomme tests fonctionnels (ou tests de bout en bout) automatisés. Ils ont
l’avantage de vérifier toute la chaine nécessaire au fonctionnement de l’application. Ici,
l’application est testée dans un environnement similaire à celui en production. Ce type de
tests sont d’autant plus intéressants pour OWM quand on a connaissance de son utilisation
des procédures stockées. Les procédures stockées sont difficiles à tester unitairement car
elles dépendent fortement de leur environnement (ici la base de données). Environnement
qu’on essaye en général de simuler. En effectuant des tests fonctionnels automatisés, on
teste par la même occasion les procédures stockées associées.
6.2 Choix technologiques
OWM étant une application web, les solutions recherchées devront être des outils capables
d’émuler les interactions d’un utilisateur sur une page web dans un navigateur. En d’autres
termes, cet outil qui nous servira comme socle à la réalisation de nos tests, devra être capable
de lancer un navigateur web, aller sur OWM, se connecter, cliquer ou survoler des boutons
d’une page, etc.
35
6.2.1 Selenium
Il existe différentes solutions permettant l’automatisation de tests fonctionnels d’applications
web. Le Framework open source Selenium [8] a été choisi pour être le socle de nos tests
automatisés de bout en bout.
Contrairement aux différents outils disponibles sur le marché des Frameworks de tests
fonctionnels, Selenium est celui qui offre la meilleure compatibilité avec les navigateurs.
Selenium fonctionne avec la plupart des navigateurs9. Selenium doit cette forte compatibilité
grâce au WebDriver.
Figure 6.1 Architecture de Selenium WebDriver
Comme illustré sur la Figure 6.1, un Client Selenium correspond au framework qui sera utilisé
par les développeurs pour écrire le code de leurs tests. Selenium fournit un framework par
défaut qui est en Java. Cela dit, il en existe dans d’autres langages10 rendant son utilisation
universelle.
Chaque navigateur web possède un Driver spécifique. Ce Driver est une implémentation d’un
protocole de communication standardisée11. Ainsi lorsqu’ un Driver reçoit des commandes
d’un client Selenium, celui-ci va traduire ces commandes qui seront ensuite envoyées au
navigateur.
9 https://www.seleniumhq.org/about/platforms.jsp#browsers 10 https://www.seleniumhq.org/about/platforms.jsp#programming-languages 11 https://www.w3.org/TR/webdriver/
36
Selenium, c’est aussi une solution mature avec une très large communauté, élément
important lorsqu’on souhaite se former sur une technologie car la recherche d’informations
est d’autant plus facile.
6.2.2 Geb, un Framework qui réunit le meilleur
Comme décrit dans la section précédente, il est possible d’utiliser d’autres Framework que
celui fourni par défaut qui est en Java. Cependant, mon choix ne s’est pas orienté vers le
Framework par défaut mais vers Geb [9], un Framework Groovy. Les éléments qui ont pesé
dans le choix d’utiliser Geb sont décrits dans les sections suivantes.
6.2.2.1 Intégration simplifiée dans notre écosystème
Groovy étant un langage de la JVM12, celui-ci s’intègre sans effort dans un écosystème Java
comme le nôtre. On peut ainsi réutiliser nos outils de build comme Maven ou notre IDE qu’on
utilise pour Java. De quoi minimiser le coût de l’apprentissage de ce Framework comparé au
fait de prendre un Framework utilisant un autre langage (hors JVM) et donc un écosystème
différent.
6.2.2.2 Une API simplifiée
Geb fournit une API simplifiant la sélection d’éléments d’une page web. De même il est aisé
d’itérer à travers le contenu des pages. Geb s’inspire fortement des sélecteurs JQuery au
niveau de sa syntaxe.
6.2.2.3 Support du patron de conception Page Object
Réaliser des tests fonctionnels implique du code en plus à maintenir et à faire évoluer. Pour
cela, nous devons décider des approches à avoir pour structurer notre base de code de tests
en vue de rendre celle-ci maintenable. Dans cette optique, Geb promeut une approche dans
la façon d’organiser le code. Celle-ci se nomme « Page Object Model ».
Le POM [10] (Page Object Model) est un patron de conception ayant pour objectif de réduire
les duplications de code lors de la réalisation de tests fonctionnels automatisés.
Ce patron de conception recommande de regrouper dans une classe l’ensemble des éléments
d’une page et les interactions (clic, survol,) possibles sur celle-ci. L’objectif est que cette classe
serve par la suite d’interface pour communiquer avec la page dans un test donné.
12 Java Virtual Machine ou Machine Virtuelle Java
37
Par exemple, si dans plusieurs tests différents, on effectue la même action de cliquer sur un
bouton d’une page.
Sans utiliser de POM, cela impliquerait de dupliquer le code de l’action dans chaque test.
On peut au contraire encapsuler le code décrivant l’action dans une méthode d’une classe
(qui représente notre page) et l’utiliser dans chacun des tests. Cette approche a deux
avantages : d’une part on réduit la duplication de code et d’autre part, dans le cas échéant où
l’interface d’une page venait à changer, alors on aurait qu’un seul endroit (la méthode
contenant le code l’action) dans le code pour effectuer nos modifications. On obtient donc
ainsi un code facilement maintenable.
De plus, Geb fournit des primitives13 14 facilitant l’adoption de cette approche.
6.2.2.4 Une intégration simplifiée avec Spock
Geb s’appuyant sur le langage Groovy, son intégration avec Spock se fait sans effort. On peut
donc ainsi combiner la puissance de Spock décrit ci-dessus à celle de Geb dans le but de
réaliser des tests fonctionnels automatisés concis, lisibles et faciles à maintenir.
6.3 Mise en œuvre
6.3.1 Des tests fonctionnels structurés
Tout au long du développement des tests, une approche consistant à organiser les tests de
manière à être maintenables a été adoptée. Pour cela, le patron de conception Page Object
Model a été utilisé pour chaque page web testée. De même, les primitives fournis par Geb
ont été utilisés au maximum dans les cas où cela était pertinent.
On peut prendre l’exemple des Module fournis par Geb. L’utilisation des modules est
pertinente lorsqu’on a des éléments qui se retrouvent de façon répétée dans plusieurs pages
web. Un tel élément est présent dans OWM et il s’agit du menu de navigation. En effet, ce
menu est présent dans tous les pages. Le moyen proposé par Geb pour éviter la duplication
de code pour ce cas est d’utiliser des Modules. Le code(simplifié) de la Figure 6.2 illustre une
utilisation de cette primitive.
Spock a été utilisé pour la réalisation des tests. L’avantage de Spock est de pouvoir utiliser la
structure BDD. Cette structure permet de représenter facilement des scénarios utilisateurs
dans le code du test comme illustré dans la Figure 6.2.
13 https://gebish.org/manual/current/#pages 14 https://gebish.org/manual/current/#modules
38
class MenuModule extends Module {
static content = {
menuList { $("#menuList") }
}
def clickOnHomePageMenuItem(){
menuList.children(".homepage").getAt(0).click();
}
//.. autres méthodes pour intéragir avec le menu
}
// Une page d'un rapport d'OWM
class SomeReportPage extends Page {
static content = {
menu { module MenuModule }
}
}
class SomeReportSpec extends GebReportingSpec{
def "A user can use the menu to go to the homepage"() {
given: "I am on some report page"
to SomeReportPage
when: "I click on the homepage menu item"
menu.clickOnHomePageMenuItem()
then: "I should be redirect to the homepage"
at HomePage
}
}
Figure 6.2 Exemple de test fonctionnel avec Geb
6.3.2 Gestion des Drivers
Comme décrit précédemment, l’utilisation de Selenium implique d’avoir un navigateur et son
Driver respectif. Ce fonctionnement requiert de devoir spécifier dans le code où se trouve le
Driver du navigateur sur la machine comme ci-dessous.
Figure 6.3 Gestion native des Drivers
Une telle approche pose plusieurs problèmes.
39
Premièrement, Un Driver est lié à une version du navigateur. Cela implique de devoir vérifier
manuellement que la version du navigateur correspond à celle du Driver. Si ce n’est pas le
cas, il faut télécharger le Driver correspondant puis remplacer le précédent.
Un autre point est que le chemin du Driver dépend de la machine du développeur.
Cela implique aux développeurs de mettre à jour manuellement le code pour que le chemin
corresponde à celle de leur machine.
Bien sûr, un moyen d’atténuer ce point pourrait être de se fixer un chemin commun où placer
les Drivers. Cependant cette approche ne fonctionnerait que si tous les développeurs de
l’équipe utilisent le même type de système d’exploitation15.
Pour résoudre ce problème, la librairie WebDriverManager16 open source a été conçue en ce
sens. Celle-ci a pour but de rendre transparent tout le processus de gestion des Drivers.
Elle permet notamment le téléchargement automatique de la bonne version du Driver
(uniquement si elle n’est pas déjà installée) dans un dossier commun17, dossier dont le chemin
est compatible avec tous les systèmes d’exploitation. Ainsi, le problème de devoir gérer les
versions de Drivers pour chaque navigateur est éliminé grâce à l’utilisation de cette librairie.
6.4 Résultats
Les prérequis pour exécuter ces tests sont d’avoir un navigateur web d’installé. Le
téléchargement et la configuration des Drivers se font automatiquement.
Pour lancer la suite de tests, il suffit de lancer la commande :
$ mvn test
Celle-ci va exécuter la suite de tests de l’application OWM se trouvant à l’URL spécifié par
défaut avec le navigateur par défaut.
Pour plus de flexibilité, il est possible de configurer cette commande comme ci-dessous.
$ mvn test -Dgeb.env=firefox Dgeb.env.baseUrl="https://monUrl"
Avec l’argument -Dgeb.env, on peut spécifier quel navigateur utilisé pour exécuter les tests.
L’argument -Dgeb.env.baseUrl sert à spécifier l’URL de l’application si jamais elle est
différente de celle par défaut.
15 Différence entre les chemins, du type de fichiers (.exe pour Windows par exemple), etc... 16 https://github.com/bonigarcia/webdrivermanager 17 Ce dossier est celui qu’utilise Maven (le dossier .m2) pour gérer son cache.
40
6.5 Perspectives d’évolution
6.5.1 Intégration continue
Actuellement, pour exécuter les tests, on le fait sur une machine locale. L’objectif par la suite
serait de pouvoir l’intégrer dans notre plateforme d’intégration continue.
Pour des tests fonctionnels automatisés, nous avons besoin d’un navigateur web. Pour
pouvoir les exécuter avec Jenkins, il faudra installer un navigateur web sur le serveur où
Jenkins est installé. Cependant, l’instance Jenkins est utilisée par différentes équipes en plus
de l’équipe ORION. Y installer des dépendances comme un navigateur dont n’aurait pas
forcément besoin d’autres équipes serait difficile à faire valider.
Le fonctionnement par défaut de Selenium requiert que les navigateurs et leurs drivers
respectifs soient disponibles sur la même machine. Toutefois, Selenium permet l’utilisation
de machines distantes. Ainsi, toute la charge de lancer le navigateur et d’exécuter les tests
dans celui-ci est déplacée vers une machine distante. On pourrait donc mettre en place un
serveur sur lequel on installerait Selenium Server avec différents navigateurs.
Une telle approche résoudrait le point bloquant évoqué précédemment pour Jenkins.
6.5.2 Industrialisation
Les livrables qu’on produit sont spécifiques à chacune des BU dans le but de répondre à leurs
besoins propres. Cela implique que lorsqu’on effectue nos tests, on doit les faire pour chaque
BU. Par conséquent, une approche consistant à paramétrer nos jeux de test en fonction de la
BU pour laquelle ils sont exécutés serait utile et apporterait une forte valeur ajoutée à nos
tests fonctionnels.
41
Conclusion
Pendant mon stage comme prestataire de services en mission chez un client, j’ai acquis de
nouvelles connaissances sur le domaine fonctionnel de l’encaissement mais aussi le reporting
et l’importance de celui-ci.
Ce stage a été aussi l’occasion d’apprendre différents processus permettant de mener un
projet vers de la livraison continue notamment avec des tests fonctionnels automatisés.
Enfin, J’ai pu tout au long du stage vivre la transformation d’une grande structure comme
Adéo. Cette transformation s’est faite par un déploiement de nouveaux outils et processus
mais aussi par une réorganisation des équipes vers une approche agile. Une telle
transformation nécessite donc aux équipes de se former à de nouveaux outils mais requiert
surtout un changement de mentalité dans la façon de s’organiser. Ce dernier point se trouve
être un réel challenge.
42
Références
[1] Google Web Toolkit. http://www.gwtproject.org/
[2] Spring. https://spring.io/
[3] JQuery. https://jquery.com/
[4] JqGrid. http://trirand.com/blog/jqgrid/jqgrid.html
[5] Spock. http://spockframework.org/
[6] Mock. https://fr.wikipedia.org/wiki/Mock_(programmation_orient%C3%A9e_objet)
[7] SOAP. https://en.wikipedia.org/wiki/SOAP
[8] Selenium. https://www.seleniumhq.org/
[9] Geb. https://gebish.org/
[10] Page Object Model. https://martinfowler.com/bliki/PageObject.html
