Why do my tests keep missing the bugs that matter?

You run the test. It passes. Then the bug shows up in production, and you wonder how the test missed it. This is not bad luck. The test passed because you wrote it the way you expect your code to behave. Not the way the world will actually use it. You and your team built this thing together. You know its intentions. That is why you cannot see its weaknesses. You are too close to the design, too loyal to the plan. The code's enemy is not confused about what it is supposed to do. It does not care. This is not a skill you lack. It is a habit you have not chosen yet. Sit down with your team and ask, together: what would break this? Do that before anyone celebrates a green test suite.

◆ How this problem reads on the two dials

GuidanceKnowledge

More coaching

A little to learn

1:1 with AureliusWith others (a Pod)

Some one-to-one

Practise with peers

The person already has the technical skill; what's missing is the adversarial stance, which is a shift in habit, not information — so coaching leads.

How the two dials adapt to you →

What’s really going on

You already know how to write a test. What you avoid is trying to break your own work. A test that only confirms your code behaves is not a test — it is a mirror. Gather your team and ask: what would ruin this? Write that test first. Choose to be the enemy.

🔒 What you’ll build togetherUnlock by starting

A moveBefore anyone writes a test, ask the team out loud: 'What would make this fail?' Write down every answer before writing any code to test it.

A moveAssign one person each cycle to be the dedicated enemy of the code — their only job is to try to break it, not confirm it works.

A moveWhen reviewing a teammate's tests, ask 'what case is missing' instead of 'does this pass.'

A moveKeep a shared list of every bug that has ever slipped through. Before fixing a new one, write a test for it first.

A moveWhen a bug reaches a user, ask the team why the test didn't catch it — never who missed it.

PractiseBreak It Together · a Pod of 4 · 30 min

What changes unlock by starting

Your team starts writing tests that are designed to fail, and catches bugs before release instead of after.
You and your teammates notice edge cases you used to walk right past.
Fewer bugs reach users, because more get caught in testing.
The team trusts its test suite, because it has actually been tested against failure.

One object, two jobs: a public answer to a real problem, and — the moment you start the chat — Aurelius’s live plan for your version of it.