The ERP software market is big business, with the global market value predicted to exceed US$50billion in 2024. (Source: Statista Market Insights 2023)
An integral part of day-to-day operations within the manufacturing, distribution, construction, healthcare, logistics and government sectors, ERP software is essential to the smooth running of a wide variety of organisations.
With most major players delivering software updates on a quarterly or bi-annual basis, the installed base is faced with the choice of regular code-current projects (a concept Oracle has named continuous adoption), less frequent “major” upgrades or falling behind the current release and missing out on opportunities to improve functionality, security, and cost efficiency. Whichever route they choose, there is an element of risk involved.
Why should we test?
On the surface, the answer seems pretty straightforward. We test to mitigate risk. To prevent errors passing downstream into the ERP production environment and creating havoc. Of course, the reality is somewhat more complex. Functional and performance testing is essential for many reasons, not least of which is the inherent complexity of ERP systems. They comprise multiple modules, draw data from multiple points and integrate with a wide variety of business systems. The complex dependencies between these elements means even small changes to the base code can have ripple effects throughout the business.
Testing isn’t just about identifying and eliminating bugs. It contributes to a variety of business imperatives. Ensuring systems function as predicted and integrate properly with data sets is critical, but so are data protection and regulatory compliance. The halo effect of well tested and maintained systems extends to user acceptance, employee morale and bottom-line financial savings.
What should we test?
When organisations undertake an ERP software upgrade or update (ESU), they have varying degrees of control over what updates they choose to take and when. Updates to standard objects tend to go relatively smoothly, but changes to custom code can be more challenging. The larger your custom footprint, the more complex the technical retrofitting becomes, and the more testing is required.
With multiple dependencies, it can be difficult to identify exactly what objects have been affected by an upgrade or update. Testing is time consuming and can account for more than 50% of the overall project resource, so defaulting to a “test everything” stance is simply not cost effective. The ability to forensically analyze the impact of an ESU will save a huge amount of time and effort over the duration of any project.
How should we test?
Significant advances in test automation have transformed the way organisations carry out functional testing. While it may prove difficult to eliminate manual testing entirely, it is possible to significantly reduce the time and effort required for testing through automation.
Automation adds value throughout the testing lifecycle, from the creation of test scripts to the scheduling and execution of tests. Automation allows testing to take place unattended and eliminates the risks associated with manually repeating tests. Once automated, your test catalogue can be organized and your test results fully documented, allowing for detailed audit and analysis.
