One of my aims as I switch from marketer who did some testing to full-time tester, is to gain a deeper understanding of the fundamentals of testing that underpin all that we do.

At its heart, I am understanding testing to be about risk. Understanding it, and mitigating it. Harm/irritation to the customer/user and revenue/reputational risk to the organisation.

As Marie Drake points out, "testing is not test automation", test automation is merely a method we use to make the tests and checks we think of after assessing risk run.

Because you can't test everything, thinking about risk enables you to prioritise. This enables you to be more confident that the product is doing what it should, and less of what it shouldn't.

So this article gives a brief overview of the ways we use to identify risk that I have researched.

Risk matrices, decision tables, and mind maps

Methods we use to think about and map out risk.

Risk matrices

The risk matrix promotes robust discussion, and provides some consistency to prioritising risks, focusing the team on the highest priority risks.

Consequence vs Likelihood

Impact vs Likelihood

Decision tables and mind maps

Mind-maps and decision tables are a way to visualise the business logic of applications. They make it possible to absorb large amounts of information at a glance.

Mind-maps show flow, and decision tables show yes/no.

I've actually used this before as a marketer. At one of my previous workplaces, I created a mind map/decision tree diagram of the flow of my design of a micro-site we were using for promotion. I remember later using that same diagram to assist with my acceptance testing of the website, to make sure I had tested all the paths.

Risk-based testing

Risk-based testing uses these risk matrices to prioritise what to test because there simply isn't enough time to test everything.

It follows Risk Management principles.

Functional testing heuristics and mnemonics

Software testing heuristics are mental models of reasons/places defects are often found. If you try and apply all of them to every project, you'll waste your time, but they are great when applied judiciously.

Mnemonics are a great way to remember them.

Michael Bolton noted that as developers start consciously taking them into account while developing, and they are discussed in that context earlier in the software development life cycle, the less likely it is bugs can be found using some tactics.

This is just like with marketing tactics, where as soon as customers notice what's happening, it's a little less effective. Way fewer people click on website banners than used to.

However, that's what makes heuristics such a useful tool for identifying potential risk. They can be applied up and down the cycle. We can think about risk to customer and software system in these terms earlier.

Business Risk

Risk to revenue

Risk to reputation

Risk to market share

etc

Spec Testing & Exploratory Testing

Known risks and potential risks

Extra Background Reading

• Logs
• Incident Postmortems
• Setting time aside to learn more about the software under test's domain. For example, if it’s a logistics-specific IOT application, reading about how ports work, workplace safety, the IOT tech under test.

Thank you to the Bloggers Club at the