PlayStore12TesterA release test plan connects your important user journeys to a specific build, representative devices and recorded results. Use the checklist as a starting point, then adapt it to the app and the risk of the change.
Define the release candidate and scope
Choose the exact build you intend to ship and record what changed. List the journeys that matter most, the supported Android versions and form factors, and any integrations affected by the change. Agree which areas are excluded.
Choose a representative test matrix
Select devices and Android versions based on your supported audience, available usage data and the change you are making. Include relevant real devices alongside emulators when possible. A passing result on one configuration does not establish coverage of every device.
Run a short smoke test first
Confirm installation, launch and one complete core journey before spending time on the full plan. If a blocking issue prevents meaningful testing, report it against the exact build and repeat the smoke test after the fix.
Test transitions and failure paths
Check fresh install and update behavior, permission choices, invalid input and interrupted network access. Exercise backgrounding and returning to the app. For app-specific purchases or account flows, use appropriate test environments and dedicated accounts.
Check screen and accessibility variations
Inspect the smallest supported window, large text, supported orientations and relevant languages. Include a manual TalkBack journey when evaluating accessibility. Automated checks and manual use reveal different issues; neither alone establishes complete accessibility.
Record results before making a release decision
Mark a check passed only after observing its expected outcome. Record failed checks with report references, leave untested checks as not checked, and explain why an item is not applicable. Review fixes and remaining risks with the person responsible for shipping.
Example: a changed sign-in flow
Illustrative planning example: a sign-in change affects fresh login, invalid credentials, expired sessions, offline retry and returning from the background. Add the supported language and large-text variants most relevant to that screen. Record each result against the candidate build.
Keep QA and Google Play eligibility separate
This checklist helps organize quality testing. It is not an official Google certification, a security audit or proof that a Google Play tester-participation requirement has been met. Google Play production eligibility is a separate process.
Frequently asked questions
Does completing the checklist mean the app is ready to ship?
No. It summarizes only the checks you performed. The release decision also depends on unresolved issues, excluded areas and the needs of your users.
How many devices should I test?
There is no universal count that proves coverage. Choose representative configurations for your supported audience and document the limits of your test matrix.
Can I use the checklist without JavaScript?
Yes. The full checklist is in the page HTML and can be printed. Interactive statuses and Markdown export require JavaScript.
Android Release Test Checklist
Record 18 Android release checks, results and notes. Export your checklist as Markdown or print it. A practical tool, not a certification.
GUIDEHow to Write an Android Bug Report
Write a reproducible Android bug report with a known build, clear steps, expected and actual results, useful evidence and a retest record.