Test & Qualité
Réussir une recette fonctionnelle Core Banking sans perdre la traçabilité
Sur un programme Core Banking, la difficulté n’est pas d’exécuter des tests, mais de garder un fil continu entre ce qui était demandé, ce qui a été testé et ce qui a été corrigé. Quand ce fil se rompt, la recette devient un théâtre d’activité sans garantie.
De l’exigence au scénario, sans rupture
Chaque scénario de test doit pouvoir être rattaché à une exigence précise, et chaque exigence doit être couverte par au moins un scénario. Cette matrice de couverture n’est pas un livrable bureaucratique : c’est l’instrument qui permet de répondre, à tout moment, à la question « avons-nous testé ce que nous avions promis ? ».
Le piège classique est de tester ce qui est facile à tester plutôt que ce qui est critique. Une couverture pilotée par les exigences, et non par la commodité technique, corrige ce biais.
Les jeux de données sont la moitié du test
Un scénario bancaire ne vaut que par les données qui l’alimentent : devises, schémas comptables, cas limites de calcul d’intérêts, dates d’arrêté. Préparer ces jeux de données est souvent plus long que d’écrire les cas — et c’est là que se cachent les anomalies les plus coûteuses.
Industrialiser ces jeux de données permet de rejouer une campagne à l’identique, condition indispensable d’une non-régression crédible.
Une anomalie n’est utile que si elle est reliée
Une anomalie isolée est une information ; une anomalie reliée à son scénario, à son exigence et à sa correction est une décision. Le suivi des anomalies doit donc remonter jusqu’à l’exigence concernée, pour mesurer le risque résiduel réel avant un go-live.
Définir les critères de sortie avant de commencer
Les critères de sortie d’une recette se définissent au cadrage, pas à la veille du go-live. Sans seuil clair — couverture atteinte, anomalies bloquantes soldées — la décision de mise en production devient politique plutôt que factuelle.