What do blank cells in a state transition table mean, and how do you test them?

### The table form and why it exposes gaps A state transition diagram shows what the system *does*. A state transition table shows the same information as a grid — states as rows, events as columns — and its value is that it also shows what the system does *not* do, as empty cells. A warehouse stock ledger with six states (Draft, Reserved, Picked, Shipped, Cancelled, Expired) and seven events (reserve, amend, cancel, expire, pick, ship, split) yields a grid of forty-two cells. If ten arrows were specified, thirty-two cells are blank. The diagram makes those thirty-two invisible; the table makes them a checklist. ### Three different meanings of an empty cell The word "blank" hides a distinction that matters for what you assert: - **Rejected (invalid event).** The specification says this event is not allowed here and the system must refuse it — an error response, a rejection code, an audit entry — with no state change. - **Ignored.** The specification says the event is absorbed with no effect and no complaint. Common for idempotent or duplicated messages: firing cancel on an already-cancelled row is a no-op, not an error. - **Undefined.** Nobody decided. The cell is blank because the requirement is silent, not because silence was chosen. This is a specification defect. Raising it is part of the tester's job and is usually worth more than the test case you would otherwise write. The distinction between rejected and ignored is a real interview trap, because both leave the state unchanged and both look identical if your only assertion is on the state. Only the response and the side effects tell them apart, so decide which the requirement wants before writing the assertion. ### Sneak paths A **sneak path** is a transition the implementation has and the model does not. Nothing in positive transition coverage can find one: every arrow you drew passes, and the extra arrow is by definition not drawn. The only way in is through the blank cells — reach the state, fire the event, and see whether anything moves. A concrete shape it takes: in that ledger, the cell for state Picked and event reserve was blank, and nobody had discussed it. The implementation accepted it, placed a *second* stock hold, and left the first one in place, since the release only ran on the Reserved-to-Cancelled arrow. An overnight retry loop drove that cell 2,148 times and exhausted the ledger's pool of hold rows, at which point no new reservation anywhere in the warehouse could be created — a resource exhaustion whose root cause was one untested blank cell. The team of eleven had full 0-switch coverage and a green suite throughout. ### Unreachable states and dead arrows The table also shows the opposite gap. Read a column of targets: if a state never appears as any transition's target, it is **unreachable** — either an arrow is missing from the model or the state is dead and should be deleted. If a state has no outgoing arrows and is not meant to be terminal, it is a trap state, and something that entered it can never leave. Both are model review findings you get for free from the tabular form, before a single test runs. ### How many blank cells to test Thirty-two negative cases is often more than the feature is worth, so prioritise rather than pretending you will do them all: - Cells whose event **allocates or releases a resource** — those are the ones with a failure mode worse than a wrong error message. - Cells reachable by a **realistic** sequence: a retry, a duplicate message, a stale client, a double-click. Cells only reachable by an internal call nobody can make from outside score lower. - Cells around **terminal states**, since post-terminal events are what duplicated and replayed messages produce. - Cells where the requirement is **silent** — write the question up rather than guessing an assertion. ### What to assert For a rejected cell: the specified error is returned, the state is unchanged, and no side effect fired. For an ignored cell: no error, state unchanged, no side effect, and repeating the event stays harmless. In both cases the *no side effect* half is what catches the sneak path, because a sneak path very often leaves the state field alone while quietly doing something underneath — exactly the shape of the hold-leak above. Asserting only the visible state is how a suite stays green while the defect ships.