Quiz Branching Logic QA Checklist

What quiz branching logic means

Quiz branching logic is the set of rules that decides which question, result, or next step appears after each response. A branch is correct only when both its condition and destination match the documented decision rule.

Treat the quiz as a directed graph. Questions and results are nodes, while conditional transitions are edges. Testing must cover the routes that should exist, the routes that must not exist, and the fallback behavior when no condition matches.

1. Freeze the branching specification

Before testing, record each node, answer option, condition, destination, score effect, and result rule. Give every node a stable ID. Define operators and boundaries exactly, such as score greater than or equal to 20, instead of using a vague label such as high score.

Add an explicit default route. If no condition matches, the system should reach a safe fallback result or a clear recoverable error. A missing default can create a blank screen or silently send a participant to the wrong outcome.

W3C guidance recommends splitting multi-page forms into logical groups and communicating progress. A branched quiz should still explain the participant's current stage without pretending every path has the same length.

Related: Start with the complete quiz build process

2. Build the path inventory

Start with all expected outcomes and work backward. For each outcome, identify at least one valid input path that must reach it. Then inspect every decision node and add a test for each outgoing edge. This exposes results that exist in the builder but cannot be reached.

The table below is a specification, not a claim that a real quiz was tested. Complete the Actual and Status columns only after executing each path in the real preview or production-equivalent environment.

3. Test equivalence classes, boundaries, and ties

Do not attempt every possible answer combination when the set is enormous. Group inputs that should behave the same, then test a representative from each group plus every boundary. For a score threshold at 20, test 19, 20, and 21. For a date gate, test the moment before, at, and after the cutoff using the intended timezone.

Test ties explicitly. When two outcomes receive the same score, the specification needs a deterministic tie rule. Accidental array-order tie breaking can change the advice after an editor reorders results.

Related: Use the scoring and boundary-testing method

4. Test state changes and recovery

Run more than new sessions. Change an earlier answer after reaching a later branch. Use Back, reload, and resume where those features exist. Confirm that obsolete answers from the old path are cleared or ignored and cannot affect scoring, segmentation, or the submitted record.

Test missing input, invalid input, network interruption, duplicate submission, and a closed browser tab. W3C validation guidance says errors need accessible notification and text that helps people correct the problem. A red border alone is not a sufficient recovery instruction.

5. Check focus, progress, and announcements

After each transition, keyboard focus should move to a meaningful heading, question, or error summary. Focus must remain visible and must not be fully hidden by sticky headers or other author-created content. Progress information should remain truthful when branching changes the total number of steps.

Verify that labels and instructions stay programmatically associated with their controls. Test with a keyboard at 200 percent zoom, with reduced motion enabled, and with a screen reader on at least one representative path per outcome.

Related: Run the complete quiz accessibility checklist

6. Validate submitted data, not only the screen

For each path, compare the visible result with stored answers, computed score or outcome, consent state, contact fields, and downstream payload. A correct result screen can still send stale or contradictory values to another system.

Keep a field dictionary with each field's name, purpose, source question, allowed values, retention rule, and downstream destination. Do not collect extra data merely because a new branch makes another question technically possible.

Worked example: a three-result qualification quiz

Suppose a quiz routes participants to self-service, guided review, or a priority conversation. The priority rule is a score of at least 20 and a timeline within 30 days. The test set covers scores 19, 20, and 21 with both timeline values, plus a tie between guided review and priority.

The participant first chooses the urgent timeline, moves forward, then goes back and changes it to later. The final result must be recalculated from the later answer, and the submitted payload must not contain the obsolete urgent value. This is an illustrative test specification, not a reported product test.

Use a blocking release decision

Block publication when any valid route has no result, an invalid state can submit, a changed answer leaves stale downstream data, a required route cannot be completed by keyboard, or the visible result disagrees with the stored record.

A cosmetic issue can be recorded for follow-up only when it does not affect comprehension, completion, privacy, focus, data accuracy, or outcome selection. Store the final path table, defect log, evidence captures, and sign-off together so the release decision can be reviewed later.

• Every documented outcome has at least one passing reachable path
• Every decision edge and score boundary has a recorded test
• Default, invalid, missing-input, and interrupted states recover safely
• Back navigation and answer changes cannot leave stale state
• Visible result, stored record, and downstream payload agree
• Keyboard, focus, progress, zoom, and error guidance pass