The importance of testing safely

As your organisation’s ERP system gets more and more integrated with other systems—both internally and externally—testing updates becomes increasingly risky if not done right.

Imagine spamming your customers with emails as a result of system testing. They are unlikely to thank you for filling their inbox and may end up taking their business elsewhere. (And yes, sending emails is actually an integration, as you are integrating with your email server.)

Imagine sending large production orders to your main production line, when they were meant to be test orders.

Imagine sending a large number of purchase orders to multiple suppliers as part of testing. They will generally not know that these are test orders and are likely to act upon the request and fulfil them.

What does a typical map of integrated systems look like these days?

How to avoid integration test accidents?

Ideally, any system you are integrating with should have a test/sandbox environment you can use for testing. However, not all systems have this, so your test plan needs to consider both cases:

• Systems where there are test/sandbox environments to integrate with.
• Systems where there are no test/sandbox environments, and where no test integrations must happen.

Common best practice is to also have a separate test environment for your ERP system, within which you can test changes or system updates before they are deployed to your live ERP environment. Depending on which ERP system you are using, having a separate test environment can be mandatory.

Test/sandbox environments available

The best practice for integrations is to make integration endpoints, authentication information, etc., configurable. This makes it easy to reconfigure the integration to point to a test/sandbox environment.

The challenge in this case becomes one of maintenance, in both environments.

• In the test ERP environment, someone needs to make sure the configuration is updated any time the test ERP database is refreshed from the live environment.
• Data can become inconsistent between your test ERP environment and the integrated system. The potential impact this may have on the test integration must be assessed and documented so your test plans can take this into account. For an internal system, it may be possible to update the test environment data at the same time that your test ERP environment is updated. Once you do that, though, the test environment may have a configuration that also needs to be updated.

Test/sandbox environments are not available

As mentioned earlier, the best practice for integrations is to make them configurable, and this includes controls to enable or disable each integration. For an integration where no test/sandbox environment is available to integrate, care must be taken to make sure the integration is disabled.

Again, this ends up being a matter of configuration maintenance: someone will have to disable the integration when the test ERP database is refreshed.

Incorporating configuration updates into your test plans

Changing and verifying integration configuration should be part of your test plans, specifically in every test case that involves integrations, and that includes anything that sends emails. Only by including this configuration/verification step in the test cases can you start to proactively avoid integration accidents.

Depending on your ERP system, it may be possible to export the configuration parameters to a file, such that they can be imported again after a database refresh. If this is the case for your ERP system, keep the file in a safe place, such as a file server or SharePoint, and include a step in your test case for importing the file. It should not matter if you are importing the same configuration multiple times as part of a test plan, but if it does, it is better to add a separate test case for importing and confirming the configuration as the FIRST test that relates to that particular integration. This file should include a configuration that disables the integration if that is required.

If you don’t have the option of exporting/importing configuration parameters into your test ERP environment, you will need to do this manually. Add a test case that clearly documents which values need to be set where, or in the case of integrations that need to be disabled, document how to disable the integration.

If manually setting integration configurations is not a workable option for you, contact Professional Advantage and we may be able to assist in getting the process more automated.

What if my integrations are not configurable?

If your integrations are not configurable, please talk to your system vendor(s) to see what can be done about the situation. It is critically important that a test environment can be configured to not talk to any live systems.

How about email?

For a lot of testing, sending emails to the right email addresses and with the correct contents is an important part of the test results.

There are, generally, two ways to test this without risking emails being sent where they shouldn’t.

• As part of the test ERP database refresh process, update all email addresses to a set of safe email addresses. In this case, make sure your test plan contains a check to verify the email addresses are safe.
• The alternative is to set up a test email service that allows you to send emails without any of them being passed on to the final recipient. There are multiple such services available at different price points.

Conclusion

Testing safely can be a challenge, particularly when the systems you integrate with are in turn integrated with other systems, which are then integrated with yet other systems.

It is critical to have configuration management included as part of your test plans, rather than relying (or gambling?) on things being configured correctly before starting testing.

Also, having a clearly defined scope for what needs to be tested will help you determine how far down the rabbit hole you need to go before you disable any further integrations. For example, if you integrate with a POS system, is it enough to verify that the product and price information arrives in the test retail / POS database, or do you also need to see that it is propagated to a test POS terminal?

Good luck with your testing.