Blog

25 October, 2017

The Risk Mitigation Business

Introduction

So, what exactly is a “Risk”?

Businessdictionary.com defines a “Risk” as follows: –

“A probability or threat of damage, injury, liability, loss, or any other negative occurrence that is caused by external or internal vulnerabilities, and that may be avoided through pre-emptive action.”

In the context of software development that pre-emptive action is often what we like to call TESTING. The testing team/function become, and are correctly proud to be known as, part of the Risk Mitigation Business.

Testers reduce the chance of the negative occurrence becoming a reality by application of their skill to identify, categorise and ensure the correction or removal of issues in the object under test. This is the risk mitigation business in action!

47070247 S Copy

Risk Based Testing

In the project which we are all waiting to be assigned to there will be unlimited time and resources available to pursue the mitigation of risks to the point of extinction. However, back in the real world we need to consider Risk Based Testing (RBT).

Risk Based Testing is a good thing. With appropriate mechanisms in place to identify, assess, categorise and prioritise risks it allows the test team to focus their efforts efficiently. However, back in the real world again we need to understand the drivers for the adoption of this approach and some of the pressures it places on our team of risk mitigation experts (that’s the testers in case you were wondering!).

Risk based testing can mean different things depending on who you ask:

Try this “who said what” quiz. Well, the answers have been filled in for you but you get the picture!

Riskmitigation

Making it work!

Establishing a common and universally accepted understanding of what the terms “risk” and “risk based testing” really mean, across the wider project team, is key if the approach is to successfully deliver the increase in efficiency of testing desired.

This needs to be driven by both the Project and Test Managers (once they agree of course!) via a series of workshops and presentations.

Senior management acceptance of, and participation in, this process is critical if what can still be hard decisions around testing scope are to be faced into in such a way that all parties accept the outcomes and refrain from any temptation to move to the “I told you so” stance if/when accepted risks become defects, issues or incidents.

The missing link

There is one further part of the risk and risk based testing process that needs to be considered and it is one that is often missed when the “hard decisions” are being taken and the deadline date is rapidly approaching.

Put simply, it’s ensuring that the risk of something going wrong which could, in all probability, have been detected and prevented by executing (almost) complete test coverage, is understood by the actual person who will be impacted by it.

Some potential impacts include but are not limited to:

They may accept business their actuaries say they should decline, exposing them to unknown liabilities.

They may have to over pay a claim impacting their P&L bottom line.

They may suffer reputational impact if they are forced to contact customers previously accepted on incorrect terms and make amendments, loss of business may ensue.

They may be in breach of regulatory requirements concerning the accuracy of the information they are processing and publishing to their customers.

Conclusion

To successfully develop and deliver a project making use of a Risk Based Testing approach it is vital that the real owners (the people who will feel the pain!) of the risks identified and categorised by the project team coming to fruition are an integral part of the process.

It is not sufficient to “communicate” the risk based decisions to these potentially impacted stakeholders via meeting minutes or status reports. In today’s highly pressurised workplace environment senior stakeholder’s awareness of, or even acceptance of, does not always equate to understanding of.

Only by specifically engaging these stakeholders can the project team be comfortable that they understand the potential impacts on them and that they are bought in to the process.

Without this critical but often overlooked communications step, risk based testing will continue to be thought of as a “quick fix” by some and an “out the blue” disaster by others.

 

By Alister Aitken, Senior Test Consultant at Edge Testing

Back to Blog