4 Recommendations for Successful ERP Testing
In my blog 5 Challenges when Testing in ERP Projects, I described the challenges that many organisations encounter when planning and managing ERP testing. This article covers my recommendations on how those challenges can be addressed.
Addressing ERP Testing Challenges
Recommendation 1 – Test Plan
It’s crucial that testing is considered and planned early in the project in order to fit into the overall project plan. Consider the scope of the implementation, the number of integrations and the level of customisation. These factors will help determine the time required for testing. Executing a risk assessment to determine the business processes with the potential to cause the most disruption if they are not working properly will help to prioritise tests and the amount of time to be allocated.
At the planning stage, it’s also important to understand the different types of tests that need to be included in the plan and the purpose of each. During the build process, the vendor’s software developers and consultants will customise or configure the ERP system and perform the initial unit tests which cover individual transactions or functional modules at the lowest level. Once the functionality is delivered to the project team a series of functional and end-to-end tests are carried out to establish that the system supports the business processes as agreed in the design phase of the project. Establishing the number of cycles of these tests that will be performed is a key part of the test plan. The plan will also need to factor in time for user acceptance testing and potentially for performance testing.
It is vital to allow time in the test plan, not only for carrying out the tests, but also for resolution of the issues that the test processes will identify.
Recommendation 2 – Clear Test Scope and Scenario Identification
Functional, end-to-end and user acceptance testing should all be guided by defined and documented scripts, which are designed to ensure that the ERP solution is adequately tested against the agreed design. It is important that the scripts cover the full project scope and that they are detailed enough to allow for rigorous testing, without becoming so complex that they become difficult to execute and manage. One way to ensure that the script coverage is complete, is to start by defining test scenarios which set out the key steps in the business processes that are in scope. Usually, it makes sense to start by documenting the “happy path”, which is the most common version of each business process and then considering the variations to each process that can occur. The main focus for testing should be the happy path scenario and the more significant variations. It is important that people who really understand the business in detail are involved in this process. Once the scenarios are defined, then scripts can be documented to cover each one.
Recommendation 3 – Supporting the Test Team
The success of an ERP project depends significantly on the ability of the chosen system to effectively support the business processes that are in scope. Ultimately, the organisation that is implementing the ERP solution is responsible for testing that it meets expectations. Therefore, it is vital to ensure that the team selected for this role has the skillset and time to do it properly and that if there are gaps that the team is adequately supported. In most projects the test team is responsible for development of the test scripts as well as the testing activity. While most project team members will have good knowledge of the planned future state processes and ERP system design by the time they need to start documenting scripts and testing, not everyone will have the ideal skills required, such as a logical mindset, attention to detail, thoroughness and patience. In these situations, or where there are resource availability issues, it may make sense to think about supplementing the internal team with external testers and/or business analysts. As external resources, they will not have knowledge of the business, but they will usually have a very good understanding of the ERP system and the skills required to perform testing effectively and can make a big difference to the quality and efficiency of the test processes.
Recommendation 4 – Test Management
There are a number of strands to test management that often cause confusion in ERP projects and it’s worth clarifying the approach to each early in the project. Firstly, a decision needs to be made about whether or not there should be a dedicated test manager. In smaller projects, or those with limited functional or technical scope, the ERP project manager can usually manage testing in conjunction with the other elements of the project. In larger projects it often makes sense to appoint a test manager who will report to the ERP project manager and take responsibility for development of the detailed test plan, test scenarios and scripts and management of test execution.
It is also important to decide on the tool(s) that will be used to capture test results, manage issues and report on test progress. The choices here tend to range from Excel spreadsheets to dedicated test management software applications. The latter can offer excellent out-of-the -box capability but for smaller projects may be too expensive and complex to use. Excel spreadsheets are cheap and flexible but they are prone to data errors and issue tracking and reporting capability needs to be built from scratch.
Finally, many people are attracted by test automation tools, which offer the capability to run tests automatically and therefore in theory reduce the amount of manual testing effort. In reality, test scripts still need to be developed and it takes significant effort to set up tests in such tools. Given the cost and complexity involved, this is usually worthwhile only in projects where there is likely to be a lot of regression testing (for example in complex multi-phase implementations).
This blog was written by Ursula Browne, Managing Partner at Lumenia. For further information please send an email to Ursula Browne.
