POURQUOI ET COMMENT TESTER SA PLATEFORME EDI - Spindev
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
POURQUOI ET COMMENT TESTER SA PLATEFORME EDI
Temps de lecture Audience
20 minutes Directeurs des SI
environ Managers équipe EDI/B2B
Managers QA
40%
Dans ce livre blanc, vous allez découvrir ou redécouvrir
pourquoi il est important de tester sa plateforme EDI,
et comment le faire en fonction du type de plateforme
dans votre entreprise. Les activités de test sont
indispensables pour garantir que la plateforme EDI ne
va pas perturber les flux de l’entreprise. Ces activités Proportion du
de test représentant entre 30% et 40% du temps total temps passé sur
consacré aux activités de développement logiciel, il est
les activités de
donc important de sélectionner les bonnes méthodes
et les bons outils afin d’être le plus efficace possible. test lors des
projets
Seront abordés : informatiques
les enjeux concernant la qualité des plateformes EDI
les différents types de test à mettre en place
l’environnement indispensable à leur bonne exécution
les outils nécessaires et comment les sélectionner
Tout cela, afin de trouver les problèmes le plus tôt et le plus efficacement possible. Une
fois opérationnelle, une solution de test doit permettre aux équipes EDI d’augmenter leur
efficacité, en passant plus de temps sur le management des partenaires que sur le debug
et la recherche de régression.
C’est toute votre entreprise qui deviendra plus performante :
gagnez et conservez vos clients en intégrant plus efficacement, sans bug ni
régression, leurs flux EDI
prenez un temps d’avance sur vos concurrents, en implémentant plus rapidement des
changements fonctionnels dans vos flux EDI (par exemple la livraison le week-end
dans la logistique).
-1-
© 2019 Spindev SAS. Tous droits réservés
Table des matières
L'EDI AU CŒUR DE LA PERFORMANCE DES ENTREPRISES 3
POURQUOI TESTER SA PLATEFORME EDI ? 4
QUE SIGNIFIE "TESTER" SA PLATEFORME EDI ?
QUELS BUGS PEUT-ON RENCONTRER DANS UNE PLATEFORME EDI ? 5
FAUT-IL TESTER SA PLATEFORME EDI ? 7
DANS QUELLES SITUATIONS TESTER SA PLATEFORME EDI ? 8
COMMENT TESTER SA PLATEFORME EDI ? 9
QUAND TESTER SA PLATEFORME EDI ?
QUELLES SONT LES DIFFÉRENTES CATÉGORIES DE TEST D'UNE PLATEFORME EDI ? 11
QUELS MÉTHODES ET OUTILS ? 13
UNE PLATEFORME EDI PLUS PERFORMANTE 22
TESTER SA PLATEFORME EDI AVEC SPINDEV 23
-2-
© 2019 Spindev SAS. Tous droits réservés
L'EDI AU COEUR DE LA
PERFORMANCE DES
ENTREPRISES
Les échanges de données
informatisées (EDI) sont
indispensables à la performance
des entreprises. Ils permettent
d’accélérer les transactions entre
partenaires commerciaux,
en automatisant des processus critiques comme la préparation de
commandes, l'avis d'expédition, la facturation ou les ordres de transferts
monétaires.
En conséquence, la plus grande attention doit être portée à la qualité de la
plateforme EDI, car le moindre problème peut avoir des conséquences
extrêmement dommageables :
retard ou erreur de livraison
supply chain désorganisée
traçabilité perdue
facturation retardée
-3-
© 2019 Spindev SAS. Tous droits réservés
POURQUOI TESTER SA
PLATEFORME EDI ?
Avant d’aller plus loin dans les motivations et les méthodes pour tester efficacement sa
plateforme EDI, il convient de bien définir les différentes activités de test.
QUE SIGNIFIE “TESTER” SA PLATEFORME EDI ?
Dans le test informatique, on distingue deux activités de “test”, qui s’appliquent
également pour les plateformes EDI : la validation et la non-régression.
La validation consiste à s’assurer que des évolutions ou corrections apportées à sa
plateforme EDI sont correctes par rapport aux spécifications de ces changements.
L’objectif est de répondre à la question :
Est-ce que l’implémentation des changements est correcte ?
Par exemple, est-ce que ce nouveau mapping respecte la règle métier associée ?
La non-régression consiste à s’assurer que les changements introduits dans sa
plateforme EDI n’ont pas entraîné de modifications de comportement non désirées sur
les fonctionnalités existantes. L’objectif est de répondre à la question :
Est-ce que ma plateforme EDI continue de fonctionner correctement suite à
l’implémentation des changements ?
Par exemple, est-ce que tous mes flux existants se comportent comme attendu ? On
peut également vouloir vérifier que les aspects non-fonctionnels de la plateforme
(performance, charge, sécurité) sont toujours corrects.
-4-
© 2019 Spindev SAS. Tous droits réservés
POURQUOI TESTER SON EDI ?
QUELS BUGS PEUT-ON RENCONTRER DANS UNE
PLATEFORME EDI ?
Il est plus ou moins fréquent d’apporter des modifications à sa plateforme EDI : pour
ajouter un nouveau partenaire, modifier une règle métier, mettre à jour son ERP ou
WMS, migrer de plateforme ou encore changer de serveur.
Tester ces changements avant la mise en production (MEP) est indispensable pour
détecter :
d’éventuels problèmes fonctionnels ou non-fonctionnels
les impacts de ces changements sur les flux existants et les partenaires associés
Cette activité de test va permettre de prendre des mesures correctives qui éviteront
des pertes d’informations, susceptibles de perturber la supply chain, la logistique ou
la facturation. Cela peut également permettre de détecter les partenaires qui
pourraient être impliqués par des changements dans des flux (mapping,
communication), afin de les prévenir des modifications à apporter dans les flux en
amont de la MEP.
-5-
© 2019 Spindev SAS. Tous droits réservés
POURQUOI TESTER SON EDI ?
Plusieurs types de bugs peuvent être rencontrés dans une plateforme EDI, qui ont des
conséquences plus ou moins importantes sur les activités de l’entreprise.
TYPE DE EXEMPLES ET
DÉTAILS
PROBLÈME CONSÉQUENCES
Erreur fonctionnelle : en logistique et transport, un
Une traduction peut entraîner des erreurs mauvais traitement des données de poids (variable,
fonctionnelles
Une ou de robustesse
erreur fonctionnelle :
peut impliquer un traitement forfaitaire) peut entraîner une mauvaise facturation,
incorrect de la donnée reçue. ou une rupture dans la supply chain.
Problème dans un
Une erreur de robustesse peut impliquer des
mapping messages perdus, non traités ou pire, l’arrêt de la Erreur de robustesse : une erreur de programmation
plateforme. dans un mapping peut entraîner une exception
logicielle, entraînant elle-même l’arrêt de la
plateforme EDI.
Une mise à jour d’une application dans le SI peut
entraîner des changements d’interface, qui vont Un upgrade de SAP R/3 vers SAP S/4HANA
Problème d’intégration impliquer des modifications dans l’EDI. s’accompagne d’un changement dans les interfaces
avec le SI (ERP, CRM, De même, une nouvelle règle métier dans un WMS avec l’ERP.
ou un ERP peut impliquer des changements dans les Les données transmises depuis et vers SAP
WMS, TMS...)
données échangées (segment en plus ou en moins peuvent être perdues ou corrompues.
par exemple).
Un certificat AS2 qui change, des identifiants de
connexion mis à jour, une adresse de serveur Les messages depuis ou vers les partenaires ou des
modifiée, un firewall upgradé sont autant de cas composants du SI ne peuvent plus être reçus ou
Problème de pour lesquels les échanges électroniques avec une émis.
communication plateforme EDI peuvent être perturbés et pour Cela peut entraîner des retards, des pertes de
lesquels il faut effectuer des tests après chaque commande ou de facturation...
changement.
Une plateforme EDI en relation directe avec une
Il est important de s’assurer que sa plateforme EDI a
application de front-office (logiciel de caisse par
les performances attendues. Parmi les points à
Problème de exemple) se doit de répondre rapidement. Si un
considérer, il y a le temps de traitement des
performance vendeur veut communiquer un état des stocks ou
mappings, ou encore le temps de réponse pour des
un délai de livraison à un client, il faut pouvoir
requêtes.
fournir la réponse instantanément.
Lors des fêtes de Noël ou du Black Friday, le
Une plateforme EDI doit pouvoir supporter les pics nombre de messages échangés avec des clients
Problème de charge de charge, afin de ne pas perdre de message ou de peut varier considérablement. La plateforme EDI
ne pas retarder le traitement de l’information. doit supporter une telle charge afin de garantir la
continuité dans le business de l’entreprise.
Malgré toutes les précautions qui peuvent être
prises pour assurer la sécurité du SI (DMZ, firewall, Il y a plusieurs types d’attaques possibles, telles
etc.), la plateforme EDI doit rester accessible de que le vol d’informations sensibles pour l’entreprise
l'extérieur du SI de l'entreprise. De plus, elle est (facturation, prix d’achat de fournitures...), ou
Problème de sécurité utilisée pour l’échange des données très sensibles encore une attaque en denial of service (les pirates
pour l’entreprise. Il est primordial de s’assurer que le envoient un très grand nombre de connexions afin
plus haut niveau de sécurité est garanti afin d’éviter que la plateforme s’écroule sous le nombre de
de se faire dérober des informations confidentielles requêtes).
et de garantir sa continuité opérationnelle.
-6-
© 2019 Spindev SAS. Tous droits réservés
POURQUOI TESTER SON EDI ?
FAUT-IL TESTER SA PLATEFORME EDI ?
Il est possible de classer les plateformes EDI en 3 catégories. La classification
suivante est celle proposée par GS1(1) :
EDI Web : La plateforme est hébergée par un prestataire, et non intégrée dans le SI
de l’entreprise (pas de lien électronique avec l'ERP par exemple). Les besoins
spécifiques sont développés par le prestataire pour les échanges B2B.
EDI ASP (Application Service Provider) : La plateforme EDI est hébergée et
managée par un prestataire. Elle s’intègre directement dans le SI de l’entreprise. Le
prestataire effectue les développements de besoins spécifiques à l’entreprise, que
ce soit pour l’intégration dans le SI comme pour les échanges B2B.
EDI in situ : L’entreprise gère les développements, la maintenance et
l’infrastructure de sa plateforme EDI.
Dans ces différents cas, les activités de test ne sont pas les mêmes. Pour une
solution EDI Web, il est uniquement nécessaire de recetter les flux pour s’assurer
qu’ils sont fonctionnellement corrects. Les performances, la charge, la sécurité et
autres aspects de robustesse sont assurés par le prestataire.
Dans le cas d’un EDI ASP, les besoins de test seront plus importants. Comme pour
l’EDI Web, il faudra s’assurer que les règles métier sont correctement mises en place,
et en plus que l’EDI s’intègre correctement avec les différents éléments de son SI. Les
performances, la charge, la sécurité et autres aspects de robustesse sont assurés par
le prestataire.
Enfin, pour un EDI in situ, il va falloir effectuer des tests plus poussés. En plus de ceux
concernant les règles métier et l’intégration, il faut également s’assurer que la
plateforme EDI répond bien aux besoins non-fonctionnels (performance, charge et
sécurité).
(1) https://www.gs1.fr/content/download/2603/18776/version/3/file/L%27EDI%20_%20mes%20premiers%20pas_2016.pdf
-7-
© 2019 Spindev SAS. Tous droits réservés
POURQUOI TESTER SON EDI ?
DANS QUELLES SITUATIONS TESTER SA
PLATEFORME EDI ?
Il y a plusieurs situations qui imposent de tester sa plateforme EDI :
Une migration d’une plateforme EDI vers une autre plateforme EDI ou une mise à
jour (montée de version/upgrade) de son progiciel EDI.
Une modification fonctionnelle d’une partie de sa plateforme EDI (règle métier,
ajout ou modification de partenaire).
Un changement dans une ou plusieurs application(s) de son SI s’intégrant avec son
EDI, telle que l'ERP, le WMS ou le CRM.
Un changement de l’environnement matériel (serveur, OS) ou réseau (firewall) de
sa plateforme EDI.
Dans le cas d’une migration EDI ou d’une mise à jour importante du progiciel de sa
plateforme EDI, il est important de s’assurer que la nouvelle plateforme EDI va se
comporter de manière similaire à la précédente, autant fonctionnellement (traitement
de la donnée, communication) que non fonctionnellement (performance et support de
la charge).
Pour une modification fonctionnelle de la plateforme EDI, il va falloir d’abord vérifier
que l’ajout ou les changements sont fonctionnellement corrects par rapport aux
spécifications du métier. Ensuite, il faut s’assurer que les changements n’ont pas
d’effets de bord sur les autres flux et mappings. Ce dernier cas est très dépendant de
l’architecture de la plateforme : s’il y a du code partagé ou des règles métier dans le
mapping, alors il faut s’assurer de la non-régression pour tous les flux impactés.
Un changement dans le SI (upgrade de l’ERP, ajout d’un WMS, migration du CRM) peut
aussi avoir des impacts sur les flux entrants et sortants. On va chercher dans ce cas à
s’assurer que la plateforme EDI s’intègre toujours correctement dans le SI.
Enfin, une mise à jour de l’environnement matériel et réseau de la plateforme EDI
nécessite de s’assurer que le nouveau matériel n’a d’impact négatif ni sur les
performances générales (temps de réponse, charge, sécurité) ni sur les connexions
utilisées par les flux.
-8-
© 2019 Spindev SAS. Tous droits réservés
COMMENT TESTER SA
PLATEFORME EDI ?
S’il ne fait plus de doute qu’il faut tester sa plateforme EDI, il faut bien définir la
stratégie à mettre en oeuvre pour le faire efficacement.
QUAND TESTER SA PLATEFORME EDI ?
Il convient de tester sa plateforme EDI avant chaque nouvelle mise en production.
Suivant les modifications apportées qui nécessitent une MEP, il pourra y avoir
différentes activités de test :
1 - LA VALIDATION
Cette phase est nécessaire en cas d'ajout d’un nouveau partenaire, d’une nouvelle
fonctionnalité ou d’une nouvelle règle métier, ou de modification d’un flux, d’une règle
de validation ou d’un mapping. Il faut valider l’ajout par une phase de test
exploratoire, durant laquelle le testeur va s’assurer que l’ajout ou la modification se
comporte comme attendu. Le testeur va
définir les différents cas de test en fonction
des spécifications du métier. Il veillera à bien
prendre en compte les cas aux limites, ainsi
que les cas d’erreurs : par exemple un
mauvais format de données ou des données
incomplètes.
-9-
© 2019 Spindev SAS. Tous droits réservésCOMMENT TESTER SA PLATEFORME EDI ?
2 - LES TESTS DE NON-RÉGRESSION
Il peut y avoir plusieurs cas nécessitant une phase de tests de non-régression :
Les ajouts ou modifications fonctionnelles décrites précédemment, s'ils ont
potentiellement des effets de bord sur d’autres fonctionnalités.
Par exemple, dans le cas de la modification d’un mapping utilisé par plusieurs
flux, il faudra s’assurer de l’absence de régression pour tous les flux
impactés. A contrario, un mapping utilisé par un seul partenaire pour un
unique flux qui serait ajouté ou modifié ne nécessitera pas de test de non-
régression sur les autres flux.
La modification du progiciel utilisé ou du matériel utilisé pour l’EDI.
Dans ce cas, il convient de s’assurer principalement de l’absence de
régression non-fonctionnelle : les performances, la charge et la sécurité sont-
elles toujours au niveau attendu ?
Une telle mise à jour peut cependant avoir un impact fonctionnel : il faut
parfois modifier des mappings existants suite à une modification de l’API de
la plateforme. Dans ce cas, il faut effectuer les mêmes activités de test que
celle décrite au point précédent.
Le tableau ci-dessous permet de décider dans quels cas il faut prévoir des activités de validation et de
tests de non-régression, en fonction des changements introduits avant une MEP.
CATEGORIE DE NON-
TYPE DE CHANGEMENT VALIDATION
TEST RÉGRESSION
Migration de
Changement de progiciel NON OUI
plateforme EDI Upgrade de version de progiciel NON OUI
Sans code commun NON NON
Nouveau mapping
Nouvelle règle de Avec code commun non modifié NON NON
validation
Avec code commun modifié NON OUI
Modification d'un
Sans code commun OUI NON
mapping Avec code commun OUI OUI
Sans modification de la plateforme EDI NON OUI
Changement dans le SI
Avec modification de la plateforme EDI OUI OUI
Changement matériel ou réseau NON OUI
- 10 -
© 2019 Spindev SAS. Tous droits réservésCOMMENT TESTER SA PLATEFORME EDI ?
QUELLES SONT LES DIFFÉRENTES CATÉGORIES
DE TESTS D’UNE PLATEFORME EDI ?
Avant de mettre en production des modifications, il faut tester la plateforme EDI
suivant différents aspects, afin de s’assurer de son bon fonctionnement. On distingue
2 catégories de tests, qui sont nécessaires dans le cas de certains changements
apportés à la plateforme EDI.
1 - LES TESTS FONCTIONNELS
Il s’agit de s’assurer que la plateforme EDI respecte ses spécifications
métier.
Les règles de validation des données sont-elles correctement implémentées ?
Les mappings sont-ils corrects ? Par exemple, les données sont-elles correctement
transformées ?
Les messages sont-ils correctement routés dans le SI ou vers le bon partenaire ?
2 - LES TESTS NON-FONCTIONNELS
Il s’agit de s’assurer que la plateforme EDI respecte les spécifications qui ne sont pas
liées aux règles de gestion.
La performance de la plateforme : est-elle capable de recevoir, traiter et répondre
à un message dans un temps imparti ?
La charge de la plateforme : est-elle capable de recevoir, traiter et répondre à un
certain de nombre de messages dans un temps contraint ?
La sécurité de la plateforme : est-elle capable de bloquer les connexions non
désirées ?
- 11 -
© 2019 Spindev SAS. Tous droits réservésCOMMENT TESTER SA PLATEFORME EDI ?
Le tableau ci-dessous permet de décider dans quels cas il faut prévoir des tests fonctionnels et non-
fonctionnels, en fonction des changements introduits avant une MEP.
CATEGORIE DE NON-
TYPE DE CHANGEMENT FONCTIONNEL FONCTIONNEL
TEST
Migration de
Changement de progiciel OUI OUI
Le tableau ci-dessous
plateforme EDI permet
Upgrade dede décider
version de progicieldans quel cas il faut prévoir des tests
OUI OUI
fonctionnels et non-fonctionnels, en fonction des changements introduits avant une
Sans code commun OUI NON
MEP Nouveau
: mapping
Nouvelle règle de Avec code commun non modifié OUI NON
validation
Avec code commun modifié OUI NON
Modification d'un
Sans code commun OUI NON
mapping Avec code commun OUI NON
Sans modification de la plateforme EDI NON OUI
Changement dans le SI
Avec modification de la plateforme EDI OUI OUI
Changement matériel ou réseau NON OUI
- 12 -
© 2019 Spindev SAS. Tous droits réservésCOMMENT TESTER SA PLATEFORME EDI ?
QUELS MÉTHODES ET OUTILS ?
1 - QUELS TYPES DE TESTS ?
Il faut tester durant tout le cycle de développement d’un projet EDI. Pour cela, il y a
différents types de tests qui seront créés, maintenus et exécutés dans des
environnements différents, par des personnes ayant des rôles différents.
TESTS UNITAIRES (TU)
Ce sont les tests de plus bas niveau, dont l'objectif est de s’assurer qu’une
fonctionnalité spécifique, comme un mapping ou une règle de validation,
fonctionne comme attendu.
Comme cette catégorie de test se focalise sur un sous-ensemble fonctionnel du
logiciel, ces tests sont généralement écrits dans le langage de programmation
mis à disposition de la plateforme. Ils sont aussi créés, maintenus et exécutés
par les développeurs, avant de promouvoir leurs modifications (dans un outil de
versioning de code par exemple, ou sur l’environnement de développement de la
plateforme).
Les TU sont principalement fonctionnels et n’ont pas pour objectif de tester la
performance ou la charge de la plateforme EDI.
TESTS DE PLATEFORME (TP)
Ces tests se focalisent sur plateforme EDI dans sa globalité, mais isolée du
reste du SI et de ses partenaires. L’objectif est de vérifier que la plateforme rend
bien le service attendu sans qu’elle soit connectée au SI.
C’est généralement avec les TP que l’on va tester si les flux sont correctement
reçus, transformés et redirigés. Pour ce type de test, il faudra donc soumettre
des données en entrée de la plateforme et évaluer les résultats à sa sortie.
C’est également au niveau des TP que les tests de performance, de charge et de
sécurité vont être effectués.
- 13 -
© 2019 Spindev SAS. Tous droits réservésCOMMENT TESTER SA PLATEFORME EDI ?
TESTS DE BOUT EN BOUT (E2E)
Avec ces tests, il s’agit de s’assurer que la plateforme EDI s’intègre
correctement dans le SI de l’entreprise et avec ses partenaires. Il faut donc
tester des scénarios métier afin de s’assurer que l’information est correctement
traitée dans les différentes étapes de son flot :
Est-ce que la commande est bien relayée au WMS, au CRM et à l’ERP ?
La facture émise par l’ERP est-elle correctement envoyée à son destinataire ?
Ces tests sont généralement très fonctionnels : les scénarios sont écrits par des
experts métier pour pouvoir jouer et rejouer les différents cas liés aux activités
de l’entreprise.
Les tests de E2E permettent également de valider l’intégration correcte de la
plateforme EDI dans le SI : identifiants de connexions aux autres composants,
connexions passant les différents éléments de protection (firewall ou encore
l'API gateway).
Ils permettent enfin de s’assurer que le déploiement de la plateforme s’effectue
correctement : espace disque ou droits d’accès entre autres.
- 14 -
© 2019 Spindev SAS. Tous droits réservésCOMMENT TESTER SA PLATEFORME EDI ?
2 - QUELS ENVIRONNEMENTS DE TEST ?
II est important d’avoir accès à un environnement dédié au test de sa plateforme EDI,
quelle que soit la plateforme utilisée. Cet environnement sera utilisé pour faire la recette
des changements et si besoin les tests de non-régression. Pour bien faire, il faut au
moins 3 environnements de développement et de test, répondant aux besoins des
différents types de test définis précédemment :
Développement, utilisé pour les tests unitaires (TU)
Cet environnement n’a pas besoin d’avoir de données de la production à jour pour
exécuter les TU. La plateforme EDI peut être en isolation de tous les autres
composants du SI.
Intégration, utilisé pour les tests de plateforme (TP)
Cet environnement n’a pas forcément besoin d’avoir de données de la production à
jour pour exécuter les TP. La plateforme EDI peut être en isolation de tous les autres
composants du SI.
Pré-production, utilisé pour les tests E2E
Cet environnement doit reproduire le plus fidèlement possible l’environnement de
production, avec une image fidèle de ses différents composants : ERP, TMS, CRM.
Les données de chaque composant doivent être régulièrement mises à jour afin de
s’assurer que les tests sont effectués avec des données et des traitements
fonctionnels le plus près possible de la production.
Il faut noter qu’il est parfois compliqué, voire impossible de mettre en place un
environnement de pré-production pertinent et régulièrement à jour. Par exemple si la
plateforme EDI s’intègre avec un grand nombre de partenaires qui ne mettent pas à
disposition d’environnement de test (dans la
logistique par exemple), ou si certains
éléments du SI ne peuvent pas être dupliqués
(AS/400). Dans ce cas, les TP et TU prennent
plus d’importance : il faut mettre plus
d’efforts sur chacun de ces types de tests, en
particulier pour les tests de non-régression.
- 15 -
© 2019 Spindev SAS. Tous droits réservésCOMMENT TESTER SA PLATEFORME EDI ?
3 - QUELS OUTILS DE TEST ?
Suivant la fréquence de modification de la plateforme EDI, sa criticité et son type, il
peut devenir nécessaire de s’outiller pour la gestion, l’exécution et le reporting de ses
tests. On atteint rapidement les limites d'efficacité avec les tableurs et les interfaces
graphiques des plateformes EDI pour gérer ses tests et les exécuter.
GESTION DES TESTS
Tester sa plateforme EDI demande de créer et de maintenir des cas de tests,
pour lesquels il peut y avoir des données associées, des fichiers de description,
des liens vers de la documentation fonctionnelle.
Il peut être nécessaire de s’outiller pour cela. Cependant, les besoins seront
différents suivant la catégorie des tests :
Les tests unitaires sont gérés directement dans le code.
Les données et les descriptions des tests doivent être à côté du code, et vivre
avec lui. La gestion des tests se fait donc avec la gestion du code, et ne
nécessite pas d’outil particulier, si ce n’est un éventuel framework de test dans
le langage de programmation de la plateforme.
Les tests de plateforme se concentrent sur les tests de non-régression.
Ils sont donc beaucoup plus stables que les TU. Il faut gérer les données de
test (données à envoyer, données de référence à comparer avec ce qui est
transformé), les scripts de tests (enchaînement des commandes à exécuter) et
les configurations pour les tests (définition des plateformes de test,
identifiants de connexion).
La gestion des cas de test peut se faire, dans les cas extrêmement simples,
avec des fichiers dans des répertoires et un tableur. Cette solution atteindra
très rapidement ses limites s’il faut gérer un historique, modifier et exécuter
régulièrement les tests.
Dans la majorité des cas, il est
nécessaire d’utiliser des outils plus
puissants de gestion des tests, pour à
la fois stocker les données de test et
décrire des cas de tests : des
frameworks de tests ou des solutions
commerciales peuvent être utilisés
pour décrire l’exécution des tests.
- 16 -
© 2019 Spindev SAS. Tous droits réservésCOMMENT TESTER SA PLATEFORME EDI ?
A cela, il faut également ajouter des outils de gestion de données.
Concernant les tests de performance et de charge, on peut se baser sur des
briques open-source telles que JMeter et Gatling, mais il reste encore à mettre
en place l’infrastructure nécessaire pour stocker les données de test, qui
peuvent être très importantes.
Les tests de bout en bout sont basés sur des cas métier.
Ils ont les mêmes besoins d’outillage que les tests de plateforme pour gérer des
configurations, des données et des scripts de tests. La différence avec les TP
est que certaines actions des tests vont s’effectuer sur d’autres composants du
SI, comme l'ERP ou le CRM, mais cela ne change fondamentalement pas la
structure des tests et les mêmes types d’outils de gestions pourront être
utilisés. On peut donc se reposer sur les mêmes outils que les TP.
EXÉCUTION DES TESTS
Comme pour la gestion des tests, les besoins d’outillage diffèrent suivant les
catégories de test :
Les tests unitaires
Ils sont exécutés par la plateforme EDI lors de la “construction” (ou encore
compilation) d’une nouvelle version de la plateforme. Aucun outil particulier
n’est nécessaire, si ce n’est un
framework de test dans le langage de
programmation de la plateforme.
Les tests de plateforme
Que ce soit pour les tests fonctionnels
ou non-fonctionnels, ils doivent
s’exécuter en prenant en compte les
problématiques de connexion à la
plateforme. Il faut donc sélectionner
des outils qui supportent les protocoles utilisés par les différents partenaires :
FTP, SFTP, HTTP, Email, etc. Il est possible d’utiliser des frameworks open-
source comme Cucumber ou Robot Framework, mais dans ce cas il faudra
développer les différents types de connexion en se basant sur d’autres
composants open-source.
- 17 -
© 2019 Spindev SAS. Tous droits réservésCOMMENT TESTER SA PLATEFORME EDI ?
Il faut ajouter à ces développements des éléments permettant la validation des
résultats obtenus lors de l’exécution des tests fonctionnels, afin de prendre en
compte la diversité des formats de fichier potentiels (iDoc, HL7, XML, JSON,
etc).
Il est également possible de détourner l’utilisation de JMeter pour tester ces
connexions, mais ce composant n’est pas prévu pour la validation
fonctionnelle. Par contre, il est parfaitement adapté pour les tests de
performance et de charge.
Enfin, il existe des solutions commerciales, telle que Spindev, qui combinent la
gestion des différents types de connexion, ainsi que le support natif des
différents types de fichier.
Les tests de bout en bout
Les tests E2E ayant comme objectif de vérifier le fonctionnement global d'une
fonctionnalité particulière, il pourrait être tentant d’utiliser l’interface graphique
des outils en bout de chaîne pour certaines étapes.
Par exemple, on pourrait vouloir vérifier une mise à jour dans un ERP en utilisant
son interface web. Si cela peut convenir pour un petit nombre de tests, cette
méthode sera rapidement trop lente sur des volumes plus importants de tests.
Quant à vouloir automatiser les tests via l’interface graphique, c’est prendre le
risque d’avoir des tests qui seront fragiles car dépendants d’une interface qui
est amenée à changer régulièrement. La bonne pratique est donc d’exécuter les
tests E2E avec les mêmes outils que les TP.
- 18 -
© 2019 Spindev SAS. Tous droits réservésCOMMENT TESTER SA PLATEFORME EDI ?
REPORTING
Il est important de pouvoir suivre les résultats de ses tests dans le temps,
principalement pour les tests de plateforme et les tests de bout en bout.
Les tests unitaires ayant pour vocation de vivre avec le code, ils sont modifiés en
même temps que lui, et doivent toujours être sans erreur avant un éventuel
déploiement des modifications dans le code. Le besoin de reporting et de suivi est
donc extrêmement limité, et peut être couvert par les frameworks de test unitaire.
Les résultats des TP et des tests E2E ont vocation à être échangés entre les
équipes : par exemple entre les équipes QA ou de développement et les équipes
métier. Cela peut être également le cas entre un prestataire EDI et son client.
Dans le cas où le nombre de flux
et de changements est faible, un
tableur peut suffire. Par contre,
avec le nombre de tests et de
mises à jour qui augmente, les
besoins de reporting se font
généralement plus importants. Il
sera par exemple utile de suivre
l’historique d’un test particulier ou
d’un sous-ensemble de tests.
Il peut devenir également nécessaire d’intégrer ces résultats de tests dans des
solutions de suivi plus globales ainsi que dans les outils de gestion de tickets de
l’entreprise. Il est dans ce cas indispensable d’utiliser des outils s’intégrant dans
l’usine logicielle de l’entreprise. Spindev propose un accès à sa plateforme via
une API REST, permettant son intégration avec les outils classiques des équipes
de développement.
- 19 -
© 2019 Spindev SAS. Tous droits réservésCOMMENT TESTER SA PLATEFORME EDI ?
4 - DANS QUELS CAS S’OUTILLER POUR SES TESTS ?
Il faut considérer plusieurs critères pour estimer la pertinence de s’équiper d’outils de
test pour sa plateforme EDI. Parmi ceux-ci :
Quel est le type de plateforme ? EDI Web, ASP ou in situ ?
Quelle est la fréquence des modifications et de MEP ?
Combien y a-t-il de tests ? Ce nombre sera très fortement corrélé au point
précédent, ainsi qu’au nombre de flux différents, de mappings, de partenaires et
de la complexité du SI.
Par exemple, pour une plateforme EDI Web, avec 2 modifications par an et moins de
50 mappings, il n’est a priori pas nécessaire de s’outiller. La gestion des tests pourra
se faire via un tableur par exemple, et la génération d’un rapport pourra se faire avec
un éditeur de texte ou dans le tableur directement. Enfin, l’exécution des tests se fera
manuellement, avec l’envoi de messages EDI via le portail web.
À l’opposé, une plateforme EDI in situ, modifiée plusieurs fois par semaine, avec
quelques centaines de mappings, nécessitera la mise en place d’une véritable
infrastructure de test, avec des outils adaptés pour gérer ses tests, les exécuter et
générer des rapports de MEP. En effet, il n’est plus possible d’exécuter les tests
manuellement, d’avoir un historique des modifications ou encore d’adresser
plusieurs environnements de tests.
Une solution comme Spindev est adaptée dans ce cas, car elle répond aux différents
besoins définis plus haut. Il est également possible d’assembler différentes briques
open-source ou propriétaires, néanmoins cela nécessite un investissement important
en développement sur des technologies pas forcément maîtrisées.
Le tableau ci-dessous propose des critères de décision pour s’outiller pour ses tests de
plateforme EDI.
COND. => Conditionnel
FRÉQUENCE DES Moins d'une Moins d'une fois Plus d'une fois
CHANGEMENTS fois par an par semestre par semestre
Nombre de tests < 50 >= 50 < 50 >= 50 < 50 >= 50
EDI WEB NON NON NON COND. COND. OUI
EDI ASP NON COND. COND. COND. OUI OUI
EDI in situ NON COND. COND. OUI OUI OUI
- 20 -
© 2019 Spindev SAS. Tous droits réservésCOMMENT TESTER SA PLATEFORME EDI ?
5 - COMMENT BIEN CHOISIR SES OUTILS DE TEST ?
Il faut prendre en compte plusieurs paramètres pour bien sélectionner ses outils de test.
Voici une liste de points à considérer :
Quelle plateforme EDI et quel nombre de flux différents ?
S’il y a peu de tests, qui ne changent pas souvent, un tableur est suffisant pour gérer
son référentiel de tests. Par contre, quand le nombre de tests 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 et
proposer des solutions de reporting avancées.
L’exécution des tests doit-elle être automatisée ?
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. 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.
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.
Quelle est la politique de gestion des développements informatiques ?
Si les rôles s’occupant des activités de test sont internalisés ou externalisés, 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.
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.
Quel type de budget, et quel montant disponible ?
Si le projet entre dans le cadre d’un budget de fonctionnement, on s’orientera vers de
l’abonnement, ou vers l’acquisition d’une licence logicielle pour un investissement.
- 21 -
© 2019 Spindev SAS. Tous droits réservésUNE PLATEFORME EDI
PLUS PERFORMANTE
En leur faisant gagner de nouveaux clients, en optimisant la supply chain ou réduisant
les coûts liés au traitement de données, l’EDI permet aux entreprises de rester
compétitives et de croître plus rapidement. À condition que la plateforme EDI soit
toujours opérationnelle et performante !
Tester sa plateforme EDI est donc 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. Cela permettra de diminuer les coûts associés à ces activités,
d’améliorer la qualité de la plateforme EDI et d’augmenter la productivité des équipes
de développement.
Photo by NASA on Unsplash
- 22 -
© 2019 Spindev SAS. Tous droits réservésTESTER SA PLATEFORME
EDI AVEC SPINDEV
Créée par des experts du test et de la qualité
logiciel, Spindev propose en SaaS une solution
complète dédiée au test des plateformes EDI.
Grâce à ses fonctionnalités de gestion, d’exécution
et de reporting des tests, les équipes EDI passent
moins de temps sur leurs activités de test, tout en
augmentant la qualité de leur plateforme.
Elles peuvent se concentrer sur l’ajout et la gestion
de nouveaux partenaires avec plus d’efficacité.
C’est toute l’entreprise qui en bénéficie en
devenant plus performante.
N’hésitez pas à nous contacter pour vous aider dans vos projets autour de la qualité et
des tests de votre plateforme EDI.
- 23 -
© 2019 Spindev SAS. Tous droits réservéshttps://spindev.io contact@spindev.io +33 (0)6 28 25 49 38
Vous pouvez aussi lire
