How much ERP testing is too much ERP testing?

While the title of this ERP article suggests ‘too much testing’; the inverse should apply, since as a practical matter, any failure to develop and execute proper pre-start tests will undoubtedly trigger larger problems later.

There are a host of reasons for this, however, at the top of the list is an inability to employ efficient expectation management; since if a technical team can’t, or won’t, ‘stress-validate’ a platform’s processes, datastores, and consequent stability, every follow-on business operation ends up being founded on shifting sand.

Consequently, a better question would be ‘are you optimizing your testing regimes’, and if not, ‘what can you do to ensure that your ERP routines are as efficient as possible.’ Here are some quick takes on how you can make sure this question is answered.

The Checklist:

Successful ERP testing is largely based on granular investigations into one or more integrations, modules, functional processes, datastore activities, and reporting routines. Consequently, in order to ensure that you’re not going to miss anything, check-listing is a handy way to keep all the moving parts rolling forward in the right direction. To give you a sense of what I’m talking about, here is a pro forma ERP test framework including a generalized plan of attack:

Organization and administration:

Dual-team test approach.
Core team – chartered to test regimes based on static software functions.

Implementation team – charted to test regimes driven by dynamic and/or tailored operations.
Specific test foci:

Functional
Record handling
Integrity
System utility
Security
Reliability
Adaptability
Scalability
Usability
Performance
Load measuring
Interface
Interoperability
Regression compliance
Infrastructure
Image
Installation
Parallel
Functional stress
Datastore stability
Datastore cross-checks
Datastore accuracy
Mobility compliance
Network compliance
Automation:

Give the deep list of test elements; at-large testing automation support needs to be applied in most, if not all, cases. While there are some naysayers who suggest that developing an automated test fabric is just as time-consuming as manual system tests themselves, there are three major advantages to the approach.

Efficiency

Either or both test group(s) can be applied strategically when resolving case specific elements. This advantage is apparent when one or more requirements call for iterative processes.

Replication/Reusability

Automated baselines are easily stored for re-use, while at the same time accommodating any new changes quickly, and with a minimum of muss and fuss.

Stability over time

Automated processes provide measurable stability over time. These code elements reduce error rates by eliminating human error.

Extension of life-cycles

Automation can be delivered highly-rigid requirement-sets, driven by zero-margin analytics. This capability can allow functions and feature-sets to be refined prior to a systems launch. In general, however, ‘why a system does what it does’ ends up producing operational confidence that in turn leads to reduced cost over time.   

As I said at the outset, this is a just pro forma approach to optimizing a test regime, and every ERP requirement is different. So, use this article is a guide not a firm view of problems you’ll face in your own operations.