Retour d’expérience : tous testeurs chez AXA !
Par Emilie-Anne Guerch, Lionel Brat, Pascal Cugnet, David Esteves Da Fonte, Vincent Dugarin, Emmanuel Lehmann et Bruno Pedotti
1) Contexte de la transformation AXA : pourquoi se transformer ?
Pour faire face à des enjeux business grandissants dans le secteur de l’assurance, AXA France lance en octobre 2017 un plan stratégique centré sur ses clients : Easy AXA « Gagnons en simplicité pour nos clients ».
A chaque instant, à chaque opération, à chaque projet, chaque collaborateur doit se demander,si cela apporte de la valeur et de la simplicité à nos clients.
Forte de ses équipes agiles, de son partenariat avec le Métier et de son savoir-faire technologique, la Direction du Système d’Information (DSI) est un pilier de ce plan. Elle doit apporter uneexpérience simple et fiable à l’ensemble des utilisateurs du système d’information.
La transformation agile de son organisation, le déploiement progressif de pratiques DevOps,l’accompagnement des collaborateurs sur ce changement culturel doit permettre à la DSI derelever ce challenge.
2) L’organisation agile à l’échelle de la DSI AXA France
L’histoire de cette transformation commence dès 2011 avec la création du Webcenter de Lille, où sont développées les applications web métiers et grand public d’AXA France. Fin 2014, 50% des équipes de la DSI travaillent en Scrum.
En 2015, la DSI construit et expérimente pendant un an, auprès de 400 collaborateurs, un modèle inspiré de Spotify et du framework SAFe.
Ce modèle est validé, déployé et généralisé au restede la DSI deux ans après, soit auprès de 1200 personnes. Il s’organise en mode Feature Team,avec un découpage standardisé basé sur la mise en place de tribus / domaines / squads.
Des équipes agiles stables, autonomes, multi-compétences et polyvalentes sont mises en place avec des Product Owners, Software Engineers et Test Engineers.
Grâce à une plus grande collaboration entre les équipes IT et les équipes Métiers, celles-ci pensent maintenant « Produit » plutôt que « Projet » et se focalisent sur la livraison de valeur visible pour le client, plus vite et plus régulièrement par petites itérations.
En parallèle, la guilde test est lancée. Direction transverse à l’ensemble des tribus, elle accompagne les équipes agiles dans leurs activités opérationnelles pour garantir la qualité des solutions informatiques et mettre à disposition les moyens de test (jeux de données, postes et matériels mobiles de test).
Sa vocation est de développer les compétences et pratiques de test des collaborateurs à un haut niveau d’expertise, en s’appuyant sur l’état de l’art du marché. Elle conseille, sensibilise et développe les compétences test au sein de la DSI AXA France.
La guilde test s’organise autour d’équipes de test qui sont managées par des engineering managers test. Chaque équipe est composée de Test Lead et de Test Engineers intégrés dans les tribus.
L’Engineering Manager Test est garant de la qualité des livrables et des engagements de la guilde. Il porte la responsabilité du staffing de son équipe, déploie les bonnes pratiques et mesure l’efficacité des plans de progrès mis en place.
Le Test Engineer contribue à la définition de la stratégie de test de son périmètre. Il assure la conception, l’automatisation et l’exécution des tests en mettant en oeuvre les bonnes pratiques de test. Il réalise et communique de manière régulière le reporting d’avancement de l’activité.
En plus des activités du Test Engineer, le Test Lead anime un chapter test et assure la montée en compétence des Tests Engineers. Il est le référent de son périmètre pour le déploiement des bonnes pratiques et la montée en compétences des différents acteurs.
Une équipe Ingénierie complète l’organisation en prenant en charge l’animation et la montée en compétence des collaborateurs. Elle définit et maintient le cadre de référence test de la guilde (méthodes, outils, conseil expertise).
3) Les Pratiques de Test
Voici les pratiques de test que nous mettons au premier plan. :
La stratégie de test se décline à deux niveaux : tribu et produit.
La stratégie de test tribu décrit le contexte de la tribu, son organisation, les moyens mis en oeuvre, l’approche des tests à mettre en place pour la validation du plan d’actions de la tribu.
Elle est validée avec le responsable de tribu.
La stratégie de test produit décline la stratégie tribu pour chaque release d’un produit. Elle aborde principalement le périmètre, la couverture des tests, les éléments d’organisation spécifiques et le planning de réalisation. Elle est partagée et validée avec l’équipe et le Métier.
Des ateliers « 3 amigos » permettent d’associer systématiquement le trio Product Owner, Software Engineer et test engineer dès l’apparition d’un nouveau besoin pour renforcer sa compréhension très en amont d’un sujet. Pendant ces ateliers, Test Engineers et Software Engineers questionnent le Product Owner pour comprendre le besoin, compléter les règles Métier et définir les exemples illustrant la User Story. Ces exemples seront détaillés par les développeurs en utilisant le langage GHERKIN pour développer la solution selon la méthodologie de développement BDD et automatiser autant que de possible.
Les parcours clés sont identifiés et définis avec le Product Owner. Ils représentent les parcours utilisateurs de bout en bout les plus critiques. Les tests de ces parcours sont automatisés et sont joués à chaque déploiement de l’application.
Ces tests automatisés sont intégrés dans la PIC (Plateforme d’Intégration Continue) du produit en cours de développement. L’automatisation est faite par un test engineer automaticien qui utilise le framework de développement utilisé par les Software Engineers pour faciliter les échanges, l’entraide et le partage des bonnes pratiques (revue de code, analyse qualité, …) au
sein de la squad/tribu.
Lorsque ces tests sont exécutés dans une phase dite d’intégration, le test engineer automaticien s’appuie généralement sur des services virtuels (bouchons ou mock services) pour gérer ses jeux de données.
Le Test Engineer organise des séances de pair test avec un Software Engineer dans un environnement proche du développement (poste du Software Engineer ou de DEMO). Le Test Engineer accompagne le Software Engineer pour jouer manuellement les cas de test des Story associés aux US « fraîchement » développées, complétées par des tests exploratoires basés sur l’expérience. Lors du pair test, les anomalies identifiées sont corrigées en séance et re-validées.
Si ce n’est pas possible, la User Story est bloquée, l’anomalie détectée fera l’objet d’un correctif à valider lors d’une prochaine séance de pair test.
Enfin, les tests de sécurité sont effectués à deux niveaux : pendant le développement en s’appuyant sur des outils d’analyse de code et en phase de préproduction par des experts sécurité (tests de pénétration).
Les tests de performance sont également effectués à deux niveaux : par les Software Engineers lors des phases amont du développement et par des experts en phase de préproduction. Des tests de montée en charge d’endurance et aux limites sont généralement effectués.
