La concurrence et le marché obligent de plus en plus les banques à se tourner vers le Digital Banking pour accélérer les transactions financières des clients et leur offrir une meilleure accessibilité à leurs services. Cette évolution nécessite le développement rapide de nouvelles fonctionnalités, de nouvelles applications et/ou de nouvelles intégrations à des applications tierces.

Dans ce contexte, l’aspect qualitatif des nouveaux développements est essentiel mais demande des ressources conséquentes en termes de test logiciel. Le développement en mode Agile met d’autant plus en exergue ce besoin que les cycles de vie des logiciels sont très courts.

Cela amène la plupart des acteurs du Digital Banking à se tourner vers l’automatisation des tests logiciels. Cette automatisation permet de réduire les coûts et les temps d’exécution mais elle oblige à relever certains défis d’ordre technique et organisationnel.

Dans cet article nous nous proposons de mettre en lumière les défis majeurs liés à l’automatisation des tests dans le contexte Digital Banking et nos retours d’expérience sur sa mise en place.

Défis techniques

1. Le choix de l’outil d’automatisation

Le choix d’un outil peut être compliqué pour un acteur du secteur bancaire : la multiplicité des offres (que ce soit freewares ou sous licence) et des fonctionnalités des différents outils, demande une analyse attentive.

Afin de choisir l’outil répondant au mieux à vos besoins, il est nécessaire de présélectionner les outils sur plusieurs critères : le coût des licences, la qualité du support client, les technologies pouvant être automatisées avec l’outil, la facilité de scripting et/ou de compréhension des flux par des acteurs métier, etc.

Par la suite, il est recommandé d’organiser des POC (Proof of Concept) avec les fournisseurs des solutions d’automatisation présélectionnées. Ceux-ci seront à même de vous expliquer précisément les bénéfices et limitations de leurs outils, de manière personnalisée sur vos applications.

Une fois l’outil choisi, il doit être intégré à votre infrastructure logicielle.

Les infrastructures bancaires sont très souvent complexes et soumises à des règles de sécurité strictes. L’intégration de solutions tierces et donc externes à cette infrastructure préexistante, peut parfois s’avérer compliquée. Il est fortement conseillé d’impliquer, au plus tôt, tous les acteurs qui seront amenés à travailler sur sa mise en place, et tout particulièrement les administrateurs des infrastructures informatiques. Ceux-ci sont les mieux placés pour comprendre vos besoins et y répondre, tout en respectant les exigences de sécurité et d’infrastructure mises en place dans votre banque. N’hésitez donc pas à organiser des réunions régulières avec ces acteurs, pendant toute la mise en place de la plateforme de test afin de s’assurer que tous les besoins sont pris en compte.

2. Un environnement de test fiable

Pour obtenir des résultats les plus fiables et ainsi minimaliser l’apparition de faux-négatifs, l’exécution en campagne du patrimoine de scripts automatisés requiert l’accès à un environnement stable et dédié à cette tâche.

Il peut parfois être assez difficile d’accepter l’idée de dédier un environnement uniquement à l’exécution des tests automatisés, notamment en termes de coûts. Cependant, cela reste le meilleur moyen de s’assurer que l’exécution de ces scripts peut être lancée à tout moment sans bloquer les ressources nécessaires pour les tests manuels ou pour d’autres opérations.

S’il s’avère inenvisageable d’avoir un environnement dédié dans votre organisation, il est fortement conseillé de mettre en place un planning de disponibilité de l’environnement, afin de prévoir des plages où les exécutions seraient lancées sans interférer avec les autres utilisateurs de l’environnement, par exemple en soirée ou pendant les week-ends. Ces plages devraient, bien évidemment, prendre en compte les plages d’utilisation de l’environnement pour les testeurs et pour d’autres opérations comme les mises à jour, les maintenances etc.

