State Transition Testing
Software isn't just a static form; it's a lifecycle. Learn how to track an object as it moves from one status to another — and how to catch the bugs that happen when things move in the wrong order.
1 The Hook — The Ghost Listing
A tester at a NZ marketplace app once found a "Ghost Listing" bug. A user had sold their old surfboard (State: Sold), but they discovered that if they hit the browser "Back" button and clicked "Edit," they could change the price and put it back to Active — even though the money was already in their account.
The system allowed an impossible transition: Sold → Active. This caused data corruption and a massive headache for the finance team. State Transition Testing exists to kill "Ghost" actions before they hit production.
2 The Rule — The Four Pillars
Model every state the system can be in, and every event that moves it to a new state.
A state model consists of four things:
- State: The current status (e.g., Draft, Active).
- Event: The trigger (e.g., Click "Publish").
- Transition: The movement from A to B.
- Action: What happens (e.g., Send confirmation email).
3 The Analogy — The Train Station
The Auckland Metro Map.
You can't get from Britomart to Newmarket without passing through Parnell. The track is the "Transition." The stations are the "States." If a train suddenly appears in Newmarket without going through Parnell, something is broken. State Transition Testing is checking the tracks to make sure trains can't teleport to impossible stations.
4 Watch Me Do It — TradeMe Listing
Scenario: You're testing a marketplace listing lifecycle. Here is the valid path.
| Current State | Event | Next State | Action |
|---|---|---|---|
| Draft | Click "List Item" | Active | Deduct listing fee |
| Active | Buyer clicks "Buy Now" | Sold | Send "You won" email |
| Active | Listing duration ends | Expired | Notify seller |
| Expired | Seller clicks "Relist" | Active | Reset duration |
| Sold | Seller clicks "Edit" | Invalid | Error: Sold items locked |
The "Invalid" row is just as important as the valid ones. You must verify that the system prevents the edit on a sold item.
5 Decision Tool — How much to test?
✅ 0-Switch Coverage
- Visit every State at least once.
- Best for: Quick sanity checks.
- Weakness: Misses broken transition paths.
🛡 1-Switch Coverage
- Visit every Transition once.
- Best for: ISTQB Standard / Regression.
- Strength: Confirms every path works.
6 Common Mistakes
🚫 Forgetting the "Same State" Loop
I used to think: Transitions only happen when the status changes.
Actually: Saving a Draft keeps it in Draft. That's a transition from Draft to Draft. You must test that saving doesn't accidentally trigger a "Published" state.
🚫 Testing only the happy path
I used to think: If it gets from Draft to Sold, it's fine.
Actually: You must try to "break" the order. Try to Dispatch an item that hasn't been Paid yet. These invalid transitions are where security bugs hide.
7 Now You Try — NZ Library Books
Scenario: A library book starts as Available. A member borrows it.
Identify the States and Events for this simple flow:
Initial State
Available
Trigger Event
Book Checked Out
Next State
On Loan
Invalid Transition?
Available → Overdue (Must be "On Loan" first!)
8 Self-Check
Q1. What is the difference between a State and an Action?
State is a status (e.g., Pending). Action is what the system does during the move (e.g., Sends an Email). You are in a State; you perform an Action.
Q2. Why do we test "Invalid" transitions?
To ensure the system is Robust. If a user can bypass a state (e.g., skip Payment and go to Dispatched), it's a critical logic or security bug.
9 Interview Prep
"What is 1-switch coverage in State Transition testing?"
Answer: "1-switch coverage means that every valid transition in the state model has been exercised at least once by our test cases. While 0-switch only visits every state, 1-switch ensures that every path between states is functional, which is the industry standard for foundation-level testing."
10 Next Step
Now that you've mastered state cycles, let's look at testing from the User's Perspective. Next: Use Case Testing.