Not Every Boundary Is Yours to Test

A campaign offer switched over at exactly 09:00 on a fixed date. November's bundles selectable until 08:59, December's from 09:00.

The instinct is immediate and it is the right instinct to have: that is a boundary, and boundaries are where defects live. So the plan, written in the middle of June, was to build a controllable environment clock and assert selectability at 08:59 and again at 09:00.

Two days later we dropped it.

Why We Dropped It

The switching logic belongs to the platform. The engine reads the configured start and end datetimes and decides what is selectable. That mechanism is not our code, it is not modified by our configuration, and it is exercised by every customer of that platform on the planet.

Testing it would verify that the vendor's date comparison works. It would consume an environment clock we do not have, produce evidence about somebody else's code, and find nothing — because if that comparison were broken, we would not be the ones to discover it.

What we control is the data: the dates themselves, the channels, the hardware options, the contract terms. That is where our defects can actually be.

So the boundary went out of scope, deliberately, and the test effort moved to configuration correctness.

The Rule

Test the configuration you own. Trust the mechanics the platform guarantees.

This is genuinely counterintuitive, and it is one of the clearer dividing lines between a junior and a senior tester. The junior instinct is that every boundary must be tested — thoroughness as a virtue in itself. The senior call is that effort spent proving the platform works is effort not spent on the thing that is actually likely to be wrong.

But There Was Still a Negative Test

Dropping the minute boundary did not empty the scope. It sharpened it.

Of thirteen bundles in that release, only four were live. The other nine were configured ahead of time with placeholder dates, and every one of them had to remain non-selectable.

That is nine negative test cases, and they are easy to skip precisely because the records visibly exist. You can see them in the setup. They look configured, correct and harmless. Nobody thinks to check that a thing which exists cannot yet be chosen.

Every record that exists but must not be selectable is its own test case. That is our boundary — the configuration boundary — and it sits entirely inside what we control.

When the Boundary Is Definitely Yours

The counter-example, so this does not become a licence to skip hard tests.

A cool-off period on a cancellation journey runs fourteen calendar days, starting the day after the terms are accepted. Inside cool-off means days one to fourteen. Outside means day fifteen onwards. The billing step is skipped inside the window and runs with real values outside it.

Nothing about that is platform behaviour. The rule is ours: the arithmetic, the start point, the branch that skips billing.

And it has a classic off-by-one waiting in it. Treat day fourteen as "outside" and the test runs without the termination charge — and passes, because the system does what the (wrong) test expects. Happy-path reviews never catch it, because the boundary case is always the one that gets dropped when time runs short.

That one needs explicit cases at day fourteen and day fifteen. Not "inside" and "outside" chosen comfortably far apart. "Fourteen days" and "day fourteen" are not the same sentence.

How To Decide, Quickly

Three questions, in order.

• Who implements the comparison? If it is the platform's engine, you are testing your data, not the boundary. If it is a formula, a flow, an Apex class or a validation rule that someone on your programme wrote, the boundary is yours and it needs both sides asserted.
• What would a defect look like? If you cannot describe a plausible failure — an actual sequence of events that produces a wrong outcome — you are writing a ritual, not a test.
• What did the configuration require a human to type? Every typed value is a candidate defect. Dates, channel flags, term lengths, eligibility codes. Machines are reliable at comparing numbers and people are unreliable at entering them, and your test effort should follow that asymmetry.

Writing the Decision Down

One last thing, and it is the part that saves you six weeks later.

When you decide a boundary is out of scope, record the decision and the reason where the test cases live. Not in a chat thread.

Otherwise the question comes back every sprint, usually from someone reasonable who has spotted the same edge and assumes it was missed. And in a review, "we don't test that" sounds like negligence, while "the platform owns that comparison; we verify the configured dates, see decision log 17 June" sounds like a test strategy.

The difference between those two sentences is about ninety seconds of writing.

Which boundary in your current suite are you testing because it is genuinely yours — and which one because it looked like a boundary?