Write Down What You Decided Not to Test

Every test plan is reviewed for what it covers. Almost none are reviewed for what they deliberately leave out.

Which is strange, because the exclusions are the part that gets re-argued. Coverage is agreed once and then executed. An unwritten exclusion gets rediscovered by a different person every sprint, questioned in a refinement session, defended from memory by whoever happens to remember the reasoning, and occasionally overturned by whoever is most confident in the room.

One Line in a Decision Log

The telesales cart on one epic uses a single pricebook, selected automatically.

There is no picklist. No branch. No condition under which a different pricebook could be chosen, and no user who could choose one. The decision log records it in a single line: not an element of any test.

That line is doing more work than it looks like.

Why It Attracted a Test Case in the First Place

Because of the vocabulary. "Pricebook" sounds like a configurable business rule. It has a name that belongs to the same family as discount rules, eligibility matrices and approval thresholds — all things that absolutely do need testing, and all things that have burned testers who assumed otherwise.

So the instinct fires. And the instinct is not stupid; it is pattern-matching on a word.

The cost of following it is invisible, which is the real problem. A tester spends a cycle constructing scenarios to prove that the right pricebook is selected. The scenarios pass, because there is only one pricebook and no way to get a different one. A green test case appears in the suite. Everything looks like progress.

Nothing was learned, nothing was protected, and the case will now run forever in every regression cycle because removing a test feels like accepting a risk.

The Three Questions That Settle It

Before writing a case for anything that sounds configurable, ask three things about it in the scope you are actually testing.

Is there a decision point — somewhere the system chooses between alternatives? Is there an input — something a user, a record or an integration supplies that could change the outcome? Can the outcome vary at all within this scope?

If all three answers are no, there is nothing there to assert but a constant. A test that always produces the same value regardless of what you do to the system is not a test; it is a screenshot with a run history.

The Nuance That Makes the Exclusion Safe

"Not tested" is not the same as "not covered", and this is worth being precise about, because the honest objection to any exclusion is: what if that thing is wrong?

If the single automatically-selected pricebook were the wrong one, every price in the cart would be wrong. And every price in the cart is already asserted, in the cases that exist for pricing, promotions and totals. The verification rides along with work you were doing anyway.

That is the difference between a component nobody checks and a component nobody checks directly. The first is a gap. The second is efficient design, and it is defensible in a review — but only if somebody wrote the reasoning down.

How to Write an Exclusion So It Survives

An exclusion needs three things and fits on one line.

• State what is excluded, in the terms someone would search for. "Pricebook selection on the telesales cart" — not "pricing config", which is too broad and will be read as excluding things you did test.
• Give the mechanical reason, not the conclusion. "Single pricebook, selected automatically, no user input and no decision point" tells the next reader why. "Not applicable" tells them nothing and invites them to disagree with you.
• Name what would make it testable again. A second pricebook, a selection rule, a channel that picks its own — write the trigger. An exclusion is a claim about the system as it is today, and today has an expiry date.

That third element is the one people skip, and it is the one that turns a note into a control. Without it, the exclusion is a permanent statement about a system that keeps changing. With it, the day someone adds a second pricebook, the note becomes a work item instead of a surprise.

Why This Matters More at the End Than at the Start

There is a version of this argument that sounds like efficiency, and efficiency is the least interesting reason to do it.

The real reason is what happens when something goes wrong nearby. An undocumented exclusion and an oversight look identical from the outside. Both present as "there was no test for that." One was a considered decision made by someone who understood the system; the other was a miss. Nobody can tell them apart afterwards, including you, six months later, under questioning.

The write-up is what separates them. It converts "we didn't test it" into "we decided not to test it, here is why, and here is what would have changed our mind" — which is a professional position rather than an apology.

It also does the boring thing well. The question stops being re-raised. New joiners read the reason instead of forming the instinct from scratch. Refinement sessions stop spending ten minutes on a settled point every time the epic comes back around.

Open your current test plan. Can you name one thing you consciously chose not to test — and is that reason written anywhere?