The Survey ReviewSee our picks

Evidence asset

Survey pre-launch QA checklist: 40 checks for logic, mobile and data quality

A reusable 40-check release gate covering routing, accessibility, mobile behavior, privacy, exports and recovery before a survey goes live.

Published
24 August 2026
Reading time
14 min
Author and reviewer
The Survey Review

Do not launch a survey because the preview looks right. Launch only after every route, control, data field and operational handoff has passed a repeatable release gate. This checklist provides 40 checks that can be rerun after any material edit.

What is survey pre-launch QA?

Survey pre-launch quality assurance is a documented test of questionnaire content, routing, interaction, data output and operating controls before respondents receive the survey. It is broader than proofreading.

The 40-check release gate

Purpose and content

  1. Every question maps to a decision
  2. Unnecessary questions are removed
  3. Wording passes the 25-point quality test
  4. Response options are complete and non-overlapping
  5. Sensitive items are justified

Logic and routing

  1. Every branch has a named entry condition
  2. Every route reaches a valid end
  3. No question is impossible to reach
  4. Back navigation does not corrupt routing
  5. Hidden fields and piping have safe fallbacks
  6. Quota and disqualification exits are distinct
  7. Test cases cover every terminal path

Accessibility and mobile

  1. Controls have visible programmatic labels
  2. Keyboard order matches visual order
  3. Focus remains visible
  4. Errors are described in text and not by color alone
  5. Targets meet size or spacing requirements
  6. Zoom does not cause horizontal overflow
  7. A narrow-screen completion test passes

Privacy and trust

  1. The introduction names purpose and data use
  2. Identity promise matches actual collection
  3. Tracking parameters are reviewed
  4. Retention and deletion paths are documented
  5. Access is limited to named roles
  6. Test data contains no real personal information

Data and operations

  1. Required fields are truly required
  2. All codes have stable export labels
  3. Other-text responses export correctly
  4. Dates and numbers use documented formats
  5. Partial response handling is defined
  6. Duplicate response behavior is defined
  7. Alerts contain the right fields
  8. Integrations fail safely
  9. A CSV export opens cleanly
  10. A data dictionary exists

Release and recovery

  1. Owner and approval are recorded
  2. Live URL and embed are correct
  3. Close date and timezone are correct
  4. Rollback or pause procedure is known
  5. A post-launch response check is scheduled

A reproducible test run

  1. Create one synthetic respondent profile for each terminal branch.
  2. Complete every profile with keyboard only, then repeat the longest route on a narrow screen.
  3. Deliberately trigger required-field and formatting errors.
  4. Submit distinct marker values such as QA_ROUTE_A so exported rows can be traced.
  5. Export the data, compare every field with the questionnaire and confirm alerts or integrations.
  6. Delete the synthetic records, record the result and require a second reviewer for failed checks.

Worked example: a hidden export failure

A customer survey routes detractors to an open text follow-up. The screen flow works, but the follow-up column is missing from the scheduled CSV export. A visual preview would pass; the synthetic marker and export comparison expose the defect before launch.

Limitations

This checklist tests implementation, not whether the sample represents a population or whether a measure is statistically valid. Authentication, data residency and contractual controls also require evidence outside the respondent interface.

Sources and limitations

Verification date: 24 August 2026. This is operational survey-design guidance, not legal advice. Requirements can differ by jurisdiction, audience and research purpose. Send corrections with a primary source through our corrections process.