State Transition Testing — Learn How to Test (Junior)

1 The Hook — Why This Matters

A user logs in, adds items to their cart, reaches checkout, then hits the browser Back button. The cart is empty. All their items are gone.

The developer had coded the happy path beautifully: Cart → Checkout → Payment → Done. But they forgot to handle Back from checkout → return to cart with items preserved. That transition didn't exist in their mental model.

State transition testing would have caught it. Because it forces you to ask: "What happens when the user does something unexpected at every state?"

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 link — it's an event that changes state. If you test only the happy path, you miss the bugs that real users find every day.

3 The Analogy — Think Of It Like...

Analogy

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.

4 Watch Me Do It — Worked Examples

Example 1 — Login with Lockout

States: Logged Out → Attempt 1 → Attempt 2 → Locked → Logged In

Transition	From State	Event	To State
T1	Logged Out	Valid login	Logged In
T2	Logged Out	Invalid login	Attempt 1
T3	Attempt 1	Invalid login	Attempt 2
T4	Attempt 1	Valid login	Logged In
T5	Attempt 2	Invalid login	Locked
T6	Attempt 2	Valid login	Logged In
T7	Locked	Admin unlock	Logged Out
T8	Locked	Valid login	Locked (blocked)

Happy path: T1. Lockout path: T2 → T3 → T5. Recovery path: T7. Invalid transition: T8 (login while locked should fail).

Example 2 — E-commerce Order

States: Cart → Checkout → Payment Pending → Paid → Shipped → Delivered

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	Paid	Yes
T4	Paid	Dispatch	Shipped	Yes
T5	Shipped	Deliver	Delivered	Yes
T6	Cart	Cancel	Cancelled	Yes
T7	Checkout	Cancel	Cart	Yes
T8	Shipped	Cancel	Shipped	No — invalid
T9	Delivered	Cancel	Delivered	No — invalid

T8 and T9 are invalid transitions. The system should reject them gracefully — not crash, not refund without approval, not disappear the order.

Coverage Levels

All-States: Every state is visited at least once. Minimum viable coverage.
All-Transitions (0-switch): Every valid transition is exercised at least once.
1-Switch: Every pair of consecutive transitions is tested (e.g., Cart → Checkout → Payment Pending).

Most junior testers stop at All-States. Good testers aim for All-Transitions. Thorough testers hit 1-Switch coverage for critical workflows.

5 When to Use It — Decision Tool

✅ Use state transition 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

❌ Don't use state transition 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)

6 Common Mistakes — Don't Do This

🚫 Only testing the happy path

I used to think: If the normal flow works, the feature is done.
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.

🚫 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.

🚫 Missing initial state / not resetting

I used to think: Tests can pick up from wherever.
Actually: Every test should define its start state. If you don't reset to "Logged Out" before testing login, your test is fragile and may pass for the wrong reason.

🚫 Creating one giant diagram

I used to think: One diagram should cover the whole app.
Actually: Break into focused diagrams per feature. A single diagram with 20 states is unreadable. Three diagrams with 6 states each is testable.

🚫 Not testing guard conditions

I used to think: If the event exists, the transition happens.
Actually: Transitions often have guards — conditions that must be true. "Pay" only works if balance > 0. Test the transition when the guard is false too.

🚫 Forgetting time-based events (timeouts)

I used to think: Events are always user actions.
Actually: A session timeout is an event. A payment expiry is an event. A scheduled state change is an event. Time-based transitions are among the most bug-prone because developers rarely test them manually.

7 Now You Try — Document Approval

🎯 Interactive Exercise

Spec: A document approval system.

States: Draft → Submitted → Under Review → Approved / Rejected
Events: Submit, Approve, Reject, Request Changes

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	Draft	Approve	Can't approve a document that hasn't been submitted for review.
2	Approved	Reject	Once approved, the document is final. Rejection should happen during review, not after approval.
3	Rejected	Approve	A rejected document should return to Draft or be archived. Direct approval skips review.

Bonus: What about "Under Review → Submit"? That's invalid too — you can't submit a document that's already under review. And "Draft → Reject"? Also 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. What's 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.

Q2. Why do invalid transitions matter if users "shouldn't" do them?

Because users will do them — hit Back, refresh, double-click, manipulate URLs, or trigger race conditions. If the system crashes, leaks data, or corrupts state on an invalid transition, that's a real bug. Invalid transitions must be handled gracefully.

Q3. What's the difference between All-States, All-Transitions, and 1-Switch coverage?

All-States = visit every state at least once. All-Transitions (0-Switch) = exercise every valid transition at least once. 1-Switch = test every pair of consecutive transitions (A→B→C). Each level is stronger than the last. All-Transitions is the standard target for most features.