Glossary · Test design
State transition testing
Also called: state transition diagram, state transition diagrams, state transition table, state-based testing
Definition
A test design technique that models a system as states and the events that move it between them, then tests valid and invalid transitions.
State transition testing applies when the system’s response depends on what happened before, not just on the current input. You model the system as a set of states, the events that cause transitions between them, and any actions or guards on each transition. Tests then cover the valid transitions and, just as importantly, check that invalid transitions are rejected.
Example: login lockout
An account locks after three consecutive wrong passwords, and a successful login resets the count.
States: Active (0 failures), 1 failure, 2 failures, Locked, Logged in.
| Current state | Event | Next state |
|---|---|---|
| Active (0) | Wrong password | 1 failure |
| Active (0) | Correct password | Logged in |
| 1 failure | Wrong password | 2 failures |
| 1 failure | Correct password | Logged in (count reset) |
| 2 failures | Wrong password | Locked |
| 2 failures | Correct password | Logged in (count reset) |
| Locked | Correct password | Locked (rejected) |
| Locked | Admin unlock | Active (0) |
Tests derived from it:
- Every valid transition at least once (0-switch coverage): wrong, wrong, wrong leads to Locked; wrong, correct leads to Logged in.
- Invalid or unexpected events: the correct password on a locked account must still be rejected. This is where security bugs hide.
- Sequences: wrong, correct, then logout and wrong, wrong. Is the count really reset, or does the account lock on the second failure? Testing pairs of consecutive transitions is called 1-switch coverage.
Where it applies
Anything with a lifecycle: orders (created, paid, shipped, delivered, cancelled, refunded), bug workflows, subscriptions, document approvals, payment states, media players, and UI wizards. Questions worth asking for each state: which events are allowed here, what happens to disallowed ones, and can the user reach this state by an unexpected route, such as the browser back button or a direct API call?
Common mistakes
- Testing only the happy path. Created, paid, shipped is one path. Can an order be cancelled after shipping? Refunded twice?
- Testing only through the UI. The UI may hide the Cancel button, but the API might still accept the request. Test transitions at the API level too.
- Missing the state table. The diagram shows what should happen; the full table of every state against every event shows the gaps where behavior is undefined.