Decision Tables

SUMMER15 gives 15% off — but only for stays of 3+ nights, and it doesn't combine with the member discount. Read that sentence again as a tester and feel the trap: it's not one rule, it's three rules interacting. The moment rules interact, testing them one at a time stops working — each rule can pass alone while a combination fails, which is precisely how Fernway's refund weekend happened. The decision table is the technique for this shape of problem: lay every combination out in a grid, so none can hide.

Restaurants invented the problem long ago: "free dessert with any main course — unless it's the lunch special, except on weekends." No waiter holds that in their head reliably. Every waiter can read it as a grid on the kitchen wall. Same rules, different representation — and the representation is what makes them checkable.

When You Need One

The smell is in the requirement's grammar: if... unless... except when... but only for... Several yes/no conditions, one outcome that depends on their combination. Discounts, permissions ("admins can edit, unless the record is archived, except their own drafts"), shipping rules, tax rules — anywhere business logic branches on multiple factors at once. When you catch yourself re-reading a requirement and losing track of which combination does what: that's the signal. Stop re-reading. Build the table.

Building the Table

Three moves. First, list the conditions — the yes/no factors — as rows: a promo code is applied; the stay is 3+ nights; the traveler is a member. Second, one column per combination: three conditions, each yes or no, gives 2 × 2 × 2 = 8 columns — the arithmetic is always two multiplied by itself once per condition. Third, for each column, write the expected outcome at the bottom: which discount applies? Here is Fernway's table, in full:

Walk it. Columns 1 and 2: valid promo — 15% applies, and for the member in column 1, no stacking (the no-combine rule earning its keep). Column 4: promo on a short stay, non-member — no discount, plus a clear message about the 3-night minimum. Columns 5 and 7: no promo, member — the 10% member discount. Columns 6 and 8: nothing applies. And column 3 — a member applies the promo to a 2-night stay — holds a question mark. Hold that thought.

Every Column Is a Test Case

The table's payoff for testing is immediate: each column is one test case, with its inputs (the condition values) and its expected result (the outcome row) already specified. Eight columns, eight designed tests — and the coverage claim writes itself: every combination of the three conditions is examined. Compare that to "I tested the promo code and I tested the member discount" — two single-rule tests that would have sailed straight past the refund-weekend bug, which lived in a combination. The table is Principle 2's answer for rule clusters: the space is finite, so here, for once, you actually can test everything — as long as everything means "every combination of these conditions."

The Question Mark: Tables as Requirements Probes

Now column 3. A member applies SUMMER15 to a 2-night stay. The promo is invalid (under 3 nights) — but does the traveler still get their member 10%? Or does entering an invalid code suppress everything? Petra's story doesn't say. Nobody decided. Omar, asked, admits the code currently does... whatever it happens to do — which is how the double-discount cousin bugs get born. This is the table's second job, and arguably its greater one: an empty or uncertain cell is a question nobody answered. You walk the table with Petra in refinement — five minutes — and she decides: invalid promo falls back to the member discount, with a message about the minimum. The cell fills in, the story gains a criterion, and a production surprise quietly never happens. Half the value of building the table is discovering which cells you can't fill.

Keeping Tables Honest — and Small

Two practical notes before the toolbox moves on. First, some combinations are impossible — if one condition is "booking is cancelled" and another is "traveler is checking in," no column needs both true. Strike impossible columns out with a written reason — "struck because X excludes Y" — rather than silently dropping them; a visible strike-out is a decision, an invisible one is a hole. Second, columns sometimes collapse: in columns 5 and 7 (no promo, member), the stay-length condition doesn't affect the outcome — 10% either way — so a team may merge them and test once. Collapsing is a judgment call about what genuinely can't matter; when in doubt, keep the columns apart. (The full collapsing method is deep-dive material; recognizing it is enough here.) And the size warning: tables shine for clusters of roughly 3–5 conditions — 8 to 32 columns. Past that, the grid explodes, and taming the explosion is exactly what Topic 20's pairwise technique is for.