What a Software Tester Asks Before Answering (the Lifeboat Test)

Last time, this boat taught us something about Scrum. Today, it teaches us something even more important, about testing. (WATCH THE INTRO)

Quick setup if you are new here. A small lifeboat in a rough sea. Five people aboard: a doctor, a soldier, a police officer, a teacher, and a journalist. One line of text sits across the top:

“This boat can only hold 4 people. Who will you throw out?”

First, the same ritual as before

Do not skip this. Pick one. Right now, in your head, decide who goes overboard.

Got a name? Good. Notice how fast it arrived. Hold on to it. We are coming back to it, and this time it might sting a little.

Now, let me put on my tester hat

I say this all the time, and I mean it literally.

Testers do not break products. I do not break your software. I break your illusions about your software.

That is the whole job. My work is to show you the gap between what you think your product does and what it actually does when the real world leans on it. To do that, a tester becomes a student of one specific weakness: the way our own minds trick us into seeing what we expect to see, instead of what is actually there.

Which brings me straight back to this boat.

The meme is a framing effect

Read the caption again. “This boat can only hold 4 people. Who will you throw out?”

That sentence is working on you. It hands you a conclusion (someone must go) and one allowed action (throw out), dresses both up as facts, then rushes you toward a name. That is a framing effect. It steers you, and most people never feel the hand on the wheel.

A tester feels it. So a tester does not answer the question. A tester questions the question.

And if you think that is where the lesson ends, stay with me. Because there is a second, bigger problem hiding in this picture. The same one that makes whole Scrum teams ship defects they swore were impossible. We will get there.

The question that should stop you cold

Here is the first thing I would ask. And it is not “who goes?”

It is: how do we know there are five people in the boat?

Look again. Did you count them? Or did you just trust the caption?

Yes, the picture clearly shows five. That is not the point. The point is that you accepted “five people, four seats, one must go” as a complete and correct set of facts, and you did it without checking a single one of them. The number is not the lesson. The fact that you did not verify it is.

And let me be honest with you about why this matters so much. Almost every serious production bug I have ever seen started in exactly this way. Nobody tested the assumption, because everybody accepted the question.

A tester attacks the assumptions

Once you stop trusting the caption, the questions come fast.

Who verified that the boat holds only four, and tested it in what sea, with what load? A number with no source is not a fact. It is an assumption wearing a fact’s clothes. What does “hold” even mean, float safely for an hour or just not sink in the next minute? And why is throwing someone out the only option when you could shift the weight, bail the water, or signal for help?

Notice what happens as you ask these. The panic drains out of the picture. You stop being a person trapped in a cruel choice and become someone who refuses to act on an untested spec.

Why the tester still has not answered

Notice something strange. We are this far in, and the tester still has not chosen who goes overboard.

That is not avoidance. That is the job. Testing is not about making the decision. Testing is about making sure the decision is based on reality, and not on a frightening sentence printed across a meme. A tester discovers the truth. A tester does not invent it.

This is your Sprint Planning

Here is the bigger problem I promised you. And this is where it stops being a meme and becomes your Tuesday.

This exact thing happens in Sprint Planning all the time. Someone says, “the user wants X.” Heads nod. It drops into the Sprint. Nobody asks the quiet, slightly awkward question: how do we know? A week later the story comes back with defects, and everyone is surprised.

The boat was never the problem. The assumption was. Every production defect has a family tree, and assumptions are usually sitting at the root.

Most teams do not ship bugs because they write bad code. They ship bugs because they trust assumptions they never verified.

And those assumptions hide everywhere. In a user story that sounds obvious. In acceptance criteria that quietly skip the hard case. In a refinement session where the loudest voice becomes the requirement. Every one of those is a caption on a meme, and most teams answer it in five seconds without ever counting the people in the boat.

The real superpower

So here is the lesson, stripped down to one line.

A tester’s superpower is not finding bugs. A tester’s superpower is finding assumptions.

Bugs are just the assumptions nobody tested, showing up later with the worst possible timing.

This habit, of stopping to ask “wait, is this even true,” is not natural. It is a skill. Most people never build it, which is exactly why teams keep shipping the same surprises over and over. Testers build it on purpose.

That is what I teach inside my course, Software Testing Mastery in Scrum: to see the gap between what a product claims and what it really does, to read what acceptance criteria leave unsaid, and to ask the clarifying questions that surface the truth before a single bug ships.

👉 Software Testing Mastery in Scrum

So that name you picked in the first ten seconds, before you counted, before you checked, before you asked whether anyone had to leave at all?

Next time someone hands you a question with only one allowed answer, do what a tester does.

Count the people in the boat first.