Joep Schuurkes (Posts about risk)

Not continuous everything!

Joep Schuurkes — Sat, 20 Dec 2025 23:00:00 GMT

In Chapter 18 of "Taking Testing Seriously" (I skipped ahead, sue me), Keith Klain says:

So much today is about "continuous everything" - continuous deployment, continuous integration - and speed. The pace at which people are doing things is really, really disruptive to thinking deeply about problems. Then the goal gets displaced from getting good products and services to customers quickly, and turns into, "How do we back something out quickly when we inevitably screw up?" It's continuous everything - except continuous thinking.
- Taking Testing Seriously, James Bach, Michael Bolton et al., 2025, p. 424

He has a point. But I got there by first kind of disagreeing with what he said. Because "continuous everything" is not about speed. It's about risk. Or rather, about managing certain risks: the risk of (code) integration and the risks of delivery/deployment. And how fast you go, should not just be determined by those two specific risks. (Or even worse, by the fact that you just think it's really cool that you can release every commit to your users.) It should be determined by your overall risk appetite, which is a much broader perspective.

Being intentional about exploratory testing

Joep Schuurkes — Fri, 08 Nov 2024 23:00:00 GMT

This is the second post in a (to be) three-part series about my statement "The difference between a test case and a requirement is the moment of discovery."

In the previous post I distinguished test cases that are translated requirements from ones that aren't. This is something I learned from James Lyndsay. As he describes in "Why Exploration has a Place in any Strategy":

Some tests are designed to find risks. They're made on-the-fly and run once. Some are designed to tell us about retained value. They're made once, and run forever after. You need both: they tell you different things.

The tests with a focus on value are based on requirements, on things we know we want, they are prescribed (as in: written before). The tests with a focus on risks are exploratory, they are based on our decisions in the moment, we look for surprises and decide how we feel about those surprises.

One thing I've noticed through the years, is that a lot more exploratory testing is happening than we give credit for. It's hidden, a required but implicit part of the work. We do it, but we're not intentional about it.

Today I want to argue that it pays to be more intentional about exploratory testing. Before I get there, however, I want to explain what exploratory testing is, because there are still plenty of misconceptions going around.

Three thoughts on risk-based testing

Joep Schuurkes — Sun, 17 Jul 2022 09:56:30 GMT

The past month I've been thinking about risk-based testing. This post collects three thoughts on risk-based testing I kept returning to.

If not based on risks, then based on what?

About a month ago I tweeted:

What are the alternatives to risk-based testing?
Requirements-based? I'd argue that's a subset of risk-based.
Unguided? That's either a bad idea ("we hope to get lucky") or aimed at the risk of unknown unknowns.
Any other options? Because something about the term is bothering me.

My question was inspired by the "opposite" heuristic from my talk about testing types: if we have some kind of category, what's the name for the things not in that category? Applied to risk-based testing: what's the name for testing that's not risk-based?

Test strategy primer

Joep Schuurkes — Tue, 29 Jan 2019 20:34:19 GMT

I originally wrote this primer to share with people at work. The first section is intended to be generally applicable; the second not necessarily so. The main influences on this primer are:
- Rapid Software Testing's Heuristic Test Strategy Model
- James Lyndsay's Why Exploration has a place in any Strategy
- Rikard Edgren's Little Black Book on Test Design

This document contains two sections:

Why have a test strategy? - what is a test strategy and what's its purpose
Test strategy checklist - checklist for describing your test strategy

Why have a test strategy?

The purpose of a test strategy is to answer the question: "How do we know that what we are building, is good enough?" As such, every team has a test strategy, even if it's only implicitly defined through the actions of the team members.

Why your Product Risk Analysis isn't

Joep Schuurkes — Sun, 23 Jun 2013 12:34:36 GMT

Ok, going to try to keep this short and ranty (rantish?).

Typical test advice is to do a Product Risk Analysis (PRA, mind the capitalisation!) and based on that you decide what to test and how thoroughly. The most common way to do a PRA is with a workshop. Put some people in a room with a lot of stickies, let them list all the risks they can think of and then have them score them. Et voilà, Product Risk Analysis is done!

But that doesn't really make sense, now does it? If someone were to give you an object and asked you "What could possibly go wrong with this?", what would you do? Gather a bunch of people with some knowledge of the object, yet no actual experience with it and do a workshop imagining things that could go wrong? That's not an Analysis (capital A!), that's a SWAG – a scientific wild ass guess.