Congratulations! You spent a small fortune acquiring the latest and greatest test tools—now what?
New generation automated test tools for ERPs are often sold under the marketing theme of “Anyone can use them without technical knowledge,” and “All you do is point, click, drag, and drop when using our test tools.” The truth is nothing is that simple and there is a learning curve for implementing and maintaining a test tool no matter how simple a marketing or sales team makes it appear.
Enterprise Resource Planning (ERP) systems require lots of testing with both manual and automated test tools when that are heavily customized, configured, rebuilt to look and feel like old legacy systems, and interfaced with other applications running on the web or other home-grown tools. To test large, complex, highly configured ERPs with automated test tools, it is often necessary to have technical and coding expertise to develop automated test scripts for end-to-end ERP business scenarios, such as order-to-cash, hire-to-retire, and purchase-to-pay scenarios. The typical ERP functional consultant or subject matter expert (SME) is not equipped to learn an automated test tool on the fly. At least not well enough to test and validate business rules and other test conditions for complex end-to-end scenarios with heavy customizations and integration points with non-ERP applications.
Below is a roadmap designed to help companies and government agencies navigate the landscape of deploying and effectively maintaining automated test tools within their ERP environments.
A test tool has the potential to provide your organization with a repeatable test script that can be replayed in multiple environments with different sets of data, but not every process or business scenario within your organization is suitable for automation. A business scenario is suitable for test tool automation if it is mission critical to the production environment, time consuming to execute manually, requires verification of multiple GUI objects and calculations, or involves participation from more than one business analyst or SME. The project team consisting of SMEs, business analysts (BAs), and system architects will need to decide what processes should be automated. Test tools over the medium and long run are supposed to save an organization money and pay for themselves over time.
There are a few good heuristics to calculate whether automating a process is feasible from a financial perspective. One is to estimate the number of times per quarter a process is executed manually, for instance, as part of production support (regression testing). Other heuristics include how long it takes to run the process in total number of man-hours per year, how critical the process is to the business, and how much it currently costs to run a process manually by executing test steps, reporting test results, obtaining screen captures, and executing different sets of data.
For example, at a chemical company running an ERP solution, we estimated that a production-support functional consultant was spending at least 50 percent of his time (about 1,000 man hours a year) conducting ERP manual testing. This testing was very repetitive, time consuming, error prone, and lacked robust test result documentation. It was also very reliant on this employee. If he was out sick or on vacation, no one else in the organization had the same level of knowledge to test the process manually. We automated this process and determined we could compress and shrink the overall manual testing that the employee conducted by up to 90 percent. After the test scenarios were automated, all the manually executed test scripts could be executed unattended with automatically created test logs and notifications in one hundred hours for the entire year. This was a significant time savings that allowed the test tool to pay for itself.