Write Every Test Case for a Stranger

Some of the stories written for me were reassigned to other testers.

Ordinary reallocation, nobody's fault, the kind of thing that happens in every sprint. It also meant my test cases were about to be executed by people who had not sat through a single analysis session about them.

That is the moment a test case stops being notes and starts being a product.

A Test Case Is Only as Good as Its Weakest Reader

Everything I knew about those stories was in my head, and none of it was in the steps.

Which record should be open before step one. Which actor is performing the action, and whether switching actors mid-journey is deliberate or accidental. What a term like "waived" actually means on the wire, as opposed to what it means in the meeting where it was agreed.

While I was the reader, none of that mattered. The steps were a checklist against context I already had, and a checklist is an extremely efficient format when the reader supplies the missing eighty percent themselves.

The instant the reader changes, the same file becomes ambiguous. Not wrong — ambiguous, which is worse, because an ambiguous step gets executed anyway. Someone picks an interpretation, the journey runs, a result gets recorded, and the result is real, precise and about a scenario nobody designed.

The Things That Break First

Handover failures are boringly predictable, and they are almost never in the interesting part of the test.

• Make login and logout explicit, every time. "Continue as the approver" assumes the previous session ended and a specific persona started. Written down as a step, it is unambiguous; left implicit, half the executions run the approval as the person who requested it.
• Navigate to each record explicitly, from a known starting point. "Open the order" is fine when you have one order open in a tab. It is meaningless in an org with thousands, and the stranger will pick a record whose data does not match your preconditions.
• Define the words that carry business meaning. Any term that means one thing in the requirement and another in the data — waived, active, submitted, cancelled — needs its concrete assertion attached, because the stranger will use the ordinary English meaning and the ordinary English meaning is usually wrong.

None of that adds insight. It adds about fifteen percent to the writing time and removes the entire class of failure where the test ran fine and proved nothing.

Standardisation Has No Value Until It Has All the Value

Here is why this discipline is so hard to sell to yourself.

A consistent format does nothing for the author. When you write and execute your own cases, format is pure overhead — you would be faster with terse fragments, and you would be right. Every hour spent on structure is an hour that buys you personally nothing.

Then a reassignment happens, or you go on leave, or a story slips into a release where somebody else owns the run, and format becomes the only thing that matters. It converts instantly from zero value to total value, with no warning in between.

That is the part worth sitting with. You cannot retrofit it at the moment of handover, because at that moment there is no time and you are no longer the person with the context.

Two Audiences Means Two Products

The same lesson arrived from a different direction when a client asked for test cases to run their acceptance testing. What they received were the cases the testers had written for themselves.

Chaos, and entirely predictable chaos.

There are two distinct artefacts here and they share only a name. A technical test case is a checklist for a tester: preconditions, terse steps, expected results, written for someone who knows the system. A client-ready case describes every step with the location of the button, the name of the screen, the exact field, written for someone who has never used the application and will not ask a follow-up question — they will simply stop.

Handing the first to a business user is not a shortcut. It is a different deliverable with the same file extension.

Decide the Type Before the Estimate Is Signed

The consequence is commercial, not editorial.

Client-ready cases cost roughly fifty percent more time to write than technical ones. Same coverage, same scenarios, same thinking — the extra half is pure description.

That number has to be inside the estimate before it is agreed, because afterwards there are only two ways out. Absorb it, which quietly deletes half your test-design budget. Or hand over the technical version and let the acceptance phase discover it, which spends the client's time instead of yours and costs the team's credibility on top.

So the question belongs at the start, in the same conversation as scope: who executes these, and are the acceptance cases in this number or not? It takes one sentence to ask and it is almost never asked, because everybody assumes "test cases" is a single well-understood noun.

It is not. It is two products, two audiences and two prices, and only one of them was in the estimate.

The Rule Underneath Both

Write for the reader who has none of your context. That covers the tester who inherits your stories and the business user who inherits your suite, and it is the only assumption that stays valid when the work changes hands.

The cost of writing that way is fixed and small. The cost of not writing that way is unbounded and paid by someone else, in the week of the release, when nobody has time to reconstruct what you meant.

If your current suite were handed to someone tomorrow with no conversation, how many of your cases would run the journey you intended?