Wizard test cases, for the answers that do not survive

Every serious defect in a multi step form is a variant of the same thing: the answers did not survive. They can fail to survive back navigation, a validation error on an unrelated field, a browser refresh, a session expiry, a failed step save, or a second tab. Each of those is a separate test and each produces the same user reaction, which is to stop filling in the form. File attachments are the worst case, because dropping one silently is more damaging than rejecting it outright: the user believes the document was received and finds out weeks later that it was not.

Validation has to happen twice and usually happens once. Checking each step as the user advances is good for the experience but proves nothing about the final payload, because the request that actually creates the record can be modified after the fact. Any wizard that trusts the journey rather than revalidating the complete submission on the server is one altered request away from an invalid record. The same reasoning applies to step gating: hiding navigation to a later step is presentation, and the completeness check belongs on the server.

Duplicate submission is the defect that costs money on any wizard that creates an order, a claim or a payment. Users press submit again when nothing appears to happen, mobile networks drop responses, and clients retry on timeout. A disabled button handles none of those. The server needs an idempotency key generated before the first attempt, and the timeout case needs its own handling: an outcome that is genuinely unknown must not be presented as a failure, because that is exactly what prompts the second submission.

Conditional branching is where wizards accumulate quiet inconsistency. A step that appears based on an earlier answer needs to disappear when that answer changes, and the values collected in it need to be discarded rather than travelling along invisibly in the final payload. The progress indicator needs to follow the actual branch rather than a fixed count, and a dependent field whose options load remotely needs clearing when its parent changes, otherwise it holds a selection that is invalid for the new context and passes validation anyway.