Afin de répondre à une demande émergente, le Centre de Compétences Multi-Technologie d’Informatique Caisse des Dépôts (ICDC) lance en 2009 ses premiers chantiers d’automatisation de test. Maître d’œuvre de référence pour la Caisse des dépôts et l’INPI, ICDC est en charge du patrimoine d’applications de ces deux entités.
L’impératif de mettre en service, souvent et rapidement, de nouvelles versions applicatives oblige à placer l’automatisation des tests au centre du dispositif de validation.
L’avènement des projets agiles et digitaux en fait un enjeu majeur.
Sébastien GONTRAN nous raconte son expérience et les défis relevés.
Quels sont pour vous les principaux bénéfices de l’automatisation ?
L’automatisation doit permettre d’améliorer la productivité et la qualité du travail des équipes en charge de la réalisation et de la maintenance des applications. Aujourd’hui, l’automatisation des tests est un prérequis, socle de tout développement ou projet d’intégration de progiciels.
Quel est le rôle de Henix au sein de cette mission ?
Henix est intervenu pour nous proposer son expertise sur la partie outillage avec la mise en place des solutions de Squash TM et de Squash TA.
Comment s’est passée la mise en place de l’automatisation ?
La première vague de promotion et de diffusion des pratiques d’automatisation a duré environ 4 ans, de 2009 à 2013. Malgré un intérêt fort et partagé pour l’automatisation, nous avons rencontré des difficultés autour de 4 axes suivants :
La définition et la collecte des besoins : des difficultés pour recueillir le besoin d’automatisation et définir un périmètre pour les projets d’automatisation.Sur l’axe technique : des méthodes de développements hétérogènes des scripts automatisés et l’absence d’industrialisation dans l’exécution des tests ont conduit à un sentiment de solutions artisanales peu maintenables.Sur l’axe organisationnel, l’absence d’experts internes et le peu d’intérêt pour la montée en compétence sur ce sujet ont conduit à faire intervenir des experts externes avec un turnover qui complexifie à terme la maintenance des tests.Enfin sur l’axe des coûts, prévoir un budget pour l’automatisation restait complexe avec le sentiment pour les projets de réaliser un investissement coûteux au retour aléatoire. L’automatisation au même titre que les tests restait une variable d’ajustement sur les projets.
Comment avez-vous fait évoluer votre offre ?
"On apprend de ses erreurs" et comme la roue de Deming, le chemin de l’amélioration est sans fin. Les réponses à ces douleurs récurrentes à l’automatisation ont été une réponse à la fois méthodologique et sur l’outillage.
Tout d’abord, nous avons capitalisé sur nos années d’expériences en projets d’amélioration autour de Cmmi et appliquer / remis au gout du jour pour les activités d’automatisation : la gestion (recueil et capitalisation) des exigences.
Ainsi la collecte des besoins de tests automatisés est désormais systématisée et formalisée à l’aide de fichiers d’échange sous Excel (à l’instar d’une liste des exigences) pour assurer à la fois une traçabilité du besoin, mais aussi pour relever au plus tôt des incohérences dans la formulation des scénarios de tests. Enfin ce fichier de recueil des besoins nous sert à piloter le projet d’automatisation via les besoins, en mesurant à tout moment une couverture des exigences, besoins d’automatisation à implémenter.
Sur l’axe technique, nous sommes appuyés sur MAKO : un Framework d’automatisation par mots-clés. Cet outil s’articule avec la démarche des exigences et permet une nouvelle approche de l’automatisation focus sur les besoins. L’outil à partir du fichier Excel en entrée, génère des scripts dans le langage des automates du marché. C’est bien l’outil qui génère en se basant des bonnes pratiques de développement et pas le développeur. Ce dernier intervient à hauteur de 30 % pour des fonctions spécifiques et enrichir l’outil par l’introduction de nouveaux mots clés. En cas de changement ou nouveau besoin, nous repartons du fichier Excel pour regénérer le code, cela évite un retravail fastidieux et facilite la maintenabilité et une meilleure capitalisation.
Toujours sur l’axe technique, nous avons mis en place une plateforme de tests automatisés composés d’un ordonnanceur (Jenkins) d’un référentiel de test (Squash TM).
Sur l’axe organisationnel, le Framework est venu « changer la donne » du projet d’automatisation. Avant il s’agissait d’un exercice purement technique, requérant la présence d’experts sur toutes les phases de conception et de développement. L’outil permet aux sachant fonctionnels de se réapproprier en grande partie la démarche. Cette approche permet aux sachant fonctionnels de facilement et rapidement « scénariser » leurs cas de test, à l’aide de mots-clés.
Un autre accélérateur a été la migration de notre patrimoine de tests de HP QC vers Squash TM. Squash TM permet d’exécuter et de centraliser le reporting des tests automatisés de différentes technologies. Associé à la plateforme d’exécution des tests basée sur Squash TA, il permet de compléter cette réappropriation du test automatisé par les équipes fonctionnelles qui lancent les tests à la demande.
Quels ont été les principaux impacts au niveau de la restructuration des équipes suite à ces évolutions ?
Un des objectifs était, et est toujours, de permettre une mutualisation des efforts de tests entre les équipes et les couches de tests (fonctionnels, performance, sécurité).
L’introduction du fichier d’échange va dans le bon sens car il permet aux équipes fonctionnelles de préciser leur besoin dans un format directement opérationnel.
Aujourd’hui, les échanges entre les différentes parties sont donc plus efficaces et l’effort est en partie transféré vers les équipes fonctionnelles qui s’approprient davantage l’automatisation des tests.
D’autre part, nous souhaitons impliquer davantage les maîtrises d’œuvre projet pour qu’elles interviennent pleinement dans le processus de maintien du référentiel de tests automatisés, avec également pour objectif d’assurer la réactivité dans la maintenance des tests.
Et les impacts au niveau technique ?
Aujourd’hui, 70% des étapes de test dans les scripts produits sont directement générées par les mots clés préexistants. Nous estimons un gain de productivité multiplié par 4 grâce à la nouvelle méthodologie.
Ce gain est important pour l’insertion de l’automatisation dans les projets agiles qui deviennent un standard.
Les cycles de développement sont plus courts et les besoins en tests de non-régression plus importants. Dans un tel contexte, l’automatisation devient une pratique indispensable.
Si vous deviez nous indiquer un axe de développement majeur pour la suite, quel serait-il ?
Un des objectifs est de continuer le développement de notre méthodologie pour pouvoir formuler les tests avec une syntaxe de type "user-story".
Nous souhaitons également étendre notre dictionnaire MAKO pour prendre en charge l’automatisation des applications mobiles qui est une demande émergente.
Comme quoi, l’automatisation du patrimoine de tests a de l’avenir !
Merci Sébastien GONTRAN pour ce retour d’expérience enrichissant, et un grand merci pour la confiance accordée à Henix.