State Transition Testing

The building blocks in depth

States

A state is a situation that changes how the system reacts to the same input. That definition is the test for whether something deserves to be a state.

• “The order is paid” is a state, because Pay, Cancel and Refund all behave differently once it’s true.
• “The order has a blue shipping label” is not a state if nothing behaves differently because of it.

Two special kinds of state appear in almost every model:

• The initial state is where the system starts: a new order is Placed, a fresh login screen has 0 wrong attempts. On a diagram it’s marked with a small filled dot and an arrow.
• A final state is one the system never leaves: a Canceled or Refunded order. It’s drawn with a double border. Final states are great places to test, because every event there should be rejected.

Events and transitions

An event is anything that can happen to the system. Some come from the user (tap Cancel), some from time (15 minutes pass, the paid parking time runs out), and some from other systems (the courier’s scanner says “delivered”, the bank confirms a payment, a push notificationPush notificationA message an app sends to the device that appears even when the app is closed.Open in glossary → arrives).

A transition is the arrow: in state A, when event E happens, go to state B. A transition can also go back into the same state. A bank card that is Active stays Active after a successful payment, but something still happens: money moves. That’s called a self-transition.

Guards

A guard is a yes/no condition written in square brackets on an arrow, like refund [≤ 30 days since delivery]. The same event in the same state can go different ways depending on the guard:

• Delivered + Refund [within 30 days] → Refunded
• Delivered + Refund [after 30 days] → stays Delivered, with the message “The return window has closed”

Guards are where state transition testing meets boundary value analysisBoundary value analysisTesting values at and just around the edges of valid ranges, where bugs love to hide.Open in glossary →: test day 30 and day 31, not just day 5. And where several conditions combine (amount, country, membership level), a decision tableDecision tableA table listing combinations of conditions and the action the software should take for each.Open in glossary → is the better tool for the guard itself. See boundary value analysis and decision tables.

Actions

An action is what the system does during a transition: charge the card, send the tracking email, reset the counter, release the reserved stock. Written after a slash: cancel / refund payment.

Actions matter because a transition can land in the right state and still do the wrong thing. If canceling a paid order shows “Canceled” but never refunds the money, the state is correct and the customer is still out $84. Always check the state and the action in your expected resultExpected resultWhat should happen when you perform a test step, according to the requirements.Open in glossary →.

Drawing a state diagram from a spec

You don’t need special software. Paper, a whiteboard or any diagram tool works. Here’s the method, using an online shop’s order rules.

State tables: where the bugs hide

The diagram above has 6 states and 5 events. That’s 6 × 5 = 30 combinations, but only 6 arrows. The other 24 combinations are invalid transitions. A diagram doesn’t show them, so nobody thinks about them. A state table does.

You’ll build the full order table in the explorer below (switch it to State table). Here’s a compact version of the most interesting rows:

State	Cancel	Refund	Pay
Placed	Canceled	✕ nothing was paid	Paid
Paid	Canceled / refund	✕ use Cancel	✕ already paid
Shipped	✕ offer a return	✕ not delivered	✕ already paid
Delivered	✕ too late	Refunded [≤ 30 days]	✕ already paid

For every ✕ cell, a correct system does three things:

1. Stays in the same state. Nothing moves.
2. Does no action. No money moves, no email is sent, no stock is released.
3. Tells the user why (if the user caused it), or hides/disables the control in the first place. See buttons and their disabled stateDisabled stateA component that is visible but can't be used right now, usually shown greyed out.Open in glossary →.

How much to test: coverage levels

CoverageTest coverageHow much of the product, requirements or risks your tests actually check.Open in glossary → tells you how much of the model your tests have touched. From weakest to strongest:

Level	What you test	Order example
All states	Each state at least once	6 states, reachable in 2 tests (one ending in Canceled, one in Refunded)
All valid transitions	Each arrow at least once	6 arrows, coverable in 3 tests; the usual minimum
All invalid transitions	Each ✕ cell at least once	24 cells, the high-value negative tests

Visiting every state is not enough. You can visit all six order states without ever trying “cancel a paid order”, and miss that it forgets to refund.

