Equivalence Partitioning

The stay-length field takes 1 to 30 nights. Here is the insight that saves you from testing thirty values: the software almost certainly treats 7, 12, and 23 identically — the same checks run, the same path executes, the same kind of answer comes back. If the code is right for 12, it's right for 23; if it's wrong for 12, it's wrong for 23 too. So one test speaks for all three. Cutting the input space into groups the software treats the same — and testing one representative from each — is equivalence partitioning, the first technique every tester learns and the base layer under all the others.

It's soup-tasting, formalized. One spoonful tells you about the whole pot — if the pot is stirred. Partitioning is the skill of knowing how many pots are actually on the stove, and taking one honest spoonful from each.

Partitions, Valid and Invalid

A partition — textbooks also say equivalence class — is a set of inputs that exercise the same behavior. For stay length, the rule itself draws the first lines: everything from 1 to 30 is one partition — the valid one, where booking proceeds. But the values outside the rule form partitions too: zero and below is one group (all should be refused the same way), 31 and above is another (refused, but for the opposite reason — and possibly with a different message). Those are invalid partitions, and testing them is not optional politeness. Error handling is where products embarrass themselves, and invalid partitions are where the error handling lives.

Then come the partitions the rule never mentions: the empty field. Letters — "two" typed by a human being who was never told not to. Each is a distinct group, because each should produce its own sensible response — and each is a place where "we never thought about that" hides.

Finding the Partitions

Where do the lines come from? Two sources. First, the rules: read the requirement and ask, where does behavior change? SUMMER15 works on 3+ nights — so "under 3 nights" and "3 or more" are different partitions for the promo code, even though both are valid stay lengths. Every acceptance criterion from Chapter 2 draws partition lines; this is the direct pipeline from requirements to tests. Second, the data itself: whatever the rules say, an input field can always be empty, oversized, or the wrong kind of thing entirely. Those partitions exist for every field ever built, which is why testers probe them by reflex.

Notice partitions don't have to be numeric. Payment methods — card, gift card, saved card — partition checkout. User types — guest, member — partition pricing. Browsers partition rendering. The technique is about groups treated the same, whatever the axis.

One from Each, Not Many from One

The technique's coverage claim is beautifully simple: every partition represented. One test from the valid group, one from each invalid group — for the guests field, five tests, and you can defend each one's existence. The classic waste runs the other way: five tests at 2, 3, 4, 5, and 6 guests is five spoonfuls from one pot — four of them tell you nothing the first didn't. When you see a test suite bloated with same-partition repeats (you will), you're looking at effort without design.

And the payoff at Fernway: running the guests-field partitions, the "0 and below" test doesn't get refused. Zero guests sails through — Fernway happily books an empty room at full price, cleaning fee included. FW-341. Found not by luck but because the technique demanded a test the comfortable middle would never suggest.

When Partitioning Lies

One honest caveat, because the technique rests on an assumption. "Treated the same" is a claim about the code — and from the black box, you're inferring it from the rules. Sometimes the code has lines the rules don't mention: Omar mentions offhand that stays of 28+ nights go through a separate "long-stay" pricing path. Suddenly your tidy 1–30 valid partition was actually two partitions — 1–27 and 28–30 — and your single representative at 12 never touched the second one. This is grey-box knowledge (Chapter 3) sharpening the technique: every mechanism you learn about can split a partition you thought was uniform. When in doubt, ask "does anything change inside this range?" — and re-draw the lines when the answer surprises you.