Juguler l'inflation des tests pour lancer plus vite les nouveaux produits

Afin de réduire le délai des tests applicatifs, de grands groupes créent des centres d'exécution des tests qui rassemblent les compétences dans ce domaine. Le point sur deux approches différentes chez HSBC Assurances et à la banque de détail de la Société générale.

Les systèmes d'information des assureurs et banquiers sont de plus en plus complexes et imbriqués. Les entreprises du secteur, soucieuses de prévenir les défaillances en production, ont souvent été embarquées ces dernières années dans le cycle infernal de l'inflation des tests. Le poids des tests d'intégration et surtout la complexité des tests de non-régression à valider font régulièrement exploser les plannings. Ce qui retarde d'autant le délai de lancement de tout nouveau produit d'épargne, de crédit ou d'assurance.

Repenser la stratégie de test afin d'en réduire la charge

Une dérive incompatible avec l'environnement concurrentiel auquel sont confrontées ces entreprises. “ Le test est devenu une des premières charges de travail pour les projets informatiques, alors que dans le passé ces charges étaient plutôt bien absorbées par les équipes informatiques et les utilisateurs ”, observe Thierry Cartalas consultant chez TnP Consultants. Le test d'un produit financier, par exemple, peut désormais s'étaler sur une période de quatre à plus de douze mois dans le cas d'une refonte avec mise en place d'un progiciel.Afin de contenir cette inflation, banques et assureurs – suivant le modèle de l'industrie avant eux - s'attachent depuis quelques années à redéfinir leurs processus de tests, historiquement le parent pauvre du développement informatique. Plus récemment, certains groupes se sont lancés dans la création “ d'usines de tests ”. “ Du fait de l'imbrication des systèmes, chaque fois que l'entreprise lance un nouveau produit, les équipes testent souvent les mêmes chaînes techniques. Beaucoup d'entreprises du secteur se sont dit qu'il y avait plus de valeur à confier ces tests à des professionnels concentrés dans une usine, souvent proche de la DSI. Quitte à ce que la MOA (maîtrise d'ouvrage) historique, qui gérait auparavant une partie des tests, délègue cette fonction d'exécution à cette usine ”, poursuit le consultant. Une démarche qui découle aussi de l'arrivée d'outils plus matures en matière d'automatisation des tests. La création de ces usines induit généralement plusieurs chantiers : la remise à plat des processus de test, la réorganisation des services – notamment entre MOA et MOE (maîtrise d'œuvre) – et la revalorisation du métier de testeur. Grâce à ces mesures, assureurs et banquiers, principaux demandeurs et concernés en la matière, espèrent ainsi trouver la formule magique : réduire le délai de mise en production tout en préservant la qualité. HSBC Assurances a installé des robots pour l'automatisation des tests de non-régression pour ses produits d'assurance-vie dès le début des années 2000. Des tests gérés par les équipes d'homologation hébergées au sein de la DSI. Mais c'est véritablement en 2009 que l'assureur a lancé son chantier d'industrialisation des tests. A cette époque, il décide d'élargir l'automatisation des tests à la phase de recette ainsi qu'aux applications intranet et extranet. Cette décision résulte alors d'“ une volonté de la direction générale de raccourcir le délai de mise en place de nouveaux services web ”, rappelle Elena Virgos, la DSI de HSBC Assurances. Les applications web étant par essence la vitrine de la société, les équipes de HSBC avaient alors tendance à multiplier les tests afin de se prémunir de tout dysfonctionnement en production. Les charges de test grimpaient en flèche. “ La recette représente généralement 25 à 30 % de la charge d'un projet de développement. Dans notre cas, on pouvait arriver à 50 % ”, précise Elena Virgos.

Homogénéiser les pratiques

