What is partial-response QA?
Partial-response QA is a reproducible check that an unfinished quiz journey is recorded, promoted, expired, integrated, and removed exactly as the published policy says. It tests both participant-facing behavior and the operational record. A spinner, confirmation message, or dashboard row is not enough evidence on its own.
Define the states before testing. A practical minimum is in-progress, partial, resumed, completed, expired, deleted, and delivery-failed. If the product uses different labels, map them explicitly rather than assuming similarly named states behave the same.
Typeform's current documentation illustrates why state detail matters: its capture-after-each-question option saves answers as they are submitted, can mark an inactive response as partial after about seven minutes, and can send partial records to integrations. A later return after that saved partial can appear as a new response. Those are product-specific observations to verify, not universal defaults.
Related: Decide whether to save partial responses · Prevent duplicate quiz leads
Sources: Typeform Help Center, Capture partial responses after every question
Create the evidence record first
Give every synthetic run a stable test ID and capture the exact quiz version, capture mode, identity state, expected transition, stored fields, downstream action, retention rule, observed result, and release decision. Use synthetic answers and contact data; do not test with a real person's abandoned record.
| Field | Required evidence |
|---|---|
| Test ID | Stable synthetic identifier |
| Quiz version | Exact published quiz configuration |
| Capture mode | Browser-local resume, explicit partial submit, or server-side capture |
| Identity state | Anonymous, pseudonymous, or known contact |
| Expected transition | Previous state, trigger, and next state |
| Stored fields | Exact expected answer and contact keys |
| Downstream action | None, integration payload, CRM update, or recovery workflow |
| Retention rule | Start event, expiry time, and deletion destination |
| Observed result | UI, storage, payload, analytics, and logs |
| Decision | Pass, fail, blocked, or not applicable |
Run eight blocking transition tests
Each path must reconcile the visible state with the authoritative record and every accepted downstream copy. Where a product creates a new record after resume, preserve the relationship instead of pretending the two records are one.
| Path | Blocking check |
|---|---|
| Ordinary stop | Close after two answers; after the declared threshold, confirm exactly one partial record. |
| Immediate return | Resume before the partial threshold without creating a duplicate operational record. |
| Return after save | Confirm whether completion promotes the record or creates a linked new record, then make reporting follow that behavior. |
| Duplicate retry | Replay the delivery; the receiver must not create a second lead, email, or sales action. |
| Skipped or unreachable | Keep optional, branch-hidden, malformed, and lost values distinguishable. |
| Session expiry | Show an understandable status and recovery path while preserving an explainable stored state. |
| Completion promotion | Verify final answers, result, score, route, contact context, and event without counting the partial as a second completion. |
| Retention and deletion | Verify removal or anonymisation in the source, integrations, exports, queues, and covered recovery workflows. |
Related: Diagnose quiz drop-off · Audit the broader data lifecycle
Validate the participant experience
If progress is saved, state what happened in visible text and expose the status programmatically without moving focus unnecessarily. If no server-side response exists before an explicit submit point, do not imply that the organisation already received the answers.
Test keyboard-only navigation, focus after resume, back-navigation, changed answers, required-field validation, and reduced-motion behavior. A resumed journey must not trap focus or silently discard a correction made before final submission.
Sources: W3C, Validating input · W3C, Understanding status messages
Verify storage, delivery, and measurement
Compare the visible answer, authoritative stored record, and downstream payload for every test. They must agree on state, quiz version, answer IDs, identity, timestamp, permission state, and action eligibility.
Keep denominators explicit: partial rate uses eligible started journeys; resume and promotion rates use eligible saved partial journeys; delivery-failure rate uses accepted partial deliveries. Do not add a partial to generate-lead or completed-quiz totals merely because it contains an email address.
Document and justify the partial-retention period, review it regularly, and delete or anonymise data that is no longer needed. The ICO currently marks this guidance as under review following UK legislation, so recheck it when applying the checklist.
Sources: ICO, Storage limitation principle
Worked example: partial followed by completion
A synthetic visitor supplies an email at step three, answers two qualification questions, and closes the quiz. After the declared inactivity interval, the source stores partial ID P-104 and sends one integration payload. The visitor returns in the same browser, changes one answer, and completes the quiz.
The expected result is either a promoted record or a new completion linked to P-104, according to the declared product behavior. The CRM holds one person and one completed journey, keeps the earlier partial in history, sends no duplicate recovery message, and scores the final answer set. Analytics records one completion and one lead event only if the completion satisfies the lead definition.
If the integration creates two unrelated leads or the earlier answer remains authoritative after correction, the workflow fails.
Release checklist
Release only when the evidence record proves each applicable transition and every downstream copy.
- Every state has one definition, trigger, owner, and permitted action.
- Anonymous and known-contact partials have separate eligibility rules.
- Skipped, hidden, unanswered, invalid, and lost values remain distinguishable.
- Resume and completion behavior is documented for same-device and cross-device cases.
- Partial delivery and retries are idempotent, and completion cannot double-count the partial.
- Recovery messages require an eligible contact and the appropriate permission state.
- Retention starts at a declared event and covers downstream copies.
- Save, expiry, error, and completion messages are visible and accessible.
- Synthetic evidence covers the source, payload, CRM, analytics, and deletion result.
Limitations
This checklist verifies the declared state machine and data flow. It does not prove that partial capture improves conversion, that a participant expected a particular data use, that identity can be resolved perfectly across devices, or that a workflow meets every legal requirement. Vendor behavior and plan availability can change; recheck the configured product before release.
Evidence
How to reproduce the method
A versioned partial-state evidence record, eight synthetic transition paths, participant-experience checks, a source-to-payload reconciliation method, denominator definitions, a worked P-104 example, and a blocking release checklist, verified against current Typeform, W3C, and ICO primary guidance on October 14, 2026.
Limitation
Where this conclusion stops
This is a workflow QA method, not evidence that partial capture increases conversion, resolves identity across devices, establishes permission, or satisfies every legal requirement. Product behavior and plan availability must be checked in the configured account.
Sources and verification
What this guide relies on
- Typeform Help Center, Capture partial responses after every question
- W3C, Validating input
- W3C, Understanding status messages
- ICO, Storage limitation principle
- The Lead Quiz Review editorial methodology
Sources and method checked October 14, 2026. External standards are linked to their primary publishers. Request a factual correction.