An EDI project can be about adding a new partner, changing business rules, or migrating the platform. In any case, to complete the project on time, it will be necessary to set up some test procedures leveraging some tools:

  • test case management (test description, test data)
  • automation of test execution
  • reporting of test campaign results

Several parameters must be taken into account to properly select these tools. Here is a list of questions to consider.

How many different flows?

If there are few flows, which do not change often, a spreadsheet is enough to manage its test repository (associated with flows) or do the reporting. In addition, launching tests by hand is not very time consuming. On the other hand, when the number of flows and the frequency of the modifications become too important, it is necessary to use more advanced tools which allow to store the test data, to manage the history, to execute automatically the tests and to propose advanced reporting.

Does testing take a lot of time?

If the time required to run the tests becomes too important, then it will be necessary to provide tools to the team to execute the tests automatically. If test execution does not need to be automated, then a tool that only manages the test repository will be sufficient.

What are the test skills in-house?

Will the people using the test infrastructure have technical or functional profiles or both? For the functional profiles, one will prefer simple tools, requiring little skills in development. If a QA team is already present in the enterprise, then the integration of EDI-specific tools into the test environment will also be considered.

What is the management policy for IT developments?

Depending on whether the test activities are internalized or outsourced, this may have an impact on the choice of a cloud or on-premise solution. With external providers, it may be more interesting to take tools available online.

It is also necessary to consider the policy of the company compared to open-source or proprietary software. Both solutions have their advantages and disadvantages. If you are focusing on open-source tools, you need to assemble several tools (for example a test data management tool with a test framework and a reporting solution) and make specific developments (such as writing libraries or test scripts) because a solution dedicated to EDI testing does not exist. It is then possible to create a test environment that exactly meets its needs, but it is necessary to allocate resources to maintain it (specific hardware, updating of tools, modification of the functionalities of the test environment to accompany a functional change of the IS …).

A proprietary solution can provide a complete test environment, which can be EDI-specific (such as Spindev). If the solution is hosted in the cloud, the costs of updates and hardware are optimized. The disadvantage of such solutions is that they sometimes offer less flexibility and that one can see need to adapt its processes to its tools.

What infrastructure is available for testing?

Depending on access to test environments, data management policy, availability of hardware, a cloud or on-premise solution may be more appropriate. The confidentiality of test data is also a factor to consider: if workflow data is used for test cases, it may contain confidential information that one wishes to keep in its IS. An on-premise solution is then more relevant, or it is necessary to anonymize its test data.

What kind of budget, and what amount available?

In general, setting up a test environment is an investment with an ROI that is not always obvious. This is particularly the case for its EDI platform. It is therefore important to look at the savings that will allow such a solution, by analyzing the costs associated with testing activities and the consequences of the lack of tests. Some of the costs to consider include the following questions:

  • What is the time spent by teams testing the EDI platform?
  • What is the time spent correcting the bugs that were introduced in production?
  • What is the time spent by the teams to monitor production after a go-live?
  • What are the financial impacts of a production bug (penalties, loss of sales, etc.)?

These different costs will then be compared with the investment and operational cost of using tools.

Testing an EDI platform is essential to ensure that regardless of changes made before a new release, EDI flows will continue to be properly processed. Depending on the issues and the maturity of the team in charge of EDI flows, it may be necessary to provide tools to the EDI team. Selecting the right testing tools is an important step and deserves a reflection on different axes that are mentioned above.