As your organization’s ERP system becomes more extensively integrated with both internal and external systems, the risk associated with testing updates escalates significantly if not handled properly.

Consider the scenario of inadvertently bombarding customers with emails during system testing. Such actions may result in customer dissatisfaction due to inbox overload, potentially driving them to seek alternatives. (It’s worth noting that sending emails is a form of integration, as it involves interaction with your email server.)

Similarly, envision the consequences of mistakenly routing large-scale production orders to your primary production line instead of conducting test orders.

Moreover, picture the ramifications of dispatching a substantial volume of purchase orders to multiple suppliers as part of testing procedures. Without realizing that these are test orders, suppliers may proceed to fulfill them, potentially leading to unnecessary complications.

How to avoid integration test accidents?

Ideally, any system being integrated should offer a dedicated test or sandbox environment for testing purposes. However, not all systems provide this feature, requiring test plans to accommodate both scenarios:

1. Systems with Test/Sandbox Environments: These environments facilitate seamless integration testing.
2. Systems without Test/Sandbox Environments: In such cases, integration testing should be avoided to prevent any adverse impacts.

A widely adopted best practice involves maintaining a distinct test environment for the ERP system. This allows for thorough testing of changes or updates before deployment to the live ERP environment. Depending on the ERP system in use, having a segregated test environment may be mandatory.

Test/sandbox environments available

The recommended approach for integrations is to ensure that integration endpoints, authentication information, and other relevant parameters are configurable. This allows for easy reconfiguration of integrations to point to test or sandbox environments.

However, this approach introduces challenges in maintaining consistency across environments.

In the test ERP environment, it’s essential to update configurations whenever the test ERP database is refreshed from the live environment. Failure to do so can result in data inconsistencies between the test ERP environment and the integrated system. It’s crucial to assess and document the potential impact of such inconsistencies on test integrations, enabling test plans to account for them.

For internal systems, synchronizing test environment data with the test ERP environment during database updates may be feasible. Nevertheless, this process may necessitate updates to the test environment’s configuration, thereby adding another layer of maintenance complexity.

Test/sandbox environments are not available

As previously mentioned, the best practice for integrations involves making them configurable, including controls to enable or disable each integration. In cases where no test or sandbox environment is available for integration, it’s essential to ensure that the integration is disabled.

Once more, this underscores the importance of configuration maintenance. It’s necessary for someone to disable the integration when the test ERP database is refreshed. This proactive approach helps prevent unintended interactions or disruptions caused by the integration operating in a test environment without corresponding data or resources.

Incorporating configuration updates into your test plans

It’s imperative to include the process of changing and verifying integration configurations in your test plans, especially within test cases involving integrations, including those triggering email communications. This ensures proactive measures to prevent integration mishaps.

For ERP systems offering the capability to export configuration parameters to a file, consider keeping this file in a secure location like a file server or SharePoint. Include a step in your test cases for importing this file after a database refresh. It’s acceptable to import the same configuration multiple times within a test plan. However, if repetition impacts the test plan’s integrity, consider adding a separate test case specifically for importing and confirming the configuration as the FIRST step related to that integration. Ensure the file includes configurations to disable the integration if necessary.

For ERP systems lacking the export/import feature, manual configuration adjustment is required. Document the necessary values to set or the steps to disable integrations within a dedicated test case.

If manual configuration proves impractical, reach out to Professional Advantage for potential assistance in automating this process.

What if my integrations are not configurable?

If your integrations lack configurability, it’s essential to engage with your system vendor(s) to address this limitation. Ensuring that a test environment can be configured to prevent communication with live systems is of paramount importance.

By initiating discussions with your system vendor(s), you can explore potential solutions or enhancements to enable configurability in integrations. This may involve requesting updates or modifications to the system to facilitate proper configuration management in test environments.

Maintaining the separation between test and live systems is crucial for safeguarding data integrity and preventing unintended consequences. Therefore, it’s imperative to collaborate with system vendors to implement appropriate configuration controls in your test environment.

How about email?

In many testing scenarios, ensuring that emails are sent to the correct recipients with accurate content is a crucial aspect of obtaining reliable test results.

Typically, there are two methods to conduct this testing without risking emails being sent to unintended recipients:

1. During the test ERP database refresh process, update all email addresses to a predefined set of safe email addresses. It’s essential to include a verification step in your test plan to ensure that the email addresses used are indeed safe.
2. Alternatively, you can establish a test email service that permits the sending of emails without forwarding them to the final recipients. Various such services are available at different price points, offering a viable solution for conducting email-related tests safely.

Conclusion

Safely conducting testing can pose challenges, especially when dealing with integrated systems that further connect to additional systems.

Incorporating configuration management into your test plans is essential, rather than relying on assumptions regarding proper configuration prior to testing initiation.

Additionally, establishing a well-defined scope for testing helps determine the extent to which further integrations should be disabled. For instance, when integrating with a POS system, it’s crucial to ascertain whether verifying product and pricing information transmission to the test retail/POS database suffices, or if propagation to a test POS terminal is also necessary.

Wishing you success with your testing endeavors.