What is a quiz scoring boundary test?
A quiz scoring boundary test is a synthetic response designed to land on or immediately beside a cutoff that changes a result, qualification band, or next action. It verifies the implementation of an approved rule; it does not decide whether the underlying policy is sound.
The policy should already define the score formula, reachable range, inclusive or exclusive operators, tie rule, missing-answer behavior, and eligible action for each band. Keep supplied answers, calculated scores, assigned bands, and operational decisions separate so each output can be checked independently.
Related: Choose the threshold before testing it · Review the underlying score model
Build the evidence record first
Record the rule version, reachable score range, cutoff operator, expected result, expected segment, expected owner or queue, expected event, and test identity before a test runs. That prevents the observed output from silently becoming the expectation.
W3C guidance recommends identifying validation errors in understandable text, clearly marking required input, and allowing people to review or correct critical input. Include invalid-input behavior and recovery in the evidence record rather than testing only successful submissions.
Sources: W3C, Validating input
Boundary test matrix
Run the smallest synthetic response that reaches each state. Use identifiers that cannot enter production sales or email queues.
| Case | Synthetic input | Expected output | Failure caught |
|---|---|---|---|
| Below cutoff | threshold - 1 | Lower band and lower-band action | Off-by-one comparison |
| At cutoff | threshold | Declared inclusive or exclusive action | Ambiguous operator |
| Above cutoff | threshold + 1 | Upper band and upper-band action | Wrong comparison |
| Tie | Equal competing outcomes | Declared deterministic tie rule | Unstable ordering |
| Missing optional | Valid reduced response | No invented score value | Silent default |
| Edited answer | Recomputed score | Latest band; stale action removed | Stale state |
| Resumed session | Same saved answers | Same band; no duplicate action | Lost or duplicated state |
| Rule change | Same answers; new rule version | Version-specific band and action | Retroactive drift |
Run the reproducible test method
NIST describes experimental-design selection as a sequence that starts with objectives and variables before choosing a design. Apply that discipline here by declaring the objective, input factors, expected responses, and comparison method before execution. This is deterministic software verification, not a statistical benchmark.
Run clean, resumed, edited, and retried versions separately. A passing result requires agreement across every user-visible, stored, analytical, and downstream surface.
- Freeze the scoring and routing rules under a version identifier.
- Enumerate every cutoff that changes a visible result or downstream action.
- Construct the smallest below, at, and above input for each cutoff.
- Write every expected output before running the quiz.
- Repeat from a clean session and as a resumed or edited session.
- Compare the result, score, band, event, owner, and action.
- Block release for any mismatch, duplicate, stale action, or unexplained default.
Worked example: two qualification cutoffs
Suppose a quiz can score 0–20 and the approved bands are nurture at 0–9, manual review at 10–14, and sales-ready at 15–20. Test 9, 10, 14, and 15 explicitly. Then create a tied outcome at 15, remove an optional answer, edit a 14-point response to 15, and resume a saved 10-point session.
The release passes only when each surface matches the prewritten expectation and no action from the earlier state survives an edit. These values are synthetic examples, not recommended universal cutoffs or performance benchmarks.
Measure decisions without double counting
Emit a stable completion identifier, rule version, calculated score, band, and route decision. Google Analytics documents generate_lead, qualify_lead, and disqualify_lead as recommended lead-generation events, but analytics should observe the decision rather than become its source of truth.
Count unique completions and unique routed actions separately so retries do not inflate conversion reporting. Preserve the rule version with the event so later threshold changes do not rewrite earlier results.
Related: Define the broader quiz measurement model
Sources: Google Analytics, Recommended events
Test accessibility and recovery
Do not communicate a qualification band by color alone. Associate error text with the affected field, retain valid answers after an error, move focus deliberately, and expose a clear status when recalculation or submission succeeds.
Run every boundary path with keyboard-only navigation and enlarged text and zoom settings. Verify that validation messages explain the problem and correction without discarding unrelated answers.
Sources: W3C, Validating input
Release checklist
Do not release scoring changes until every action boundary is explicit, reproducible, and auditable.
- Every action-changing cutoff has below, exact, and above cases.
- Inclusive and exclusive operators are explicit.
- Tie, missing-answer, edit, resume, retry, and rule-version behavior is deterministic.
- Visible, stored, analytical, and downstream outputs agree.
- Invalid input is explained and recoverable.
- Synthetic identities cannot enter production queues or sequences.
Evidence
How to reproduce the method
Reproduce the matrix with synthetic answer sets at every declared cutoff. Write the expected visible result, stored score, band, rule version, analytics event, owner, and downstream action before execution; then repeat clean, resumed, edited, tied, missing-answer, retry, and rule-change cases.
Limitation
Where this conclusion stops
This matrix can expose implementation defects at declared thresholds. It cannot prove predictive validity, eliminate self-report bias, establish fairness, choose a commercially optimal cutoff, or replace monitored production outcomes and human review. No product performance is claimed.
Sources and verification
What this guide relies on
- The Lead Quiz Review editorial methodology
- NIST, Choosing an experimental design
- W3C, Validating input
- Google Analytics, Recommended events
Sources and method checked September 30, 2026. External standards are linked to their primary publishers. Request a factual correction.