State Transition Testing for Testers

State transition testing uses a model of states and transitions (e.g. a state diagram) to design test cases. When behavior depends on the current state (e.g. order: draft → submitted → paid), this technique helps you cover valid and invalid transitions. This post introduces the idea and how to apply it.

What is state transition testing?

• States: Distinct conditions the system can be in (e.g. "logged out," "logged in," "cart empty," "cart has items").
• Transitions: Events or actions that move the system from one state to another (e.g. "login" moves from logged out to logged in).
• Test design: Design tests that cover valid transitions (expected behavior) and invalid transitions (e.g. submit when not allowed → error or no change).

Building a state diagram

1. List all states (e.g. Draft, Submitted, Approved, Rejected).
2. List events/actions that can occur (e.g. Submit, Approve, Reject).
3. Draw transitions: From state A, event X leads to state B (or to error). Mark invalid transitions (e.g. Approve from Draft → not allowed).
4. Identify initial and final states if relevant.

Designing test cases

• Valid path: One test per valid transition (e.g. Draft → Submit → Submitted).
• Invalid transition: One test per invalid transition (e.g. Approve from Draft → 400 or error message; state unchanged).
• Coverage: Cover every transition at least once; add paths for critical flows (e.g. full happy path, full rejection path).

When to use it

Use state transition testing when:

• Behavior clearly depends on state (e.g. order, ticket, approval workflow).
• You want to avoid missing transitions or invalid cases.
• The team can agree on a state diagram (helps requirements clarity too).

Summary

• State transition testing = states + transitions; design tests for valid and invalid transitions.
• Build a state diagram (states, events, transitions); derive test cases from it.
• Use it for workflows and stateful behavior; it improves coverage and clarity.