Risk Based Feedback Model For Software Testing

As a (performance) test engineer, it pains me when senior management and development teams look down upon us and say, “After all, it’s just testing!” But the comforting thought that I have is, “despite what they say, we are still here.. Aren’t we?”

It is an age old truth, “To err is human”. So as long as there is human intervention, mistakes are bound to happen. So, that’s where we come in. Software engineering is by no means an exception.

Now, if we implicitly accept the fact that there will always be a degree of risk (inherent/residual) associated with software at any given phase of it’s lifecycle, then testing is merely a way to ensure that the risks are within acceptable limits. That’s why testing will never become obsolete. Technologies may change, infrastructure may change, and the way we test may change. But we will still have to test it, none the less.

Please note: I am not demeaning the software developers or the work they do. For, if they do not develop stuff, we will have nothing to test J But the point here is, no matter how awesome developers are, it is our job to still validate their product and certify it is fit for deployment.

Ok, circling back to the topic, if we assume there is always a risk associated with the software life cycle, we can actually map the each phase of the lifecycle, in terms of risks alone. Now, what I am chalking out here is designed from a testing perspective alone. But it can very well be extrapolated to other phases of the software lifecycle.

The differentiating factor of this model is that, it is an evolving process, where the software risks are reduced with each iterative step via a feedback mechanism.

The model I drew up is classified in to 3 sections. Namely:

• Risks Before Testing
• Risks During Testing
• Risks After Testing

The below picture is an overview of the Risk Based Feedback Model For Software Testing

Within the Risk Before Testing Section:

The Requirement Gathering phase can be looked upon as the phase where we try and identify the risks that might occur due to this new change/requirement. We name it as Risk Identification Phase.

This then feeds in to the Risk Assessment Phase, which has been equated to the test planning phase. Here we design and plan for various testing activities that must be carried out to validate the presence of risks.

We then move to the next section – Risk During Testing Section:

The plans chalked out in the previous phase are executed here. So, the actual testing phase is equated to Risk Mitigation Phase in this model.

This takes us to the final section – Risks After Testing Section:

We term the next phase as Risk Coverage phase. This is equated to the Analysis and Reporting phase. Here we validate the effectiveness test coverage and certify if all the risks identified, have been checked and certified.

The final phase of within this section is the Risk Documentation Phase.  This is equivalent to the Knowledge Base Creation phase. Here the residual risks post testing and learning from this activity are documented.

This model additionally comes with a Feedback loop. This Risk Documentation Phase feeds in to the next iterative cycle’s Requirement Gathering/Risk Identification Phase. The learning from previous iteration will help improve the requirement gathering activities. We term this as Risk Prediction Phase. This implicitly feeds in to the actual Risk Identification Phase to reduce risks during the life cycle and this iteratively progresses.

Voila! Risk Based Feedback Model - describes the whole test life cycle in terms of risks.