State Transition Testing

A booking isn't a single screen — it's a thing with a life. It gets created, confirmed, checked into, completed; sometimes cancelled along the way. Some moves between those stages are legal, some must be impossible — and bugs adore the impossible ones. State transition testing turns a lifecycle into a diagram and tests the arrows: every legal move works, and — the part beginners skip — every forbidden move is properly refused.

Traffic lights are the whole idea in miniature. Green, then yellow, then red is the legal cycle. A light that jumps from red straight to green with no yellow isn't showing personality — it's an accident about to happen. The rules of a traffic light aren't about the colors; they're about the allowed moves between them. So are the rules of a booking.

States, Events, Transitions

Three words and you own the vocabulary. A state is a mode of being — a booking is pending or confirmed, not both, not neither. An event is a thing that happens — payment succeeds, the traveler clicks cancel, check-in day arrives. A transition is a legal move from one state to another, triggered by an event: pending, on payment success, becomes confirmed. Draw states as boxes, transitions as arrows labeled with their events, and the resulting sketch — a state diagram — is the technique's whole apparatus. Boxes and arrows on paper; no tools required.

Fernway's Booking Lifecycle, Made Canonical

Here is the diagram you'll reuse for the rest of the book. A new booking starts pending — created, awaiting payment. Payment success moves it to confirmed. Check-in day arrives and the traveler shows up: checked-in. The stay ends: completed. And from pending or confirmed — but only those — cancellation is reachable: cancelled, with the 48-hour rule deciding whether it's free. Five states, six legal transitions, and everything else forbidden by omission: there is no arrow from completed to cancelled, no arrow from cancelled to checked-in, no arrow from pending to checked-in that skips payment.

pendingawaiting payment

→

confirmedpaid · cancellable

→

checked-instay in progress

→

completedterminal — no exits

(The fifth state, cancelled, branches off pending and confirmed — also terminal. A linear figure can't draw the branch; your paper sketch can, and should.)

Testing the Valid Paths

The first coverage target: every state visited, every legal transition exercised at least once. The happy path — pending → confirmed → checked-in → completed — is one walk that covers three transitions. Add a cancellation from pending and a cancellation from confirmed, and all six arrows have been traveled. Notice what the diagram just did: it turned "test the booking lifecycle," a vague instruction, into a checklist of six specific journeys with defined start points, triggers, and destinations. That's the same move every technique in this chapter makes — vague to precise — applied to time instead of inputs.

Testing the Forbidden Arrows

Now the part that separates trained testers. Every arrow not on the diagram is a test too: attempt the move, and the system must refuse correctly — a clear error, an unchanged state, no half-transition. Cancel a completed booking: refused? Pay a second time for a booking that's already confirmed: refused, or double-charged? Check into a cancelled booking: surely impossible — but is it? Beginners assume forbidden moves can't happen because no button exists for them. Reality disagrees: double-clicks fire events twice, back buttons resurrect old screens, two browser tabs hold the same booking in different states, and slow networks deliver yesterday's click today. The forbidden arrows get attempted daily, by accident, at scale — and "refuses correctly" is a pass/fail outcome like any other.

The Missing Arrow: FW-356

Drawing Fernway's diagram, you notice something before running a single test. Pending has an arrow out for payment success. What about payment failure? Paylane says no — declined card, expired card, timeout. The story never mentions it. Omar checks the code: nothing handles it. The booking stays pending forever, silently holding the room — a phantom reservation blocking real travelers from booking it. FW-356, found by drawing, before any execution — the static-testing lesson of Chapter 3 wearing its test-design clothes. Every event that can happen in a state needs a defined destination, and "the diagram has no arrow for this event" is a requirements question, exactly like the decision table's empty cell.

Where This Technique Shines

Anything with a lifecycle: orders, accounts (active, suspended, deleted), documents (draft, review, published), subscriptions (trial, active, past-due, cancelled), support tickets. The tell is in the requirement's vocabulary — the moment you read the word status, draw the diagram. Ten minutes of boxes and arrows buys you: a checklist of legal journeys, a hit-list of forbidden moves, and — as FW-356 proved — the missing-arrow questions nobody answered. It's the highest-yield sketch in testing.