Quel est l’enjeu des tests pour l’industrie bancaire ?
Avant d’être mis sur le marché, un produit financier développé par des équipes informatiques doit être testé à plusieurs égards : à la fois pour respecter les contrôles réglementaires, faire du zéro défaut pour le client et fournir des éléments de garantie (notamment sur le risque opérationnel) et s’assurer que l’application qui va être déployée ne perturbera pas les autres opérations de la banque. Lorsque l'on fait d’importantes bascules produit, tout le réseau de distribution est lourdement impliqué et il n’y a pas droit à l’erreur.
Les banques sont confrontées à des exigences de tests qui font exploser les charges et les calendriers des projets : adoption de nouveaux progiciels, intégration avec le reste du réseau de distribution, produits plus complexes, partenaires avec des infrastructures différentes… sont autant de causes de dérive des calendriers de recette. La phase de tests peut alors dépasser 30 % des charges du projet, notamment dans la bancassurance où les contraintes de fiscalité et de respect des normes comptables sont élevées. Il n’est pas surprenant d’apprendre qu’on a testé certains produits ou applications pendant plus d’un an. Ces calendriers ne sont plus « audibles » par les métiers qui ne peuvent plus attendre ou différer un produit concurrentiel. Il faut donc accélérer le cycle des projets. L’un des leviers les plus efficaces dans cette perspective, aujourd’hui, est l’usine de tests.
Qu’est-ce qu’une usine de tests ?
C’est le regroupement de l’ensemble des compétences de tests de l’entreprise dans une organisation industrielle qui pilote le cycle de tests de bout en bout, durant tout le cours du projet, pour l’ensemble ou une très grande partie de l’informatique de l’entreprise. Les volumes de tests ainsi concentrés permettent d’investir dans l’automatisation des tests, pratique qui a atteint récemment des degrés de sophistication élevés avec les nouvelles solutions d’automatisation des tests ou de vieillissement des données. Auparavant, tout le monde était amené à tester, maintenant ce sont des spécialistes qui ont développé des méthodes, des compétences et des savoir-faire spécifiques en matière d’homologation logicielle. Un assureur a, par exemple, constaté que ses équipes de l’usine de tests identifiaient 6 fois plus d’anomalies qu’un utilisateur métier.
Quelles sont les innovations récentes qui ont permis d’accroître le niveau d’automatisation des tests ?
Les deux grandes innovations en matière d’industrialisation sont les robots programmés pour passer les tests automatiquement et les systèmes d’extraction et de gestion des données qui permettent de fournir tous les jeux d’essai nécessaires, avec les services d’anonymisation associés. Les éditeurs ont beaucoup progressé sur ce champ-là.
Quelle est la pratique des banques en matière d’usines de tests ?
Elles peuvent les organiser en interne ou en externe. Un grand réseau bancaire français a ainsi développé deux usines de tests, une en France et l’autre en Afrique du Nord. Dans la majorité des cas, c’est une usine en « propre » qui assure les tests, avec une démarche pilotée par le DSI et la DRH pour répondre à un changement profond du métier de l’homologation des systèmes. Pour les grands projets, l’usine est adossée à une société de services qui apporte les compétences off-shore nécessaires à la montée en charge du projet.
Un groupe de bancassurance avec laquelle nous avons travaillé, a préféré situer son usine de tests en interne pour mieux maîtriser ses cycles de tests et les industrialiser eux-mêmes avant de les transférer dans la captive du groupe. C’est une bonne pratique.
Pourquoi vaut-il mieux industrialiser en interne ses cycles de tests ?
Pour une raison simple : on ne peut pas externaliser des tests qu’on ne maîtrise pas soi-même. Les sous-traiter auprès d’un tiers implique de lui transférer une connaissance fine des exigences fonctionnelles et techniques de l’application, connaissance souvent peu ou mal documentée. On ne peut compter sur personne d’autre que les experts internes qui connaissent l’application dans tous ses détails pour réussir une bonne industrialisation des tests. Quand l’objectif devient celui d’automatiser (choix d'outils…) ou d’améliorer les méthodes de tests (i.e. hiérarchisation et mesure des risques, suivi des anomalies, organisation des environnements), l’assistance d’un spécialiste est utile, mais rien ne remplace la compétence métier fonctionnelle des équipes internes qui peuvent appréhender les risques pour la banque. Il faut bien comprendre qu’après la recette, on passe en production. Si cela ne marche pas quand on appuie sur le bouton, il faut pouvoir justifier les incidents auprès du marketing ou du réseau commercial.
Les directeurs des risques, notamment, s’impliquent de plus en plus sur le sujet des tests et demandent à ce que toutes les grandes applications qui basculent dans le réseau soient validées dans le cadre d’un comité des risques SI, préalablement à la mise en production.
Globalement, que faut-il faire pour que ces usines de tests soient vraiment efficaces ?
Tout d'abord, il faut mettre en place une méthodologie transverse de tests identique pour tous, de la maîtrise d’ouvrage jusqu’aux prestataires et même à l’éditeur. Une usine ne peut pas marcher avec plusieurs méthodes de travail. C’est le travail du DSI que de déterminer l’approche qui lui paraît la plus efficace en fonction des types d’application concernés comme, par exemple, la mise en place d’un produit d’assurance vie ou d’un poste de travail agence. Il devra sans doute définir des méthodes « agiles » pour développer plus vite et développer des tests « moins lourds » comme pour le cas d’un intranet. Ensuite, on peut commencer à établir une courbe d’expérience sur cette méthode. Le Club français du test logiciel fait la promotion d’un certain nombre de méthodologies, mais quelle que soit celle qui est choisie, ce qui importe, c’est que tout le monde utilise la même au sein de l’entreprise.
Ensuite, il paraît nécessaire de regrouper les équipes qui font du test d’intégration et du test fonctionnel ou de qualification, soit physiquement (ce qui est idéal) dans l’usine, soit dans une gouvernance commune (voir Encadré 1). Il faut un seul patron pour piloter les phases de tests afin d’éviter les tests en double. S’ils sont plusieurs, très rapidement, ils vont s’opposer, chacun cherchant à démontrer qu’il a mieux testé que l’autre, comportement souvent source de coûts et de délais.
Enfin, les métiers des tests sont devenus des compétences à part entière au sein de la DSI et de la MOA, compétences qui n’ont plus grand-chose à voir avec la fonction historique de business analyst ; ce dernier faisait un peu tout : cahier des charges, préparation et exécution des campagnes de recette, accompagnement du changement, etc. Nous constatons une vraie courbe d’expérience spécifique aux tests chez nos grands clients. Ainsi, le métier de test analyst émerge : il doit savoir spécifier des cas de tests économes et, de bout en bout, rédiger des cahiers des charges pour la robotisation des tests de non-régression. De même, le test manager doit démontrer une double compétence fonctionnelle et de maîtrise des risques vis-à-vis du métier :
- il définit les stratégies de tests et de « non-tests », en précisant comment tester le plus efficacement possible (compromis entre couverture des tests, calendrier du projet, coût des campagnes) ;
- il est capable de dire où tester, ce qu’il faut automatiser ou non (périmètres stables).
Ces métiers sont-ils vraiment reconnus ?
Ils n’apparaissent pas dans la dernière nomenclature des métiers du CIGREF. Et pourtant, tous les DSI reconnaissent l’intérêt d’avoir un métier autour du test analyst. L’usine a le mérite de définir un cadre, un patron, des méthodes et des outils qui donnent plus de visibilité à ces métiers. Le test analyst va rester quelques années en poste, pour devenir ensuite responsable de référentiel ou test manager, puis directeur de tests d’un grand projet au sein de l’usine. Ils peuvent aussi mettre à profit leurs compétences de tests pour intégrer les filières formation, qualité ou encore de maîtrise des risques.
Au niveau du compte de résultat de cette usine, comment peut-on évaluer les investissements à consacrer, d’un côté, et les gains que l’on va engranger, de l’autre ?
Une usine est là pour durer. Elle va tester le patrimoine applicatif de la banque pendant de nombreuses années. Pour profiter d’un levier de financement, il faudra la mettre en place pour le premier gros projet pour lequel le cycle de tests atteint une durée inhabituelle : le retour sur investissement peut être rapide, souvent dès la troisième release de l’application, car l’usine réduit le cycle de test d’un grand projet par 2 ou 3. Si on fait de la petite maintenance sur des applications stables, le retour sur investissement sera en revanche plus long.
Selon différents retours d’expérience, une bonne usine de tests peut diminuer le cycle de tests manuels par deux et les charges d’au moins 30 à 40 %. Et les niveaux d’automatisation des tests atteignent 70 à 75 %.