L’environnement devrait être disponible sur des plages de durée minimum chaque jour, permettant l’exécution des campagnes de tests automatisés. Cette durée doit être évaluée selon le périmètre du projet d’automatisation et donc selon le nombre de scripts de test à lancer.

3. Des bonnes pratiques de développement

Afin de permettre une automatisation efficace au niveau IHM, les applications doivent, être développées en suivant des bonnes pratiques de développement (comme W3C pour les applications web ou Sun Coding Conventions pour les applications Java), et notamment en ce qui concerne les conventions de nommage des objets avec la mise en place d’identifiants uniques : cela sera d’autant plus simple pour identifier les éléments des pages, comme les boutons ou les champs texte, de manière unique.

En effet, si certains éléments possèdent des identifiants auto-générés, lors de l’ajout de boutons ou de champs dans l’application, ces identifiants risquent d’être décalés/modifiés. Dans le pire des cas, s’il n’y a pas d’identifiant, il peut être très complexe voire impossible d’identifier l’élément dans la page de l’application.

Certains logiciels d’automatisation auront également plus de difficulté à interagir avec des éléments qui ne sont pas identifiés correctement via des tags (par exemple à cliquer sur des boutons identifiés comme des DIV ou des SPAN dans une page HTML).

L’identification correcte des éléments d’une application est aussi essentielle pour l’accessibilité des applications numériques puisqu’un bouton ou un champ qui n’est pas identifié comme tel ne le sera pas non plus par un lecteur d’écran par exemple. Ces exigences en termes d’accessibilité seront l’objet de l’European Accessibility Act (EAA), qui s’appliquera au secteur bancaire européen dès fin juin 2025. Ces nouvelles normes seront une bonne opportunité pour les banques de mettre à jour les règles de programmation pour le développement de leurs applications, et ainsi de définir des règles de nommage et d’identification d’objets dans leurs codes sources.

4. Une application stable

L’idéal pour l’automatisation est que l’application à automatiser soit suffisamment stable pour que le temps de maintenance des scripts soit réduit au minimum. Il est donc recommandé d’automatiser des applications finies ou des parties de l’application qui sont finies.

Cela n’est pas toujours possible, notamment en mode Agile, où des nouveaux projets de modifications de l’application ou simplement de nouveaux sprints sont régulièrement lancés. Ces modifications auront des impacts plus ou moins importants sur l’existant.

Afin de pallier cette instabilité, il est vital qu’un processus de release management clair et global soit mis en place sur tous les environnements de l’application et en particulier sur l’environnement dédié à l’automatisation le cas échéant.

Ce release management devrait inclure l’édition des release notes détaillant les changements et les impacts potentiels sur l’existant. Cela permettra à l’équipe d’automatisation, mais également aux testeurs, de mieux cibler le périmètre des tests de non-régression à couvrir ainsi que les modifications à apporter aux scripts existants. Sans ce processus, l’équipe d’automatisation sera aveugle et ne pourra donc être suffisamment proactive dans la mise à jour des scripts, ce qui, mécaniquement, allongera le temps de maintenance des scripts.

Défis organisationnels

1. Le périmètre de test à automatiser

L’automatisation des tests ne pourra pas être effectuée efficacement tant que le périmètre de test n’aura pas été défini et clairement détaillé.

La première chose à faire est de définir les niveaux de test et les types de test qui devront être automatisés, chaque niveau et chaque type de test ayant des objectifs et des valeurs ajoutées différents. Ces objectifs sont documentés à travers la politique d’automatisation globale de la banque qui est ensuite déclinée à travers les stratégies d’automatisation pour chaque application.

2. Ressources de test

Avant le lancement du projet d’automatisation, il est primordial de bien évaluer les besoins en ressources humaines et matérielles.

Il faut identifier quelle est l’infrastructure d’automatisation à mettre en place, quels sont les besoins matériels et humains nécessaires à son fonctionnement et sa maintenance.

