Joep Schuurkes (Posts about test cases)

Thinking in threes about software testing

Joep Schuurkes — Sat, 30 May 2026 22:00:00 GMT

In the episode "Thinking magically with Ramsey Dukes" of the "What magic is this?"-podcast, Ramsey Dukes (pen name of Lionel Snell) says some interesting things about thinking in twos as opposed to thinking in threes. (The quotes are from a section starting at 01:03:47 and ending at 01:08:02. Transcription mine.)

Thinking in twos and threes from the perspective of Magic

Thinking in twos, dualistic thinking, Ramsey Dukes calls a trick:

[...] the brain is constantly making distinctions. And, so I suggested that when we have these dualities, God - Devil is what we are sort of brought up with. [...] The good, the bad. Now when that gets polarized. You see other people are always the bad. They're the devil. And I say that if you look closely it's actually a trick. All these things are tricks. [...] There isn't a little gate in the middle with a guard there, saying: "Fill in the form. Are you on this side or are you on that side?" It's a whole spectrum. Everything's connected.

Instead of thinking in twos, Ramsey Dukes recommends thinking in threes:

So I said that if instead, we trained ourselves or encouraged ourselves to think in threes. God, Devil, Trickster.

Where the third element of a duality is not the middle ground:

The difference between a test case and a requirement is the moment of discovery

Joep Schuurkes — Sun, 26 May 2024 22:00:00 GMT

There are several straightforward ways to distinguish a test case from a requirement. A test case tells you how to check some kind of thing about the application, a requirement tells you that the application should do some kind of thing. A test case is written by a tester, a requirement by a business analyst. A test case takes the shape of an action and an evaluation of the result, a requirement takes the form of a sentence like "product ABC shall do XYZ."¹

A less straightforward, but more interesting way to distinguish a test case and a requirement, is this:

The difference between a test case and a requirement is the moment of discovery.²

In this post I want to explore the meaning of that statement. In the next post I'll explore how looking at requirements and test cases in this way, can help us to do better testing. So this post will be a bit more philosophical, the next one more practical.

It's time to retire our test case management tools

Joep Schuurkes — Sun, 19 Jul 2020 14:38:17 GMT

Recently the topic of test case management tools popped up a few times in my surroundings. In almost all cases I'd recommend against using these kinds of tools and I found myself able to give a few reasons, but also found that my thoughts lacked the clarity I'd like them to have. Hence this blog post, to force myself to think more deeply and communicate more clearly.

Before I go into that, there are a few things this blog post is not about. I won't be really going into what effect test cases have on test execution, or rather if test cases are a good tool to use when doing actual testing. Personally I don't think they are and I wrote about my inability to use them in this post from July 2013. For some deeper thoughts on this, I recommend James Bach's and Aaron Hodder's article "Test cases are not testing: Towards a culture of test performance".

What I do want to cover in this post is managing test cases. Having a collection of test cases stored somewhere to re-use across releases and reporting their pass/fail numbers. Both are important use cases for a test case management tool and both are in my opinion a bad idea.

The test case - an epistemological deconstruction

Joep Schuurkes — Sun, 01 Feb 2015 21:19:55 GMT

(This article was first published in Dutch in TestNet Nieuws 18. The article below is a translation with minor changes. Many thanks to Joris Meerts and Ruud Cox for reviewing the original version.)

Testing as an information problem

Testing is an information problem. We are in search of certain information, of an answer to the question: does this application fulfill the relevant explicit and implicit expectations? The exact way in which we can answer this question, however, is not immediately clear. First we will need to decide which questions to ask, how to ask them and how to evaluate the responses. Hence, testing is an information problem.

For the traditional test methodologies (ISTQB and TMap being the most well-known) the test case is a large part of the solution. So let's take this solution apart epistemologically and see what it is we have in front of us. If the traditional test case is our solution, what information does a test case contain? What changes occur after executing it? And also, where is the understanding in all of this that's happening?

In this article, I will first describe how a typical test case is created and how it is used. Then we shall take a look at which kinds of information a test case contains. Finally, we will analyze where the understanding of what happens during testing, is present and where it is not.

Test cases, can't do 'm no more

Joep Schuurkes — Sat, 06 Jul 2013 18:19:32 GMT

Continuing the style of my previous blog post...

Some days ago I found myself no longer able to think in test cases while testing. Of course, it's not as if I was using test design techniques to generate test cases one day and woke up the next day to find myself unable to do it anymore. But still, about a week ago I figured I had explored enough to be able to write down the test cases I wanted to execute and found myself staring at a blank page (well ok, empty Excel sheet) feeling alienated from what I was planning to do.

So what do I mean when saying "thinking in test cases". Simply put, you take a piece of functionality, let a test design technique loose on it and there you go: a set of test cases to execute. Combine test design techniques over the different pieces of functionality as required and you're all covered test strategy-wise. Or that's the idea.