What does it mean to test an EDI platform?
Before going further, our first step should be to define the different testing activities. In the software testing field, there are two main “test” activities, which also apply to EDI platforms: validation tests and regression tests.
Validation consists in ensuring that changes or fixes made to its EDI platform match the specifications of these changes. The goal is to answer the question: is the implementation of the changes correct? For example, does this new mapping correctly implement the associated business rule?
Regression tests are here to ensure that changes introduced in its EDI platform have not resulted in unwanted behavioral changes on existing features. The goal is to answer the question: does my EDI platform continue to work properly after implementing the changes? For example, Are all my existing flows behaving as expected? We may also want to check that the non-functional aspects of the platform (performance, load, security) are still correct.
Which bugs can we encounter in an EDI platform?
Depending on the context, it is more or less frequent to make changes to its EDI platform. The cases justifying it are nonetheless numerous: adding a new partner, modifying a business rule, updating its ERP or WMS, migrating from an EDI solution to another one or changing a server.
Testing these changes before going live is essential to detect:
- possible functional or non-functional problems
- the impacts of these changes on existing flows and associated partners
These test activity will make it possible to take corrective measures that will avoid loss of information that could disrupt the supply chain or the invoicing. It can also detect partners that might be involved by changes in flows (mapping, communication), to prevent changes to be made on their side before the go-live.
Should we test an EDI platform?
It is possible to classify EDI platforms into 3 categories. The following classification is proposed by GS1 (in french):
- EDI Web: the platform is hosted by a provider, and not integrated into the IS of the company (no direct connexion to the ERP for example). Specific needs are developed by the provider for B2B exchanges.
- ASP (Application Service Provider): the EDI platform is hosted and managed by a service provider. It integrates into the IS of the company. The provider carries out the development of needs specific to the company, whether for integration into the IS as for B2B exchanges.
- EDI in situ: the company manages the development, maintenance and infrastructure of its EDI platform.
In these different cases, the test activities are not the same. For an EDI Web solution, it is only necessary to check the flows to make sure they are functionally correct. Performance, load, safety and other aspects of robustness are ensured by the service provider.
In the case of an ASP EDI, the test needs will be greater. As for the Web IDE, it will be necessary to make sure that the business rules are correctly implemented, and in addition that the EDI integrates correctly with the various elements of its IS. Performance, load, safety and other aspects of robustness are ensured by the service provider.
Finally, for an in situ EDI, it will be necessary to carry out further tests. In addition to business rules and integration, there is also a need to ensure that the EDI platform meets non-functional needs (performance, load and security).
In which situations do you test your EDI platform?
There are several situations that require you to test your EDI platform:
- A migration from one EDI platform to another or an update (upgrade / upgrade) of its EDI software package.
- A functional modification of a part of its EDI platform (business rule, addition or modification of partner).
- A change in one or more application(s) of its IS integrating with its EDI, such as ERP, WMS or CRM.
- A change in the hardware environment (server, OS) or network (firewall) of its EDI platform.
In the case of an EDI migration or a major update of the software package of its EDI platform, it is important to ensure that the new EDI platform will behave similarly to the previous one from a functional point of view (data treatment, communication) and from a non-functional point of view (performance and load support).
For a functional modification of the EDI platform, it will first be necessary to check that the addition or the changes are functionally correct in relation to the specifications of the business. Then, it must be ensured that the changes do not have side effects on the other flows and mappings. This last case is very dependent on the architecture of the platform: if there is shared code or business rules in the mapping, then we must ensure the absence of regression for all the impacted flows.
A change in the IS (ERP upgrade, WMS addition, CRM migration) can also have impacts on incoming and outgoing flows. We will seek in this case to ensure that the EDI platform always integrates correctly in the IS.
Finally, an update of the hardware and network environment of the EDI platform requires ensuring that the new hardware has no negative impact on overall performance (response time, load, security) or on connections used by flows.
By boosting new customers acquisition, optimizing the supply chain, or reducing data processing costs, EDI enables businesses to stay competitive and grow faster. As long as the EDI platform is still operational and efficient!
Testing the EDI platform is therefore essential to ensure that EDI messages will continue to be properly processed, regardless of the changes made before a new release. Depending on the challenges and the maturity of the team in charge of EDI flows, it may be necessary to start using tools to test your EDI platform effectively. This will reduce the costs associated with these activities, improve the quality of the EDI platform and increase the productivity of the development teams.