The 3Rs of Risk

After writing about using the Test Automation Pyramid to identify at which layer we can mitigate a risk and our team’s current automated test strategy, I thought I’d explore a model that helps us ask questions to identify the risks we are trying to mitigate. The mitigation of these risks does not have to occur through testing, but it may help fuel test ideas.

**Firstly, I’d like to say that this model is a work in progress, so all feedback is welcome!**

What is the Purpose of the Model?

Before I share the model itself, I’d like to describe the thought process behind creating the model and why I believe it is important.

The main purpose of developing a product is to provide value to “someone”. This “someone” is usually our customer, but it can also mean providing value to our company, in the form of monetary income, for example.

When considering what risks there are to the value of the product I am working on, I often rely on my own past experiences. What issues have been raised in the past that have caused harm to either a) our customers or b) the company? What is the worst possible thing that could happen when the software/functionality we are working on goes live?

Based on my own answers to the above questions, I’d like to share my opinion that there are three main areas to consider when discussing which risks we need to mitigate throughout the development process. These are:

• (Lost) Revenue
• Relationship (with customers)
• Reputation (of the product)

These categories are very much business focused. To put it bluntly, in the majority of cases, if the company we’re working for isn’t making money then it doesn’t matter how high the quality of the software we’re developing is. On a more human level, our Relationship with our customers is vital for retention. The last category of Reputation can massively impact growing our customer base and have financial implications.

I’ll explore each of these categories in more detail after sharing the model.

Of course, not all of these three areas apply in every case. For example, if your customer is an internal team or you’re operating as a not for profit organisation then you may not have to consider Revenue as a potential risk area.

The “3Rs of Risk” Model

The model itself uses what I’ve identified as the three main areas of risk. The overlapping circles signify that risks to Revenue, Reputation and Relationship can overlap. For example, there may be risks identified which could result in lost Revenue that also result in damaging your Reputation. Poor app security, resulting in a security breach, may result in a damaged Reputation in the media and also damage your Relationship with customers.

I’m now going to cover the three areas in more detail and provide some examples so I can illustrate why I’ve identified these areas as threats to software value.

Revenue

Losing Revenue has to be one of the biggest risks for the majority of businesses that we will work for throughout our careers.

When identifying what types of tests we need to run, we should consider what risks there are to losing Revenue. Whilst exploring the three areas of risk, we will imagine we’re working for an online retailer. Based on that scenario, I’ve identified a few risks to Revenue in the circle below.

Losing sales is probably your biggest threat to revenue. What tests/types of testing can you run to identify that there are no major issues resulting in lost revenue for the customer? If completing the checkout process is identified as one of your main critical flows, can you automate a test at one of the layers of your application to flag if there are any changes in this area?

Does your product function correctly on multiple platforms (desktop, mobile etc)? What percentage of customers are using each platform? Will that help you decide which risk is more important to mitigate?

How easy is your software to use? Can you ensure your product is observable? If customers aren’t completing the checkout process then is it a usability issue? Or is it a performance issue? Do we need to identify more performance tests to run in our process to cope with peak loads and stop people abandoning transactions?

The aim of the Revenue circle is to initiate conversations around what risks there are to losing Revenue with the software we’re developing. Lost revenue impacts the value we are providing to the business.

Relationship

Our Relationship with our customers is key. We need to be able to connect and empathise with them in order to meet their needs and provide them with valuable software. Having a good Relationship with customers is vital to retention.

Let’s again use our example of an online retailer. What risks are there to our Relationship with our customers?

The first word that comes to mind for me is trust. Do our customers trust us with their data? How secure are we? In order to try and mitigate this risk could we use the STRIDE model?

How well are we communicating with our customers? Have we tested confirmation emails are being sent once transactions are complete? Do we have automatic communication when the website is down (a temporary web page for example)? What tests could we add to cover that?

How usable is our website? Is it accessible? Are those (all too popular) annoying pop-up adverts getting in the way of people using our site? Are people frustrated?

How about our loyalty schemes? Have we tested these? If loyal customers were to lose ‘points’, how would they react?

Identifying and mitigating risks to our Relationships with customers (even if they are internal) is vital if we wish to provide a valuable and reliable product.

Reputation

The third and final area of risk in my 3Rs of risk model is Reputation. What issues are likely to effect your company/product’s Reputation and prevent you from delivering a valuable product?

Our shopping application/web page may have a number of risks associated with Reputation.

Security breaches are possibly the most reported software bugs within the media and social media, and for good reason. As well as damaging your product/company’s Relationship with customers, security issues can also have devastating effects on your Reputation. What are we doing to mitigate security risks?

If a customer is looking for a nearby store, are we hooking into Google Maps (for example), or have we created our own version of a interactive map? How would we test the design and usability of the map? The reason I’ve added this to Reputation is the disastrous rollout of Apple Maps in 2012 and the media coverage that followed.

Are we compliant with industry regulations? If not, it could result in a high profile court case or disciplinary procedures. What tests (or monitoring) do we have in place to mitigate that risk?

Is our app highly available? How will downtime be handled? How quickly can we recover? Do we carry our war games or chaos engineering tests?

Are we an ethical company/product? How do we deal with customer complaints? If we advertise that “x% of purchases goes to charity” have we ensured that this is actually the case?

Final Words

I hope that you will find this model useful when deciding which areas of risk to focus on. Like all models, I don’t believe it is complete, but I hope you can use it to facilitate conversations around the risk of lost Revenue, customer Relationship, product Reputation and how to mitigate those risks through the design or testing of your software.

As always, feedback on this model is welcomed. Does it make sense in your context? Have you found it useful? What would you change?

If you would like to read more about testing and risks then I’d recommend Dan Ashby’s Risk Based Testing series.