Suivant la fréquence de modification de sa 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. En effet, on atteint rapidement des limites d’efficacité avec les tableurs et les consoles des plateformes EDI. Voyons dans cet article quels sont les types d’outils disponibles pour gérer ses tests, les exécuter et produire des rapports d’exécution.

GESTION DES TESTS

Tester sa plateforme EDI demande de créer et de maintenir des cas de tests. Ces tests vont en général avoir des attributs associés : nom, description, fichiers de données, liens vers de la documentation fonctionnelle, etc. Afin de gérer correctement ces données, il peut être nécessaire de s’outiller, mais les besoins seront différents suivant les types des tests.

Tests Unitaires

Les tests unitaires (TU) 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.

Tests de Plateforme

Les tests de plateforme (TP) 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.

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.

Tests de bout en bout

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 :

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.

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. 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, EDIFACT, 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.

Tests de bout en bout

Ces tests 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 ces tests avec les mêmes outils que les TP.

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.

Maintenant que nous avons décrit les différents types d’outils nécessaires aux tests des projets EDI, nous étudierons dans un prochain article les paramètres à prendre en compte pour bien choisir parmi les outils disponibles.

Share