Sur un projet d’automatisation de tests, il est nécessaire d’avoir des ressources humaines disponibles pour plusieurs tâches : la gestion et la maintenance du patrimoine de tests candidats à l’automatisation, le scripting des tests automatisés, la gestion des données de test (collectes et maintenances), l’exécution des tests et la maintenance du patrimoine de tests automatisés.

Le nombre de personnes affectées par tâche dépend de la taille du projet de test et peut évoluer au fur et à mesure que le périmètre augmente.

Ne pas prévoir ces ressources à l’avance ou ne pas prendre en compte la possible évolution du projet, et donc l’augmentation des besoins en ressource, peut ralentir ou bloquer le projet pendant une longue période, surtout en milieu bancaire, où les budgets sont souvent décidés à l’année et non flexibles.

3. La gestion des données de test

La gestion des données de test est un aspect crucial de l’automatisation des tests, du fait du volume de données nécessaires et de la couverture des cas fonctionnels.

Il est donc essentiel de définir les besoins en amont de l’automatisation et de prévoir une stratégie pour gérer leurs possibles évolutions et maintenances, car plus le nombre de tests à automatiser augmente, plus il sera difficile d’intégrer la gestion de ces données par la suite.

Pendant la phase de mise en place de la stratégie d’automatisation, il est de bonne pratique de définir les types de données qui seront nécessaires tout au long du projet d’automatisation. Cette définition ne requiert pas une précision absolue concernant chacune de ces données, mais simplement une compréhension globale de leur nature, de leur localisation et de leur maintenabilité.

L’identification précise des données et leur collecte aura lieu durant les différentes itérations des projets d’automatisation, une fois leurs périmètres et objectifs définis clairement.

Le domaine bancaire est un secteur où une grande attention est portée à la sécurité des données et leur structure est souvent complexe, ce qui rend leur acquisition difficile.

Il est donc important de se renseigner sur l’accessibilité des données et sur la façon de les obtenir.

Il est possible de travailler avec deux types de données de test : des données statiques souvent intégrées directement dans les scripts ou générées à la demande, dont la maintenance est relativement simple, et des données dynamiques extraites de la base de données client et qui évoluent à chaque lancement des tests. Pour ce deuxième type de données, il est conseillé de mettre en place un système de collecte automatisé.

4. La communication avec les équipes de développement et le métier

Il est essentiel que l’équipe d’automatisation soit intégrée dans le cycle de vie du logiciel cible et entretienne une communication régulière avec les équipes de développement et les équipes métier.

Cette communication est d’autant plus nécessaire dans le domaine bancaire car, de façon générale, on y trouve beaucoup de parties prenantes, réparties en de nombreuses divisions et équipes, qui n’ont pas nécessairement de liens hors du projet.

Avant le lancement officiel du projet d’automatisation, il est nécessaire de prendre le temps de discuter avec toutes les parties prenantes et de leur présenter les tenants et aboutissants, le rôle qu’ils vont y jouer, et organiser des ateliers de sensibilisation aux bonnes pratiques de test et aux exigences de l’automatisation.

Une fois le projet lancé, les réunions de suivi sont très importantes pour garder les acteurs du projet à jour et pour discuter d’éventuels blocages ou succès.

Les rapports sont aussi un moyen efficace de garder une bonne communication dans le projet : ils permettent de garder les parties prenantes informées de façon détaillée des avancements.

En plus des rapports d’avancement, des rapports d’exécutions des campagnes de tests peuvent être très utiles pour communiquer plus concrètement sur les résultats des exécutions des tests et donc l’état de l’application.

Pour résumer, l’intégration du projet d’automatisation des tests au sein même des projets de développement des applications est essentielle à son succès. Celle -ci passe également par la bonne communication, la collaboration entre les équipes et la prise en compte de ce projet avec la même criticité que les projets de développement de la banque.

L’automatisation doit être un processus permanent incluant l’écriture et la maintenance régulière des scripts automatisés en parallèle du développement de l’application testée. Elle doit être considérée comme tel pour être efficace et pérenne dans le temps.