5 Best Practices for better ERP Integration Testing

Testing is the most important part of an ERP project and the success of this phase significantly drives the overall success of the ERP project in terms of timelines, cost, meeting expectations and defect free design. We all know that all above lead to increase in spending in the project and in addition of the loss of opportunity to use ERP more effectively for the business growth, we end up reducing ROI of ERP. In this article, I wish to share the best practices that will help you to ensure that your integration testing is done in best possible manner.

• Never skip the pre-work: Before you jump to system integration testing, please make sure that –
• All end to end test scripts are ready
• All testers are identified and their dedicated testing windows frozen
• Testers are trained sufficiently to test their respective pieces
• Dedicated rooms are blocked for them to come and test the application with all integrations
• All in scope integrations should be ready before testing
• All components are unit tested successfully before integration testing
• Testing success factors and metrics is well defined and agreed beforehand
• 80% of data conversion is complete before integration testing
• Bulk of test data is ready and guidelines for creating more test data, are in place
• Legacy systems outages are not scheduled during integration testing window
• Daily testing handouts are prepared so that testers know their agenda for the day
• Defects identification is the key: The main objective for integration testing should be to identify the defects and while most of the focus should be on the test scenarios that are applicable in 90% of the cases but exceptions should also be given equal importance and a well communicated plan should be in place to handle these. Divide the whole exercise into 3 major parts:
• First will need only modular testing but will still complete the end to end scenarios involving single or a smaller set of modules
• Second will be end to end testing involving multiple modules covering all the related integrations and these scenarios are driven by business functions rather than application modules
• The third part is about trying to break the system which is more popularly called as negative testing where you need to test those scenarios when the system is expected to not give the desired results. For example, an order line for a hazardous material should get approved by compliance manager – this is expected behavior. The negative testing scenario here is to check if order lines with non hazardous material are also getting routed through compliance manager which is not expected
• Continuous Progress Reporting: Even a small time lost in integration testing can delay the whole project and also can defeat the whole purpose of testing due to following reasons:
• Testers not able to devote time in testing as planned
• The test scenarios are not complete
• System is not ready with the components on time
• Unplanned issues that prevent testing to continue on planned pace etc.

Due to this, it is very important that daily status reviews and progress dashboards are shared with all the key stakeholders and required actions can be taken on time to avert the delay and to maintain quality of testing. Also, daily defect tracking reports are required to be shared with all along-with the progress of the service provider team to resolve those issues. Faster resolution of those issues that have the potential to prevent further testing in one of more business functions will be facilitated if reporting dashboards are discussed with relevant stakeholders

• Defects resolution: Resolution of defects is as important as identification of defects during integration testing so the best practice is set-up dedicated rooms for technical team members who can provider real time help to the testers to resolve the defects as well as help them overcome training related issues so that testing can continue seamlessly
• Test results documentation: The best practice for documenting test results is the usage of a testing tool that can record the test scenarios, their results and can provide the ready to use progress dashboards. This will reduce the manual effort to compile the testing data and will also build a future repository of the test cases that can be used in further regression testing cycles during system enhancements or large application patches

Hope, the above best practices will help the organizations in completing their ERP integration testing cycles in much better way. In case of any questions, I can be reached by clicking here.