Depending on your point of view, risk is either a good or bad thing. The pessimist sees the doom and gloom of future problems, the optimist delights in the opportunity, the naive ignore risks completely. As a Test Architect, I see risk as one of my most powerful tools in driving a successful test cycle. I have a ‘virtual risk lever’ that I can pull or release depending on the situation. I can use risk to justify priorities and resource, focus attention and articulate a clear business view of our testing. So what do I mean by ‘risk’ in a software testing context?

Taking a simple definition: Risk is the possibility of an event occurring that will have an impact on the achievement of objectives. Risk is measured in terms of impact and likelihood.

To give an example, if a tightrope walker is walking along a wire one foot above the ground then, regardless of the probability, the impact of falling off is minimal. A sprained foot at worst. This could be deemed a low risk activity. If the same performer walks along a wire one thousand feet from the ground the probability of falling off essentially remains the same, but the impact of falling and receiving major injuries is far greater. In this case, broken bones and worse are a certainty. This would then be considered a high risk activity. So we can see that for the same simple activity the risk can vary depending on the situation.

So how can we use risk to drive our testing?

We know that as systems become more complex it is impossible to test everything (Richard will talk about this in a later post). We need to target our testing in the most effective and efficient way. Simply chasing bugs is not useful, we want to find the bugs that are associated with the greatest levels of risk. We know from testing theory that most bugs are found on boundaries, so we can target our resources towards these areas. However, a complex system will have many interactions and therefore many boundaries – so where do we start?

The three step approach: Identify, Assess and Harness.

Identify

Take time to identify all the risks around using the system under test. I like to look at risk in three different categories (in no particular order).

• Risk to the the project team
• Risk to the company delivering the system
• Risk to the end user

Whilst there is no priority on these categories, it does help to consider the risks from different view points.

Assess

Once you have identified all the risks you can, look at them in terms of the likelihood (or probability) of them happening and the impact. For each risks assign values for likelihood and probability – a high, medium, low rating is a good start. Risk becomes a product of the two factors. You should now be able to list all your risks in order, with the most risky first. Remember to view the risks from all three roles.

Harness

Now the powerful bit. As a project (testers, developers, project management) team you can now review the risk list to determine which ones need to be addressed (or mitigated) and which ones you will accept (do nothing about). All the risks that need mitigating become the driver for your test plan. You now have a test plan that can be prioritized to find the bugs in the riskiest areas first and will focus on the important areas of the system, in terms of risk, rather than the usual approach, which is to focus on the function delivered.

You have now harnessed the risk to your advantage!

An added benefit of this approach is that when a test does fail it can be articulated, not just in turns of functionality failing, but also in terms of the risk associated with this test failing. This can help in prioritizing defect fixing and even guide a ‘ship the system’ decision.

Tags: risk

This entry was posted on Monday, January 28th, 2008 at 17:21 by Jon Tilt. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.