Le test logiciel est un vaste domaine, avec une variété de méthodes et d’outils et une terminologie qui peut parfois être déroutante. Pour une équipe responsable d’une plateforme d’échanges B2B qui souhaite s’assurer en continu de la qualité de sa plateforme, il peut être difficile de se frayer un chemin dans ce domaine et de mettre en place les meilleures pratiques. Chez Spindev, notre expertise nous permet de faire des recommandations sur la manière dont les tests doivent être abordés.

Une plateforme B2B de type Axway, TradeXpress, Seeburger BIS etc. est constituée d’une interface graphique (IHM), d’interfaces de communications (API réseau) et d’un moteur de calcul. L’IHM propose en général plusieurs points d’entrée en fonction du profil de l’utilisateur : un éditeur de configuration/code pour le développeur de flux, des rapports et des logs pour la personne en charge de surveiller l’activité (monitoring) et un formulaire pour les partenaires qui souhaiteraient déposer des fichiers via une interface web. L’API quant à elle va écouter les messages entrants dans la plateforme via différents protocoles de communication. Enfin, le moteur est la partie de la plateforme B2B qui va effectuer les “calculs” (mappings, validation des données, routage des messages etc.).

tests plateforme B2B

Quels types de tests ?

Une plateforme B2B comprend de nombreux éléments à vérifier afin d’en évaluer la qualité. Ces éléments incluent les fonctionnalités, la performance, la sécurité, etc. Selon le contexte, le niveau d’attente pour chaque élément diffère, à l’exception de la couverture des fonctionnalités. La plateforme doit fonctionner conformément à ses spécifications. Les tests fonctionnels permettent de vérifier que c’est bien le cas.

Parallèlement, les tests fonctionnels sont regroupés en différentes catégories : tests unitaires, tests de plateforme et tests de bout en bout, pour ne nommer que les principaux.

types de tests

Nous pouvons définir ces types de tests :

  • Les tests unitaires sont les tests de plus bas niveau, dont l’objectif est de s’assurer qu’une fonctionnalité spécifique fonctionne comme attendu. Dans le cadre d’une plateforme B2B, il s’agira en général de tester qu’un mapping transforme correctement un fichier ou que la validation des données est correctement effectuée.
  • Les tests de plateforme testent la plateforme B2B de façon globale 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 mais sans qu’elle soit connectée au SI. 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.
  • Les tests de bout en bout permettent de s’assurer que la plateforme B2B s’intègre correctement dans le SI de l’entreprise (avec l’ERP, le CRM etc.) et avec ses partenaires.

Pour mieux comprendre la différence entre ces types de test, il est possible de les examiner sous un autre angle. Nous pouvons les classer en deux catégories : tests boîte noire et boîte blanche. Les tests boîte blanche supposent que l’on connaît la façon dont le développement a été fait et dans ce cas on se base sur le code pour tester. À l’inverse, dans le cas des tests boîte noire, on ne sait pas comment a été programmé l’élément à tester et on s’appuie sur les spécifications pour effectuer les tests.

tests boite noir et boite blanche

Le plus souvent, les tests boîte blanche sont écrits et lancés par les développeurs. Les langages et outils utilisés dépendent de la plateforme B2B (la plupart proposent un framework de test unitaire compris dans l’environnement de développement). Les tests boîte noire peuvent être écrits par les développeurs, les QA (quand il y en a !) ou les analystes métier. Ce sont les tests sur lesquels nous allons nous concentrer par la suite.

Prenons l’exemple d’un flux qui reçoit un message entrant en EDIFACT et le transfère, après validation et transformation des données, sous la forme d’un message iDoc à SAP. Voyons comment tester cet exemple avec un test de plateforme et un test de bout en bout.

Pour effectuer un test de plateforme, il vous faut soumettre un fichier d’entrée à la plateforme. Le mode opératoire varie d’une plateforme à l’autre, mais pour la plupart cela sera possible via un des modules de l’interface graphique. La terminologie et les étapes dépendent elles aussi de la plateforme utilisée, mais le principe reste le même, et les étapes devraient être :

  • Soumettre un fichier EDIFACT via le formulaire client
  • la plateforme B2B transforme l’EDIFACT en iDoc et l’envoie vers SAP
  • Vérifier que le fichier iDoc a le bon format et le bon contenu

