The Contractor‑Ready QA Plan: Device Matrix, Acceptance Tests & Smoke Flows That Prevent Store Rejections

You can’t test every handset. Prioritize devices by global install share and your own analytics. Aim for 10–15 devices that cover: latest iOS major release + one previous, popular Android OS versions in your target markets, and a spread of screen sizes and CPU classes. This keeps coverage meaningful while staying contractor‑friendly.

Concrete selection rule: pick the top 3 iOS device families (e.g., flagship phone, mid-range phone, recent iPad if you support tablets), then choose 6–10 Android devices representing different OEMs, OS versions, and screen buckets. If you have analytics, replace the defaults with the top device models and OS versions from your traffic. If not, weight by market share (Android vs iOS) and popular models in your target countries.

Acceptance tests should be actionable, binary where possible, and tied to user flows and App Store rules. Below are 12 tests that catch the majority of technical and review issues (completeness, crashes, metadata mismatches, privacy requests, and core flows). For each test, include the exact build number, environment (prod/test), and a short reproduction script.

For each test define: test objective, preconditions (account state, network), steps, expected result, and 'blocker' condition(s) that must fail the submission if seen. Require video recording of any failing test and a short log or device screenshot attached to the ticket.

A smoke run should take 30–90 minutes on the prioritized device matrix and is the last manual gate before upload. The runbook should be a short, ordered list: sanity checks, critical flows, permissions, performance quick checks, and submission metadata verification. If any blocker is found, the contractor marks the build 'reject-to-dev' with video and logs attached.

Make the runbook prescriptive. Assign timeboxes per device, require specific artifacts (crash logs, screenshots, short Loom videos), and include precise metadata checks so reviewers don’t reject for obvious mismatches (screenshots, app name, privacy policy URL).

After the build is live, the contractor follows a short post‑release checklist to catch issues the review might have missed and to validate distribution: crash and first‑24‑hour metrics, payments reconciliation, and user reports triage. Early detection prevents urgent rollbacks and expensive hotfix cycles.

Define ownership and SLAs: who monitors crash alerts, who triages new user complaints from the store, and how long the contractor must be on-call after release. Make these explicit in the handoff so contractors know when to escalate and when to file a patch ticket.

Pack everything. A contractor‑ready packet contains: prioritized device matrix, acceptance test checklist (12 items) with binary-specific preconditions, smoke runbook, and a post-release checklist. Add links to credentials (throwaway test accounts), app store submission notes, and the exact build artifact (IPA/APK) plus the CI tag.

Include governance rules: who can mark a build 'ready', what qualifies as a 'blocker', and how to escalate. Also require contractors to attach recorded evidence for any failed acceptance test. This converts subjective QA into auditable decisions, prevents rework, and reduces rounds of review.