State transition testing
State transition testing is a test design technique for software whose behaviour depends on what has already happened to it: an order that can be paid, shipped, refunded or cancelled, a session that is signed in or expired. The tester draws the states, the events that move between them and the transitions that must be impossible, and each transition, valid and invalid, becomes a test case.
The longer version
The technique begins with a model. Each state the system can be in is a node; each event that can arrive is an arrow leading to the state the event should produce. Pay moves an order from placed to paid, ship moves paid to shipped, refund moves shipped to refunded. The same events are then applied to the states where they should not apply: ship on an unpaid order, refund on a cancelled one. A state table lists every state against every event and says what should happen in each cell, and the cells that say nothing or error are the ones that get skipped when the tests are written from the happy path.
Decision table testing asks how several conditions combine at one moment; state transition testing asks how a sequence of events accumulates over time. A discount rule is a decision table; a subscription that can be paused, resumed, upgraded and cancelled is a state machine, and the bugs in it are ordering bugs: resume after cancel, upgrade while paused. The two techniques are complementary, and a system with both kinds of logic needs both tables.
The characteristic bug is an event handled in a state it was never meant to reach: a duplicate webhook that marks an already-refunded order paid, a submit button clicked twice that creates two records, a token refreshed after the session was revoked. These are bugs of omission, and they survive because the code checks for the events it expects and ignores the rest. The technique fails when the model is drawn from the code rather than from the requirement, since a model of the code reproduces its omissions, and when the invalid transitions are drawn and then skipped because they cannot happen from the interface. They can from a second tab.
Common questions
What is the difference between state transition testing and decision table testing?
A decision table covers the combinations of conditions that hold at one moment and the action each combination produces. State transition testing covers sequences: which events are allowed from which state and where each leads. A pricing rule is a table; an order life cycle is a state machine. Systems with both kinds of logic need both.
What is an invalid transition in state transition testing?
An invalid transition is an event arriving in a state where it should have no effect or should be rejected: shipping an unpaid order, refunding a cancelled one, resuming a subscription that was never paused. Testing them matters more than testing the valid ones, because the valid paths are the ones developers already ran.
What is a state transition table?
A state transition table lists every state as a row and every event as a column, and each cell says what the system should do when that event arrives in that state: move to another state, stay put, or raise an error. Filling the cells that the diagram left blank is what turns the drawing into a complete set of cases.
What kinds of software need state transition testing?
Anything whose response to an event depends on its history: an order life cycle, a subscription that can be paused and resumed, a document that moves through draft, review and published, a login session with sign-in, timeout and revocation, a payment that can be authorised, captured and refunded. A feature whose behaviour is the same whatever happened before it does not need the technique.
How is a state transition diagram used to write test cases?
Each arrow in the diagram becomes a test case for a valid transition: put the system in the source state, send the event, check it reached the target state. The arrows that are missing become test cases for invalid transitions: send the event in a state where no arrow leaves, and check the system rejects it or stays put. Longer cases chain arrows to cover the sequences the diagram allows.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.