Pour tester cet exemple de bout en bout, il faudra tout d’abord s’assurer que l’on dispose d’une plateforme SAP de test vers laquelle le flux peut être redirigé. Les étapes du test seront semblables, mais la vérification se fera dans SAP au lieu d’être faite en sortie de plateforme B2B :

  • Soumettre un fichier EDIFACT via le formulaire client
  • la plateforme B2B transforme l’EDIFACT en iDoc et l’envoie vers SAP
  • Vérifier que le SAP a correctement été mis à jour (commande ajoutée, informations mises à jour sur le client, etc.)

Mais rappelons-nous que la plateforme B2B expose aussi des API de communications qui sont les points d’entrée des flux (FTP, AS2, etc.). L’interface graphique est un moyen convivial pour un humain de tester la plateforme, mais les interfaces réseaux seront plus appropriées. En effet, envoyer un fichier EDIFACT à la plateforme B2B en passant par l’API réseau reproduira plus justement le comportement réel. Cela permet donc de tester la plateforme dans son ensemble (interfaces réseau et transformation avec les mapping). Cette méthode est aussi plus efficace car par la suite cela permettra d’automatiser les tests plus facilement. Nous vous conseillons donc d’utiliser ces interfaces comme point d’entrée principal pour vos tests boites noires.

différents types de tests d'une plateforme B2B

Combien de tests ?

Combien de types de messages d’entrée différents doivent être testés ? Autant que nécessaire pour couvrir correctement toutes les flux et mappings de la plateforme B2B. En outre, vous devez ajouter des cas aux limites qui n’ont pas forcément été imaginés dans la phase de spécification, mais qui sont susceptibles de se produire (segment manquant, donnée hors des limites définies, fichier XML mal formaté…).

Chaque flux testé nécessite une suite de tests spécifique utilisant des fichiers d’entrée spécifiques. De plus, tout bug fonctionnel observé (et corrigé !) doit être reproduit avec un test fonctionnel et ajouté à l’ensemble des tests existants. Cela signifie que vous allez probablement vous retrouver avec de nombreux tests. De ce fait, lorsqu’il faudra exécuter l’ensemble des tests dans le cadre d’une campagne de tests de non-régression, la durée totale d’exécution peut facilement atteindre  plusieurs heures, voir plusieurs jours.

À quelle fréquence effectuer les tests ?

Une fois que vous avez écrit un ensemble de tests fonctionnels, la question suivante est de savoir à quelle fréquence vous allez devoir les exécuter. Il y a des événements majeurs pendant lesquels il est évident qu’il faut tout retester (i.e. effectuer une campagne de tests de non-régression). C’est le cas lorsque vous migrez d’une plateforme B2B à une autre. C’est aussi le cas lors d’une mise à jour de la plateforme B2B (nouvelle version, patch de sécurité, etc.).

Il faudra aussi ré-exécuter tout ou partie des tests dans le cas où il y a une modification fonctionnelle dans la plateforme B2B (règle métier, ajout ou modification de partenaire). Dans ce cas, il faut tester la modification, et aussi les autres flux qui pourraient être modifiés par effet de bord.

Enfin, il y a les cas où il y a une modification d’application s’intégrant avec la plateforme B2B (ERP, CRM, WMS etc.) ou une modification de l’environnement matériel (serveur, OS etc.) de sa plateforme B2B. Dans tous ces cas, il y aura un gros effort de tests de non régression à effectuer.

Notez qu’un test fonctionnel qui échoue ne signifie pas nécessairement qu’il y a une régression fonctionnelle dans la plateforme B2B. L’échec peut être dû à un changement dans le fonctionnement attendu (par exemple le fichier iDoc en sortie change car SAP a été mis à jour et un nouveau format est attendu). Effectuer les tests aussi souvent que possible vous permettra de suivre (et de corriger) ces modifications très rapidement.

Automatisation ?

Cette exploration rapide des tests fonctionnels d’une plateforme B2B montre que vous devrez souvent exécuter de nombreux tests. Comme vous pouvez le sentir, cela ne sera pas possible sans automatisation. C’est ce que nous examinerons dans un prochain article, mais n’hésitez pas à laisser des commentaires sur ce que nous avons couvert ici.

Si vous recherchez déjà une solution d’automatisation de tests pour plateforme B2B, consultez ce que nous proposons et contactez-nous pour savoir comment elle pourrait répondre à vos besoins. Et pour rester à jour avec notre produit, suivez-nous sur Twitter et LinkedIn.

Share