Decision Tables and State Transitions

A shipping-rule spec fits in five sentences: if the order is over $50, shipping is free; members get free shipping regardless of total; express shipping always costs $15 unless the member; frozen items require an express-capable carrier. Four conditions interact — order total, membership, express choice, frozen items — and the tester who writes cases one scenario at a time will cover the first three combinations she thinks of and ship. The combinatorics say why: four binary conditions make 2^4 = 16 combinations, and unaided scenario writing reliably covers fewer than half while being unable to prove which. A decision table is the technique that makes every combination visible and every test justified.

The table has the standard shape — conditions as rows, rules (combinations) as columns, actions per rule:

Building it is a four-pass drill. Pass 1 — list conditions and their possible values (each binary here: >$50 yes/no, member yes/no, express yes/no, frozen yes/no). Pass 2 — enumerate the combinations as columns: 16 columns for four binary conditions; ten conditions would be 1,024, which is why the next pass exists. Pass 3 — prune. Remove impossible rules (a cell combination that cannot occur — none here, but in insurance or banking specs they appear constantly, e.g., 'under 18 with a mortgage'), then merge duplicate rules — columns where the actions are identical and the differing conditions provably do not affect the outcome. The shipping table's four action-relevant conditions collapse significantly once free-shipping subsumption is applied (membership makes total irrelevant). Pass 4 — write the expected action per surviving column with the product owner in the room, because every disputed cell is a requirement defect found before coding.

Each surviving column becomes one test case, with concrete values chosen from the equivalence classes for each condition — the techniques compose: decision tables decide which combinations, equivalence partitioning picks which value in each cell. The payoff is provability: when a stakeholder asks 'did anyone test express shipping with frozen items and a non-member?', the table either contains the column with a test ID next to it or it doesn't — and 'the table says no' converts a panic into a backlog item.

Two disciplines keep tables honest. Incomplete tables are the real risk: 16 columns written, 11 'look similar', tested implicitly as 6 — a table with silent gaps is worse than no table because it launders partial coverage as proof. Number every column and require a test ID or an explicit 'impossible/merged — justification' note per column. Tables are living spec: when the rule changes mid-sprint (members now pay $5 for express), the changed column is the blast radius — the affected test cases are exactly the ones linked to it, which is traceability at its most practical.

Equivalence partitioning and decision tables share a blind spot: both analyze a single point in time. An order-form spec passes every such test while the product is broken, because the defect lives in history: 'cancel an order that already shipped' is only reachable as the third event in a sequence, and no single-input test can express it. Stateful features — orders, tickets, subscriptions, file uploads, playlist items — need a technique that models time: state transition testing.

The first artifact is a state diagram: states as nodes, events as labeled edges, optional guards ([qty > 0]) and actions (/ send confirmation) on the edges:

[Created] --submit--> [Paid] --ship--> [Shipped] --deliver--> [Delivered]
     [Created]/[Paid] --cancel--> [Cancelled]
[Shipped] --cancel--> ???   ← edge missing from the diagram = spec question or defect
[Delivered] --return--> [Refunding] --approve--> [Refunded]

Reading that ??? is the technique's interview moment: the diagram has a missing transition, and the tester's question — 'what happens if the customer cancels a shipped order?' — is a requirement defect found by construction, before a line of code implements the wrong default (most commonly: an exception stack trace, or worse, a silent success that marks a shipped parcel cancelled in the database).

The second discipline is choosing how much of the diagram to test. Full path enumeration is exponential (loops make it infinite), so standard coverage levels bound it:

• 0-switch coverage (state coverage): every state is visited at least once — the minimum; finds unreachable states and dead ends.
• 1-switch coverage (transition coverage): every legal transition is exercised once — the practical default for most suites; every edge in the diagram has a test.
• n-switch coverage: every sequence of n+1 transitions is exercised; 2-switch (every ordered pair of consecutive transitions) catches sequence-dependent defects like cancel-after-ship and is affordable for the critical paths of payment and fulfillment flows.

1-switch coverage deserves emphasis because it is what people mean when they say 'we test all the transitions': each edge tested in isolation verifies the event works from its source state, but not that orderings behave — a feature can pass 1-switch and fail a 2-switch case where state A's residue affects state B's handling (refunding a partially-shipped order is a two-transition defect).

Invalid transitions are test cases, not omissions. For every state, events that are not legal there are as important as the legal ones: ship on a Cancelled order must be rejected with a defined error, not processed. The systematic move is a state × event matrix — rows are states, columns are events, each cell either names the expected next state or 'rejected with error X' — and requiring every cell to be filled turns the diagram into a complete contract. This matrix is also the automation blueprint: one parameterized test per row, feeding event sequences from a data table, runs the entire model in seconds.

Interview prompts for this topic are almost always practical: 'the app has draft/scheduled/published articles with comments — design tests.' Deliver the state list first (Draft, Scheduled, Published, plus Archived if the spec allows), then transitions with guards, then the invalid-event matrix, then state your coverage level and why (1-switch default, 2-switch on the destructive paths: publish→unpublish with live comments, delete-with-replies). That structure shows the interviewer the technique, not just a case list.

Both techniques model combinations; choosing wrongly costs a week of the wrong tests. The split is by defect family, and it can be stated as one question: does the feature's behavior depend on the simultaneous state of several conditions, or on the order in which events arrive?

Real features often need both, and the composition pattern is stable: model the lifecycle with states, then decision-table the logic inside each state. A subscription service illustrates it — the state model handles Trial → Active → PastDue → Cancelled with events (renew, payment-fail, cancel, restore), and inside the Active→PastDue transition a decision table governs the dunning logic: grace period × payment method × retry count × plan type → action (retry, notify, downgrade, suspend). Neither diagram alone is sufficient: the state model without the table cannot say what PastDue does; the table without the model cannot say when its rules run. Each artifact's test cases then target different bugs: the state suite finds sequence defects (restore after cancel is ignored), the table suite finds rule defects (grace period ignored for annual plans).

The senior-level question that closes the topic: where do these techniques end and defects still escape? Three honest limits. First, tables and diagrams cover the modeled logic; they say nothing about timing (what if the renewal job runs twice concurrently — now you need concurrency testing), data volume (dunning with 100,000 due invoices), or the UI's fidelity to the model (the API honors Cancelled but the screen still shows a Cancel button). Second, the model is only as good as the spec-reading behind it: a missing state is invisible forever — which is why the diagram review with product and support (support knows which state combinations users actually reach) is not optional. Third, state explosions in real systems (an order with five line items each in one of four states is 4^5 = 1,024 joint states) push you back toward risk-based sampling — cover the pairwise joint states for the critical path and state the exclusion.

For interviews, the durable takeaway to state plainly: decision tables and state transitions are specification instruments first, test generators second — they force ambiguity (a disputed cell, a missing edge) into the open while it is still a text edit. Candidates who describe finding a requirement defect by building the table, and name the coverage level they chose for the lifecycle suite, consistently read as practitioners. The next technique in this phase takes on the case these two deliberately leave alone — many-parameter configurations like browsers × OS × devices — in Pairwise Combination Testing.