Where it shines in mobile and web apps

OrdersLogin lockoutRide-hailingBank card

Order status is the classic. The same rules usually show up in three places: the customer app, the staff back office, and emails or push notifications. Each one is a door into the same state machine. Things to try:

• Cancel at every state, not just Placed.
• Pay twice: double-tap Pay, or pay from two tabs. This is a double submitDouble submitA bug where an action runs twice because the user tapped or clicked twice quickly.Open in glossary → and the server needs idempotencyIdempotencyAn action that gives the same result no matter how many times it is repeated.Open in glossary → to stop it.
• Refund at every state, especially before payment and after the 30-day guard.

More in shopping cart and checkout.

A login with lockout turns a counter into states: 0 wrong, 1 wrong, 2 wrong, Locked. It protects against a brute-force attackBrute-force attackGuessing passwords or codes over and over until one works.Open in glossary →.

• The third wrong password locks the account (not the second, not the fourth: a boundary!).
• The right password while Locked must still be rejected.
• A successful login resets the counter. Does it? Test 2 wrong → right → log out → 1 wrong: the account must not lock.
• After 15 minutes, can you log in again? What if you kill the app during the lockout?

More in login and sign-up.

A ride-hailing trip has states driven by three different people: the rider, the driver and the system.

• Can the rider cancel On trip? (No: the trip must be ended by drop-off.)
• What happens if the driver accepts at the exact moment the rider cancels? This is a race conditionRace conditionA bug that depends on the timing or order of events, so it only happens sometimes.Open in glossary →, and only one of them can win.
• Is the late-cancel fee charged at 1:59 and at 2:01 correctly?

A bank card in a banking app: Active, Blocked (frozen by the user) and Expired.

• Paying while Blocked must be declined. This is the whole point of the freeze button.
• Unblock needs Face ID or the PIN (the guard). Test it with the check failing.
• An Expired card must not come back to life when someone taps Unblock.

Turning transitions into test cases

Each transition (valid or invalid) becomes one test caseTest caseA written set of steps, data and an expected result used to check one specific behavior.Open in glossary →. The structure maps neatly:

Test case part	Comes from
PreconditionPreconditionSomething that must already be true before you can start a test.Open in glossary →	The start state (and how to get there)
Step	The event (and the guard value)
Expected result	The end state + the action (or “stays, nothing happens”)

Typical bugs

#	Bug	What you see	Typical severity
1	Invalid transition allowed	Delivered order can be canceled and refunded	Critical
2	Paying twice	Double-tap Pay, card charged twice	Critical
3	Refund on an unpaid order	Refund issued for money never received	Critical
4	Lockout ignores the right password	Locked account still logs in with the right password	Critical
5	Stuck state	Order stays “Processing” forever after a network error	Major
6	Wrong state after restart	Paused workout comes back as Running after the app is killed	Major
7	Action missing	Order shows Canceled but no refund is made	Major
8	Final state revived	Old payment link re-opens a canceled order	Major

Bugs 5 and 6 deserve a special mention for mobile. Apps are paused, killed and restored all the time, and the state must come back correctly from the server or from saved data. That’s state persistenceState persistenceWhether the app remembers what the user did after navigating away, rotating, or restarting.Open in glossary → and state restorationState restorationBringing the user back to the same screen and data after the OS closed the app in the background.Open in glossary →. Test transitions across a restart: start in Paused, kill the app, reopen, and check you’re still in Paused. See background and foreground and interruptions.

When you find one of these, the state table makes your bug report easy to write: start state, event, expected state, actual state.

When to use it (and when not to)

Use it when the same input gives different results depending on history: statuses, modes, counters, wizards, sessions, players, anything with “if it’s already X, then…”.

Skip it when the feature has no memory: a unit converter, a tip calculator, a search box. There, equivalence partitioningEquivalence partitioningSplitting inputs into groups that should behave the same, then testing one value from each group.Open in glossary → and boundary value analysisBoundary value analysisTesting values at and just around the edges of valid ranges, where bugs love to hide.Open in glossary → do the work.