Les tests de non-régression recouvrent des enjeux de coûts, de délais, de continuité d’activité. Ils s’inscrivent dans des phases de changement de logiciels souvent critiques. Un outil de test de non-régression optimise la gestion de vos flux de données et réduit le temps de ces tests.
Le test de non-régression : une façon d’assurer le changement lors des échanges de données
Comme DSI ou architecte, vous connaissez ce principe du changement : contrôler et maîtriser l’évolution entre la situation actuelle et la cible. Les tests de non-régression sont les garants de la mesure et de cette maîtrise.
La méthodologie de test de non-régression consiste à prendre un point de référence avant le changement, puis de le comparer après la mise en œuvre du changement. Une fois la comparaison validée, vous pouvez appliquer ce changement. Il n’existe malheureusement que cette comparaison qui apporte des garanties sur la qualité du résultat attendu.
Dans la pratique, cette méthodologie s'avère très ardue à suivre pour tester les flux de données. Il s'agit en réalité d'un produit cartésien entre :
- les variantes fonctionnelles des messages de la source,
- les états finaux (succès, erreur, etc.),
- les contenus transportés : formats (JSON, XML, CVS, etc.) et protocoles (Fichiers, API, WebServices, Messages, etc.).
Ces tâches sont très coûteuses et demandent un accompagnement lourd des équipes fonctionnelles. C’est dans l’optique de simplifier et d’accélérer les tests de non-régression que nous avons conçu la console de supervision Enterprise Flows Repository (EFR).
Que cherche-t-on à optimiser ?
Pour bien comprendre, il est nécessaire de rappeler les différents types de changements rencontrés :
- Correctif. Le correctif d’un bug sur un échange de données est un cas simple. Dans la pratique, le développeur reprend un jeu de tests pour valider le correctif. Au bas mot, il passera entre 1h et 4h pour le réaliser.
- Évolution. Le changement implique une différence de comportement. En plus du correctif, la description précise du nouveau résultat est nécessaire. Les temps de développements sont plus importants, entre 2 et 5 jours.
- Migration applicative. Le changement d’un applicatif avec un upgrade de version est un cas complexe. En effet, modifier la version d'une application implique de RE-vérifier TOUS les échanges entrants et sortants. Il faut monter un projet pour gouverner cela.
- Mise à jour du middleware d’interconnexion. La mise à jour de l'outillage ETL, ESB ou API Management implique de revérifier TOUS les échanges des n applications pour lesquels il coordonne et orchestre tous les échanges entrants et/ou sortants. Un tel changement dans la couche de transport des échanges de données elle-même représente le cas de complexité maximal. Le coût humain est ici gigantesque.
Concrètement, les évolutions sont menées par des équipes projets multiples et nombreuses. Les charges sont proportionnelles aux impacts sur les applications sources et les cibles.
En synthèse, 2 groupes de personnes sont nécessaires : les développeurs de flux et les sachants techniques pour les tests fonctionnels. Les gains sont énormes par rapport à ces activités non structurées et non outillées.
Notre démarche vise à réduire les actions de ces équipes au plus stricte minimum afin de gagner en productivité et en efficacité.
Avec la console EFR, facilitez la supervision des échanges de données
Pour rappel, la console de supervision EFR, couvre l'entièreté du scope de la supervision des échanges en :
- observant l'exécution d'un échange,
- déterminant les sources, les cibles attendues,
- indiquant l'état de l'échange,
- captant le contenu des échanges,
- rejouant des échanges.
Elle vous permet de garder le contrôle de vos résultats obtenus, en environnement de production, mais aussi sur les précédents, recette ou préproduction.
Tous ces éléments de supervision sont la base du constat lors des tests de non-régression. Ils sont à comparer : résultat de référence versus le résultat post-test.
Un module de Tests de Non-Régression qui étend la supervision
Avec le module de tests de non-régression, vous étendez vos actions de supervision avec les 2 dimensions nécessaires :
- la dimension jeux de tests de référence,
- la dimension des résultats obtenus.
Soit vos jeux de tests sont extraits de la production, soit ils sont extraits de nouveaux scénarios en cours de construction. Vous constatez et vous sélectionnez vos jeux de tests.
Le schéma suivant illustre la démarche proposée avec EFR : superviser, tester puis comparer.
Avec EFR, la supervision est au service des tests. Les 2 activités sont intégrées pour une efficacité accrue.
EFR, une démarche nouvelle pour tester vos flux de données
Au final, avec ce module de TNR, EFR vous propose un socle complet de tests pour vos équipes de développeurs et vos équipes fonctionnelles.
Vous optimisez le travail des équipes métier en réduisant leurs actions. Leur productivité opérationnelle est accrue. Ils ne reproduisent plus, quand ils exécutent, des tests de non-régression.
Nous avons organisé un webinaire sur le sujet. Dans cette vidéo de 15 minutes, découvrez comment notre outil de gestion des flux optimise vos phases de tests.
EFR, une console intégrée au service de la productivité opérationnelle de vos équipes
Les résultats opérationnels constatés par nos clients sont :
- une réduction de 50 % des délais de Tests d’Intégration,
- une réduction de 80 % des charges réalisés par les équipes métier,
- une augmentation du rythme de déploiement des flux de données.
