How much testing is too much testing?

(Source - CloudHire)

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 optimising 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 am talking about, here is a pro forma test framework including a generalised plan of attack:

Organisation 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.

1. 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.

2. 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.

3. 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 optimising a test regime, and every requirement is different. So, use this article is a guide not a firm view of problems you’ll face in your own operations.