Qu’il s’agisse de l’ajout d’un nouveau partenaire, d’une modification de règles métier ou d’une migration, un projet EDI n’aura toutes les chances d’être terminé en temps et en heure que si l’on met en place une démarche de tests s’appuyant potentiellement sur plusieurs outils permettant :

  • la gestion des cas de test (description du test, données associées au test)
  • l’automatisation de l’exécution des tests
  • le reporting des résultats des campagnes de tests

Il faut prendre en compte plusieurs paramètres pour bien sélectionner ces outils. Voici une liste de points à considérer.

Combien de flux différents ?

S’il y a peu de flux, qui ne changent pas souvent, un tableur est suffisant pour gérer son référentiel de tests (associés aux flux) ou faire le reporting, et lancer ses tests à la main est peu chronophage. Par contre, quand le nombre de flux et la fréquence des modifications deviennent trop importants, il est nécessaire d’utiliser des outils plus avancés qui vont permettre de stocker les données de test, gérer l’historique, exécuter automatiquement les tests et proposer des solutions de reporting avancées.

L’exécution des tests prend-elle beaucoup de temps ?

Si le temps nécessaire pour l’exécution des tests devient trop important, il faudra alors s’équiper d’outils permettant de jouer les tests automatiquement. Si l’exécution des tests n’a pas besoin d’être automatisée, alors un outil qui ne gère que le référentiel des tests sera suffisant.

Quelles sont les compétences en test en interne ?

Est-ce que les personnes qui vont utiliser l’infrastructure de test ont des profils techniques, fonctionnels ou les deux ? Pour les profils fonctionnels, on préférera des outils simples d’utilisation, nécessitant peu de compétences en développement. Si une équipe QA est déjà présente dans l’entreprise, alors on considérera également l’intégration des outils spécifique à l’EDI dans l’environnement de test plus global.

Quelle est la politique de gestion des développements informatiques ?

Suivant si les activités de test sont internalisées ou externalisées, cela peut avoir un impact sur le choix d’une solution cloud ou on-premise. Avec des prestataires extérieurs, il peut être plus intéressant de prendre des outils accessibles en ligne.

Il faut également considérer la potitique de l’entreprise par rapport aux logiciels open-sources ou propriétaires. Les deux solutions ont leurs avantages et inconvénients. Si l’on s’oriente sur des outils open-source, il faut alors assembler plusieurs outils (par exemple un outil de gestion des données de test avec un framework de test et une solution de reporting) et effectuer des développements spécifiques (comme écrire des librairies ou des scripts de tests) car une solution dédiée aux tests EDI n’existe pas. Il est alors possible de créer un environnement de test qui répond exactement à ses besoins, mais il faut dédier des ressources pour le faire vivre et évoluer (matériel spécifique, mise à jour des outils, modification des fonctionnalités de l’environnement de test pour accompagner un changement fonctionnel du SI…).

Une solution propriétaire peut proposer un environnement de test complet, et qui peut être spécifique à l’EDI (comme Spindev). Si de plus la solution est hébergée dans le cloud, les frais liés aux mises à jour et au matériel sont optimisés. L’inconvénient de ce genre de solutions est qu’elles offrent parfois moins de flexibilité et que l’on peut voir besoin d’adapter ses processus à ses outils.

Quelle infrastructure est disponible pour les tests ?

En fonction de l’accès aux environnements de test, à la politique en matière de gestion des données, à la disponibilité de matériel informatique, une solution cloud ou on-premise peut être plus adaptée. La confidentialité des données de test est également un facteur à considérer : si l’on utilise les données de flux de production pour des cas de test, elles peuvent contenir des informations confidentielles que l’on souhaite conserver dans son SI. Une solution on-premise est alors plus pertinente, ou alors il faut rendre anonyme ses données de test.

Quel type de budget, et quel montant disponible ?

De manière générale, mettre en place un environnement de test est un investissement, dont le ROI n’est pas toujours évident. C’est le cas en particulier concernant sa plateforme EDI. Il faut donc bien regarder les économies que vont permettre une telle solution, en analysant les coûts liés aux activités de test et aux conséquences du manque de tests. Parmi les coûts à considérer, on se posera entre autres les questions suivantes :

  • Quel est le temps passé par les équipes à tester la plateforme EDI ?
  • Quel est le temps passé à corriger les bugs qui ont été introduits en production ?
  • Quel est le temps passé par les équipes à surveiller la production après une MEP ?
  • Quelles sont les impacts financiers d’un bug en production (pénalités, perte de CA…) ?

On comparera alors ces différents coûts avec le coût d’investissement et opérationnel lié à l’utilisation d’outils.

Tester sa plateforme EDI est indispensable afin de garantir qu’indépendamment des changements effectués avant une nouvelle mise en production, les flux EDI continueront d’être correctement traités. Suivant les enjeux et la maturité de l’équipe en charge des flux EDI, il peut être nécessaire de s’outiller pour tester sa plateforme EDI efficacement. Sélectionner les bons outils de test est une étape importante et mérite une réflexion sur différents axes que nous avons évoqués ci-dessus.

Share