by Pat Neary

I was chatting with a customer last week about how she was using test automation to reduce the time and effort involved in functional testing for JD Edwards EnterpriseOne.

After we’d talked, I was convinced that payroll was a great use-case for automated testing products. I’ve not had much recent experience of working with payroll systems myself, so I was fascinated to hear how she was using automated testing within this environment.

What prompted her interest in test automation in the first place? She explained that in the “bad old days” she would have to perform a minimum of eight payroll runs, simply to get the database to a point where it was possible to run a basic pass/fail test.

Not only was this a manual, time consuming task, but is was also a risky process. As committed as you might be on the first run, by the eighth time your enthusiasm is bound to wane.

Our customer had been doing an excellent job of building out a comprehensive catalogue of test scripts, covering a range of functional areas; including finance, procurement and payroll. What was most interesting, was how she was using a test automation tool to prepare data, to stage data and to seed various test environments.

The accuracy of the automated test program enabled the organisation to satisfy itself that its implementation was fit for purpose. In addition, the test automation tool was being used to schedule and automate data entry and run scheduled batch jobs, quickly and efficiently.

With the automation solution in place, our customer was able to schedule payroll runs to execute overnight, with no need for human intervention. When she returned in the morning, she could manually kick-off the tests and observe them as they executed successfully.

There is still a perception amongst the JDE community that test automation requires specialist staff or complex code changes to be effective; or that it is time consuming and difficult to scale. This real-world implementation of test automation is one of many examples that disprove this theory.

I appreciate some of you might not have had the best experience with test automation in the past, especially when creating test scenarios or testing custom objects. Some solutions may have been considered too restrictive, or too expensive.

Times have changed. A test automation solution should be easy to use, even for non-technical end-users. We don’t believe it should require specialist coding skills or labour-intensive ‘record and playback’ test set-up.

If you’d like to find out more about a test automation solution that works as well on custom code as it does ESUs, allows multiple test scripts to be queued, pin-points reasons behind test failures and is available on a pay-as-you-go subscription basis, CLICK HERE.