La société déploie donc des automates, côté recette, sur les systèmes intranet-extranet. Des référentiels de tests sont créés avec des stratégies de tests préétablies (scénarios, cas de tests, valorisation des cas). Mais le modèle n'est pas viable en l'état. “ Nous avions un budget prévu pour la maintenance des robots, l'hébergement et la qualification. Mais pas pour maintenir le référentiel lui-même et le développement des scripts. C'était pénalisant ”, rappelle la DSI. Le référentiel risque vite de devenir obsolète. Une meilleure coordination est également nécessaire entre les équipes d'homologation, côté informatique, et les équipes de recette, rattachées à la maîtrise d'ouvrage, afin de mieux cerner les tests réutilisables, et d'homogénéiser les pratiques et les outils. Dès lors, la décision est prise, en 2010, de fusionner les équipes : les ingénieurs d'automatisation rejoignent les équipes de recette.

Un cycle de test réduit de 43 % chez HSBC Assurances

La création de ce centre de test interne, composé d'une quinzaine de personnes, avec un budget alloué, s'accompagne d'une refonte de l'ensemble du processus d'homologation, du lancement du projet de développement à la mise en production. La société s'est attachée notamment à la mise en place d'un processus de test continu. “ Auparavant, il y avait un espace vide entre la définition de stratégie et l'exécution des tests. Nous attendions que les développements soient réalisés avant de passer aux tests de non-régression et de qualification ”, rappelle Elena Virgos. D'où une perte de temps. Désormais, “ Une fois reçues les exigences de tests, nous donnons un cahier de spécifications aux ingénieurs d'automatisation qui créent les nouveaux scénarios de test, enrichissent les jeux de test, ou développent des scripts complémentaires avant même la fin des développements, illustre la DSI. En complément, la stratégie de test a été affinée afin de mieux définir ce que l'on teste avec les automates ou en manuel. ” L'analyse de risque est de ce point de vue primordiale. “ On gère la recette de façon manuelle là où le risque est important. Quand le risque est moindre, on laisse opérer les automates ”, précise la DSI. Dans l'optique de mieux encadrer les exigences de tests, le processus d'échange avec les métiers, ainsi que les modèles de documents, ont été révisés.Au final, la société a réduit le délai de test de 43 %. Un résultat qui n'est pas seulement lié à l'automatisation des tests mais aussi à cet effort de formalisation. La charge a baissé de 30 % grâce à l'automatisation (sur le domaine assurance-vie et les applications internet-extranet, le ratio est de 70 % en automatisé et 30 % en manuel) et à une meilleure hiérarchisation des tests.Pour la banque de détail France (BDDF) de la Société générale, professionnaliser le test était devenu indispensable en raison d'une part de l'augmentation des incidents (le plus souvent mineurs) en production, d'autre part d'une charge de test qui gonflait régulièrement en raison de la complexité du système informatique. “ Notre système informatique est très urbanisé et imbriqué. Une opération initiée dans une application peut se dénouer ensuite dans une quinzaine d'autres applications ”, remet en perspective Catherine Lepesqueur, responsable qualification pour la Banque de détail en France. Ces briques applicatives sont développées par quatre départements différents. Les responsabilités liées au test étant diluées et les méthodes disparates, la principale difficulté pour la société, en l'absence de “ pilote ” référent transverse, tenait à la maîtrise des tests de bout en bout de l'ensemble d'un processus.

Centralisation des homologateurs à la DSI

