State Transition Testing
Catch workflow and lifecycle bugs that happy-path testing misses. Model the system as states and transitions, then test every valid path and every invalid one.
1 The Hook — Why This Matters
A major NZ online retailer launched a new order management system. A customer placed an order, paid with credit card, then changed their mind and hit Cancel. The order status flipped to Cancelled and the refund processed. So far, so good.
But the warehouse didn't know about the cancellation. The order had already reached Shipped status in the fulfilment system. The package turned up at the customer's door in Christchurch two days later. The customer kept the item and got a full refund. When the retailer tried to recharge the customer, the payment gateway refused because the original transaction had been reversed.
The bug? The e-commerce platform allowed a Cancel event on a Shipped order — an invalid transition that never should have been possible. It cost the retailer $47,000 in lost stock and chargeback fees in the first month alone. State transition testing would have caught it on day one.
2 The Rule — The One-Sentence Version
Model the system as states and transitions. Test every valid path and every invalid transition.
A state isn't a screen — it's a condition the system is in. A transition isn't a button click — it's an event that changes state. If you only test the happy path, you miss the bugs that real users find when they hit Back, refresh, timeout, or cancel at the worst possible moment.
3 The Analogy — Think Of It Like...
A washing machine.
Idle → Fill → Wash → Rinse → Spin → Done. You can't go from Idle to Spin. You can't go from Done back to Wash without resetting. Each state only accepts certain events. The "door open" event might pause at any state. State transition testing is making sure your software washing machine doesn't flood the laundry by accepting a spin command while the door is open.
4 Watch Me Do It — Step by Step
Here is a real NZ example using an e-commerce order lifecycle. Follow these steps every time you test a workflow or stateful feature.
Scenario: An NZ online store processes orders through a lifecycle. States are Cart → Checkout → Payment Pending → Authorized → Captured → Shipped → Delivered. Events include: proceed, pay, confirm, dispatch, deliver, cancel, refund, and payment fail.
- Identify the states List every distinct condition the order can be in. Don't confuse screens with states. "Checkout" and "Payment Pending" might look similar to the user, but they are different states because different events are allowed.
- Identify the events List every action that can change state: user actions (pay, cancel), system actions (timeout, payment confirmed), and time-based events (auto-cancel after 48 hours).
- Identify the transitions For each state, ask: "What events are allowed here?" and "What state does each event lead to?" Write them all down, even the ones that seem obvious.
- Draw the state diagram A visual diagram forces you to see gaps. If you can't draw a transition, you can't test it. Keep diagrams small and focused — one per major entity.
- Create the state transition table A table catches transitions that diagrams miss. List every from-state, event, to-state combination. Mark invalid transitions explicitly.
-
Determine coverage level
- All-States (weak): visit every state at least once
- All-Transitions / 0-Switch (standard): exercise every valid transition at least once
- 1-Switch (thorough): test every pair of consecutive transitions
- Invalid transitions: always included — non-negotiable
- Derive and document test cases Every test case needs: start state, event, expected end state, and any guard conditions (e.g., "only if payment > $0"). Ambiguous expected results make failures impossible to judge.
| Transition | From State | Event | To State | Valid? |
|---|---|---|---|---|
| T1 | Cart | Proceed to checkout | Checkout | Yes |
| T2 | Checkout | Pay | Payment Pending | Yes |
| T3 | Payment Pending | Payment confirmed | Authorized | Yes |
| T4 | Authorized | Capture funds | Captured | Yes |
| T5 | Captured | Dispatch | Shipped | Yes |
| T6 | Shipped | Deliver | Delivered | Yes |
| T7 | Cart | Cancel | Cancelled | Yes |
| T8 | Checkout | Cancel | Cart | Yes |
| T9 | Delivered | Request refund | Refunded | Yes |
| T10 | Shipped | Cancel | Shipped | No — invalid |
| T11 | Payment Pending | Payment fail | Checkout | Yes |
| T12 | Delivered | Cancel | Delivered | No — invalid |
| Test case | Path | Coverage |
|---|---|---|
| Happy path | Cart → Checkout → Payment Pending → Authorized → Captured → Shipped → Delivered | All-States |
| Cancel before pay | Cart → Checkout → Cancel → Cart | All-Transitions |
| Payment failure recovery | Cart → Checkout → Payment Pending → Payment fail → Checkout → Pay → Authorized | 1-Switch |
| Refund path | Delivered → Refunded | All-Transitions |
| Invalid: cancel after ship | Shipped → Cancel → rejected | Invalid transition |
| Invalid: cancel after delivery | Delivered → Cancel → rejected | Invalid transition |
5 The Decision Tool — When to Use It
✅ Use state transition testing when...
- The feature has a workflow or lifecycle (draft → published)
- Session management matters (login, timeout, resume)
- History-dependent behaviour (what you can do depends on what happened)
- Events can happen out of order or at unexpected times
- Guard conditions control whether a transition is allowed
- Time-based events change state (auto-lock, session expiry)
❌ Don't use state transition testing when...
- The system is stateless (each request is independent)
- It's a simple single-step function (calculator add)
- There are no restrictions on order of operations
- The "state" is just UI cosmetic (dark mode toggle)
- You don't have access to state information for verification
Before you apply state transition testing, ask:
- Does your app have a state machine or workflow?
- Are there restrictions on which transitions are allowed?
- Can events happen out of order or at unexpected times?
6 Common Mistakes — Don't Do This
🚫 Only testing the happy path
I used to think: If Cart → Checkout → Pay → Done works, the feature is tested.
Actually: Real users hit Back, refresh, double-click, timeout, and cancel. The happy path is usually the only path developers test. Your job is to find what they missed. If you don't test payment failure, refund after delivery, and cancel-after-ship, you're not doing state transition testing.
🚫 Confusing screens with states
I used to think: Every page is a state.
Actually: A state is a condition the system is in, not a URL. The "Checkout" page might actually be two states: "Checkout (valid cart)" and "Checkout (empty cart)" with different allowed transitions. One screen can represent multiple states, and one state can appear on multiple screens. Test the state, not the screen.
🚫 Forgetting invalid transitions
I used to think: If a transition isn't in the spec, users won't do it.
Actually: Users will absolutely do it — hit Back, refresh, double-click, manipulate URLs, or trigger race conditions. Invalid transitions verify robustness. If the system crashes, leaks data, or corrupts state on an invalid transition, that's a real bug that affects real users. The Christchurch retailer learned this the hard way.
When state machine testing fails
Missing transition paths allow users to reach invalid states or corrupt the workflow. This is common in systems with concurrent events (payments overlapping with cancellations) or when guard conditions are checked inconsistently on frontend vs. backend.
7 Now You Try — AT HOP Card Top-Up
Scenario: Auckland Transport's AT HOP card top-up system has the following states and events:
- States: Idle → Card Scanned → Amount Selected → Payment Processing → Topped Up / Failed
- Events: Scan card, Select amount, Confirm payment, Payment success, Payment fail, Cancel, Remove card
Your task: Identify 3 invalid transitions. For each, state the from-state, the event, and why it should be invalid.
| Invalid transition | From state | Event | Why invalid? |
|---|---|---|---|
| 1 | ? | ? | ? |
| 2 | ? | ? | ? |
| 3 | ? | ? | ? |
| Invalid transition | From state | Event | Why invalid? |
|---|---|---|---|
| 1 | Idle | Select amount | You can't select a top-up amount before scanning a card. The system doesn't know which card to credit. |
| 2 | Topped Up | Confirm payment | The transaction is complete. Confirming payment again could trigger a duplicate charge. |
| 3 | Payment Processing | Select amount | Changing the amount mid-transaction would create a mismatch between the authorised amount and the credited amount. |
Bonus: What about "Card Scanned → Confirm payment" without selecting an amount? Also invalid. And "Failed → Remove card → Topped Up"? Absolutely invalid. How many did you find?
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you're ready to practice.
Q1. Why are invalid transitions important if users "shouldn't" do them?
Real users do unexpected things — hit Back, refresh, double-click, manipulate URLs, or trigger race conditions. Invalid transitions verify robustness. If the system crashes, leaks data, or corrupts state on an invalid transition, that's a real bug that affects real users. Invalid transitions are non-negotiable in any state transition test plan.
Q2. What's the difference between All-States, All-Transitions, and 1-Switch coverage?
All-States means every state is visited at least once (weak coverage). All-Transitions (0-Switch) means every valid transition is exercised at least once (standard coverage). 1-Switch means every pair of consecutive transitions is tested (thorough coverage). Each level is stronger than the last. All-Transitions is the standard target for most features.
Q3. A state diagram has 5 states and 8 valid transitions. How many invalid transitions should you test?
Test every invalid transition you can identify — there is no fixed number. For each state, list every event that is not allowed. If state A doesn't accept event X, that's an invalid transition. In practice, prioritise invalid transitions that could cause financial loss, data corruption, or security issues.
9 Interview Prep — Know These Cold
These are questions Kiwi employers actually ask junior testers. Have an answer ready.
Q1. What is state transition testing and when would you use it?
State transition testing is a black-box technique that models the system as states and transitions, then derives test cases to cover valid paths and invalid transitions. Use it when testing workflows, lifecycles, session management, or any feature where the allowed actions depend on the current condition of the system.
Q2. Why are invalid transitions important?
Real users do unexpected things. Invalid transitions verify robustness. If the system crashes, leaks data, or processes unauthorised actions on an invalid transition, that's a real bug. Testing only valid transitions gives false confidence.
Q3. What is the difference between a state and a screen?
A screen is what the user sees (a URL or page). A state is the condition the system is in. One screen can represent multiple states, and one state can appear on multiple screens. Test the state, not the screen.
10 Link to Reference
Want the full theory, ISTQB syllabus mapping, and advanced coverage strategies?
→ State Transition Testing — Full Library Reference
Includes the formal ISTQB definition, coverage level deep dive, and real-world worksheets for login lockout and e-commerce lifecycles.
11 Next Step
You now know how to model states and test transitions. The next skill is deriving test cases from user goals and use cases — testing end-to-end from the user's perspective.