Q9 of 38 · Test design
Design test cases for a multi-step wizard using state transition testing.
Short answer
Short answer: Model each wizard step as a state, transitions between them as user actions ('next', 'back', 'save and exit'), and design tests that cover every state, every valid transition, and the most-likely invalid transitions (skipping, refreshing, going back to a step with stale data).
Detail
A multi-step wizard is a near-perfect candidate for state transition testing because the bugs cluster in transitions: data loss when navigating back, validation on the wrong step, partial submissions, and recovery after the user refreshes the page.
Step 1: Map the states and transitions. A 4-step "create account" wizard: Step1 (email) → Step2 (profile) → Step3 (plan) → Step4 (confirm) → Submitted, plus error states (Validation Error per step, Session Expired, Network Failure).
Forward transitions: Next from each step. Backward: Previous, restoring previously entered data. Side: Save-and-exit (creates a draft); Cancel (discards everything). Failure: Validation error stays on the same step; session expiry kicks back to Step1; network failure stays on the current step with retry.
Step 2: Derive coverage:
- State coverage (every state visited): 8 cases minimum, one per state.
- Transition coverage (every valid transition exercised): forward through all 4 steps; backward at each step; save-and-exit at each step; cancel from each step.
- Invalid transition coverage: try to skip Step2 by submitting from Step1's URL; submit Step3's form with Step2 not completed; refresh on Step3 — does state survive?
Step 3: Add data integrity tests around transitions:
- Enter data in Step2 → go back to Step1 → return to Step2 → data should still be there.
- Enter data in Step2 → close browser → reopen → resume? Or start over? Test per spec.
- Enter Step3 → go back to Step1 → change email → does Step3 reset, or are we now confirming a stale combination?
Step 4: Add the meta-tests:
- URL-direct access — typing /wizard/step3 directly should redirect to step1 if not started, or land on step3 if data is in place.
- Browser back-button vs in-app back button — both should produce sensible behaviour.
- Two tabs editing the same wizard — usually causes data corruption if not handled.
A senior tester knows that wizards are bug magnets and explicitly probes the cross-product of state × user-behaviour, not just the linear path.