En 2008, lorsqu'il initie son programme d'industrialisation des tests, le groupe bancaire ne part pas de zéro ; il a déjà réuni l'ensemble des homologateurs (analystes de test, gestionnaires de test…), soit environ 200 personnes, sous la bannière de la DSI. Y compris, donc, les équipes fonctionnelles émanant des maîtrises d'ouvrage. Un important travail de réorganisation interne souvent délicat pour ces grands groupes, tant les MOA sont parfois réticentes à céder ces compétences. Il s'agit néanmoins d'un préalable essentiel à l'introduction de pratiques de tests plus industrielles. BDDF peut alors passer à l'étape suivante : la séparation franche entre la conception des tests et leur exécution.En clair, l'approche choisie par la banque consiste à professionnaliser la partie amont, la conception des tests, et sous-traiter leur exécution à deux centres de services dont la prestation est mesurée à l'aide de métriques de qualité. L'un est proche des équipes de développement en région parisienne, l'autre implanté chez un prestataire hors site. A charge pour ces deux centres d'utiliser la même méthodologie conforme aux exigences de la banque, de faire bénéficier d'un TJM (taux journalier moyen) moindre pour le centre hors site et d'offrir une capacité d'absorption des pics de charge (au moment de la livraison d'une application) plus importante. “ Dans ce cas de figure, le prestataire prend en général à sa charge des tests non automatisés imposant du travail de saisie et, surtout, nécessitant beaucoup de pointages, analyse Thierry Cartalas. Il amène des outils de rapprochement automatique, de saisie, de gestion des environnements de données et éventuellement de capture des sessions de tests ”.Des phases d'exécution que les MOA bancaires confiaient de toute façon généralement à des prestataires en faisant appel à des ressources en régie. En interne, la cellule qualification de la banque s'est concentrée sur l'amélioration de la conception des tests.

Refonte des pratiques et redéfinition d'une filière du test

Son objectif principal était de mieux anticiper leur exécution. Elle a d'abord identifié les meilleures pratiques initiées ça ou là dans les différents départements, puis a redéfini complètement le processus de test. Une méthodologie de conception des jeux de tests commune aux quatre départements, basée sur un référentiel commun, s'est substituée aux différents référentiels éparpillés au sein des départements. Sur ce référentiel viennent se connecter les équipes des deux prestataires. Cette refonte des pratiques internes s'accompagne d'une sensibilisation des professionnels du domaine sur la notion de risque versus effort de test. Mais c'est surtout sur la revalorisation des compétences du test, métier peu reconnu en interne, que la banque a concentré ses efforts en 2009. “ Le test n'était pas considéré à l'époque comme un véritable métier, rappelle Catherine Lepesqueur. Pour la partie tests fonctionnels, les postes étaient considérés par la direction des ressources humaines comme un sous-métier de la MOA. Quant aux tests techniques, ils n'étaient même pas identifiés comme une profession en tant que telle. Résultat : les personnes qui assuraient ces fonctions ne se sentaient ni valorisées ni considérées. ”La Société générale a, dès lors, redéfini les postes clés et une filière spécifique avec les évolutions professionnelles afférentes. Un parcours de formation a été mis en place débouchant sur une formation certifiée par l'ISTQB (International Software Testing Qualifications Board). Le métier de responsable de qualification (RQA), qui n'existait pas vraiment au sein de la société, a été créé et mis en valeur auprès des MOA et de la DSI. De nombreuses actions de sensibilisation (séminaires, etc.) ont également été conduites auprès de la communauté interne concernée par le test. Ce travail de communication est désormais récompensé. “ Auparavant quand nous passions une annonce pour un poste à pourvoir, nous n'avions pas de réponse en interne. Depuis 2010, nous obtenons des candidatures ”, se réjouit Catherine Lepesqueur. BDDF ne livre pas de données chiffrées quant aux résultats obtenus. “ La couverture de test s'est améliorée et, dans certaines équipes, on constate une réduction de la charge et du délai ”, signale néanmoins Catherine Lepesqueur.Reste que la société a encore de gros chantiers à mener. Contrairement à sa consœur de l'assurance, la banque n'a pas donné sa priorité à une démarche d'automatisation des tests. Elle ne devrait s'y atteler que cette année. “ Il nous fallait d'abord disposer d'un référentiel de test avant de plancher sur l'automatisation ”, souligne Catherine Lepesqueur. Surtout, BBDF compte regrouper l'ensemble des ressources dédiées au test - c'est-à-dire la conception et l'exécution - au sein d'une même structure. “ Nous comptons passer du centre d'exécution des tests au centre de test tout court ”, résume Catherine Lepesqueur. Un nouveau chantier de réorganisation qui doit faciliter la communication entre les différents intervenants et l'élimination des tests redondants.