Pourquoi les tests d'intégration déterminent ce qui échouera après la mise en production
Une intégration est une connexion qui transfère des enregistrements entre deux systèmes qui n'ont jamais été conçus pour communiquer. Une commande passée sur une boutique Adobe Commerce doit arriver dans SAP sous une forme que le service financier peut facturer. Un niveau de stock dans SAP doit atteindre la boutique avant qu'un client n'achète un article qui n'est plus disponible.
Les tests d'intégration vérifient que cet échange fonctionne correctement avant de commencer à traiter de vraies commandes. Cela ressemble à des tests logiciels ordinaires avec davantage d'éléments mobiles, mais la plupart de ces éléments appartiennent à quelqu'un d'autre.
Lorsqu'une équipe fait l'impasse sur ces tests, le service informatique n'est pas le premier à s'en apercevoir. L'entrepôt, le service client et le service financier s'en rendent compte à la fin du mois :
- Une commande jamais rencontrée par le flux : un avoir ou une livraison partielle atteint SAP sous une forme non prévue par le mappage. Le flux s'arrête et le client n'est pas facturé jusqu'à ce que quelqu'un s'en aperçoive.
- Un flux de stock qui échoue silencieusement : la boutique affiche la disponibilité de la veille pendant vingt minutes, et les préparateurs de commandes cherchent des articles déjà vendus.
- Une place de marché qui a modifié un champ : Amazon commence à exiger un attribut que les données produit n'ont jamais envoyé, rejette les annonces et les produits disparaissent du canal.
- Un pic de charge non anticipé : un flux testé à dix commandes par heure en reçoit quatre mille lors du premier grand jour de soldes et expire, laissant les commandes en attente sans surveillance.
Rien de tout cela n'est exceptionnel. Chacun de ces scénarios aurait pu être testé à l'avance. La plupart des équipes ne le font pas, car la moitié des systèmes impliqués ne leur appartiennent pas et ne permettent pas d'expérimenter.
Pourquoi les intégrations ne peuvent pas être testées comme des logiciels ordinaires
L'environnement de test du fournisseur peut ne pas exister. S'il existe, il peut contenir des données vieilles de trois ans qui ne ressemblent en rien à celles utilisées actuellement. Tester dans un environnement différent de celui de production apporte moins de garanties qu'il n'y paraît.
Les intégrations modifient également les choses lors de leur exécution. Le premier test crée la commande, utilise un numéro dans une séquence ou déplace le stock ; le même test ne peut donc pas être simplement relancé. Le répéter implique de réinitialiser les systèmes, ce qui est généralement impossible, ou de générer de nouvelles données à chaque fois. Les conditions les plus importantes à tester sont aussi celles que personne n'autorisera. Un fournisseur ne mettra pas son système hors ligne pour permettre à l'équipe de tester sa gestion des erreurs. Un transporteur ne ralentira pas une API sur demande. Ces scénarios sont donc simulés ou ignorés.
Une condition ne peut jamais être testée. Un fournisseur peut modifier un champ sans prévenir personne, et ce changement n'a pas encore eu lieu au moment où le plan de test est rédigé. Pour le détecter, l'équipe a besoin de surveillance et journalisation. Les tests valident un flux avant la mise en service. La surveillance indique à l'équipe ce que le trafic réel lui fait subir par la suite. Tout ce qui se trouve entre les deux dépend d'une seule chose : savoir si l'environnement de test était suffisamment proche de la production pour être fiable.
Pourquoi l'environnement de test est le point de blocage des tests d'intégration
La majeure partie des efforts consacrés aux tests d'intégration système porte sur l'environnement, et non sur les tests eux-mêmes. Lorsque chaque connexion repose sur du code personnalisé, un environnement de test implique d'exécuter une seconde copie de ce code, pointée vers les bacs à sable (sandboxes) des fournisseurs disponibles, et maintenue en phase avec la production alors que les deux parties évoluent.
C'est cet entretien qui provoque le décalage des environnements de test. La version testée ne correspond plus à la version en cours d'exécution, et les tests ne prouvent plus rien.
Configurer les flux sur une couche d'intégration partagée élimine ce problème. La même définition de flux s'exécute dans les deux environnements. Elle pointe vers des points de terminaison de test dans l'un et des points de terminaison réels dans l'autre, seule la configuration diffère. Les bacs à sable des fournisseurs ne s'en trouvent pas améliorés, mais l'équipe cesse de déployer autre chose que ce qu'elle a testé.
Les équipes gèrent cela de trois manières aujourd'hui. Elles construisent un environnement parallèle complet, ce qui est exhaustif mais coûteux à maintenir à jour. Elles testent en production avec des enregistrements sélectionnés avec soin, ce qui fonctionne jusqu'à ce que l'enregistrement choisi s'avère crucial. Ou bien elles simulent chaque système externe, ce qui est rapide mais ne teste que ce que l'équipe suppose que le fournisseur enverra. Une plateforme d'intégration en tant que service (iPaaS) est la quatrième option, et la seule qui élimine le problème d'environnement au lieu de le contourner.
Comment une plateforme d'intégration facilite les tests d'intégration
Une iPaaS est une plateforme unique à laquelle chaque système se connecte une seule fois, au lieu de se connecter directement les uns aux autres. Elle héberge les flux qui déplacent et remodèlent les données entre eux. Comme chaque flux est centralisé, une équipe peut le pointer vers des points de terminaison de test ou réels sans rien reconstruire.
Cela rend quatre choses possibles sur la plateforme d'intégration Alumio :
- Un flux, deux environnements : le même flux configuré s'exécute contre des points de terminaison de test dans un environnement de test et contre des points réels en production, de sorte que l'équipe déploie exactement ce qu'elle a vérifié
- Détail au niveau du message : l'iPaaS Alumio enregistre le contenu de chaque message et l'endroit où il s'est arrêté, permettant à l'équipe de corriger la faille réelle au lieu de la deviner
- Rejeu : Le stockage au sein de l'iPaaS Alumio conserve ces messages, permettant à un flux corrigé d'être relancé contre la commande qui l'avait fait échouer
- Promotion contrôlée : le contrôle de version et le déploiement par étapes permettent de mettre en production une modification de manière délibérée, et non en modifiant ce qui est déjà en cours d'exécution
L'iPaaS Alumio propose également un Outil d'inspection. Il affiche côte à côte les entrées et les sorties de chaque étape de transformation, permettant ainsi à une équipe de tester une partie d'un flux sans avoir à exécuter l'intégralité de l'intégration. Ces fonctionnalités fonctionnent de la même manière pour chaque flux, ce qui permet à la deuxième intégration de réutiliser l'approche de test de la première.
Ce qu'une véritable stratégie de test d'intégration apporte à une entreprise
Une couverture complète est inatteignable, et un plan de test conçu comme tel est soit malhonnête, soit interminable. L'objectif utile est d'établir une liste claire : les chemins que l'équipe a correctement couverts, ceux qu'elle a seulement simulés et ceux qu'elle n'a pas pu atteindre du tout. Une équipe qui connaît ses zones non testées peut les surveiller spécifiquement et réagir rapidement, ce qui est bien plus efficace que de croire à tort que tout a été testé.
Une plateforme d'intégration permet de tenir cette liste à jour. Elle centralise le flux testé et le flux déployé, conserve un historique de chaque message et permet de vérifier une correction en utilisant la commande qui a initialement causé l'erreur.
L'entreprise bénéficie de mises en service avec moins de surprises, d'échecs expliqués par des données réelles plutôt que reconstitués a posteriori, et de la confiance nécessaire pour modifier un système connecté sans que cela ne soit perçu comme un risque pour le projet.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
