Under time and budget pressure testing is an area project teams tend to shortchange. Periodicals are full of examples where testing shortcuts led to disastrous consequences, including actions that drove up costs, and drove down customer satisfaction.
My experience led me to embrace two rules for creating an ERP testing program:
- Specify test conditions as part of the design, and
- Do your tests with real data
Teams often wait until the ERP system is built to address how it will be tested. Then the testing team comes up with relevant test scenarios which were not previously considered. Testing fails to pass these scenarios creating rework and delays. Identifying how the solution will be tested during design provides the builders with a better understanding of how the system needs to work. It also improves the unit and integration testing that proceeds business acceptance testing. be tested during design provides the builders with a full understanding of how the system needs to work. Additional time spent identifying test scenarios during design will be more than made up many times over in subsequent phases. I’ve observed teams running behind schedule on data conversion work use fabricated test data instead of actual data. Using real data validates that the data conversion and clean up efforts are truly effective. People doing testing with fabricated data lose the ability to judge the results, invalidating the testing outcomes. Going into production with bad data or a poorly built system due to inadequate testing has immediate negative impacts on customers and operations, and longer term destroys the organizations confidence in the system.
