Test Case Design Technique: State Transition Testing
Overview
State Transition Testing is a black-box test design technique used when the system behaves differently based on its current state and events or inputs that cause it to transition to another state.
This technique is especially useful for workflow-based systems, user interfaces, authentication systems, and anything involving finite state machines.
Why Use State Transition Testing?
- Helps test systems with sequential logic and state dependencies
- Ensures coverage of all valid and invalid transitions
- Captures real-world behavior better than input/output-only testing
- Identifies missing or undefined states or transitions
Key Concepts
- State: A condition or situation of the system (e.g., "Logged In", "Locked").
- Transition: A change from one state to another triggered by an event or input.
- Event/Input: The trigger that causes a transition (e.g., "Enter Password").
- Action: The result or behavior that occurs during the transition.
Example: ATM Card Authentication
States:
- Idle
- Card Inserted
- PIN Entered
- Authenticated
- Card Locked
Events:
- Insert card
- Enter PIN
- Enter wrong PIN 3 times
- Eject card
State Transition Table
Current State | Event | Next State | Action |
---|---|---|---|
Idle | Insert card | Card Inserted | Prompt for PIN |
Card Inserted | Enter valid PIN | Authenticated | Show main menu |
Card Inserted | Enter wrong PIN | Card Inserted | Show error |
Card Inserted | 3 wrong PINs | Card Locked | Lock card, keep card inside |
Any State | Eject card | Idle | Return card |
State Diagram
(Use a diagramming tool to visualize if needed)
[Idle] → Insert Card → [Card Inserted]
└── Eject ───────┐
[Card Inserted] → Enter Valid PIN → [Authenticated]
↓ Wrong PIN ×3
[Card Locked]
Test Scenarios
-
Valid Flow
- Insert card → Enter correct PIN → Authenticated
-
Invalid PIN Flow
- Insert card → Enter wrong PIN ×3 → Card Locked
-
Cancel Midway
- Insert card → Eject card → Idle
-
Edge Case
- Insert card → Enter wrong PIN twice → Correct PIN → Authenticated
When to Use State Transition Testing
- Systems with workflow or status-based logic
- Login/authentication modules
- Shopping carts, order processing, ticket booking
- Devices with mode-based behavior (e.g., mobile phone: Locked → Unlocked → Sleep)
Best Practices
- Use state diagrams to visualize system behavior
- Ensure test cases cover all transitions, not just the "happy path"
- Include negative transitions (e.g., invalid input, unauthorized states)
- Test illegal transitions and system responses to unexpected states
Summary
State Transition Testing helps QA engineers model the dynamic behavior of systems where actions depend on history or system state. It ensures that the software behaves correctly across all possible flows and not just one-off conditions.
“If your system can be in multiple states, don’t just test the inputs—test the journeys.”
Quick Template
Test Case ID | Current State | Input/Event | Expected Next State | Expected Action |
---|---|---|---|---|
TC01 | Idle | Insert card | Card Inserted | Prompt for PIN |
TC02 | Card Inserted | Wrong PIN x3 | Card Locked | Card retained, access denied |
TC03 | Authenticated | Eject card | Idle | Card returned |