Google Play Closed Testing: 12 Testers for 14 Days Checklist
A practical checklist for the Google Play closed-testing requirement, what LuneTest records, and the developer work that remains essential.
Who the 12-testers-for-14-days requirement applies to
Google states this requirement for personal Play Console accounts created after November 13, 2023. Account-specific requirements and Google policy can change, so confirm the current requirement in your own Play Console before planning a release.
Where the requirement applies, 12 testers need to opt in continuously for 14 days. Treat the count and the continuous period as an operating requirement, not as a promise that production access will follow automatically.
Preparation checklist
Prepare an installable Android release on the intended closed track, the package name, and the private opt-in link. Add the intended tester accounts to that same closed track and confirm that the opt-in flow reaches an installable listing. The order for that confirmation is in check the closed-test opt-in link, and the registration steps themselves are in add tester emails to your closed track.
Keep track ownership, the tester list, and release availability under the developer's control. Do not share Google passwords, two-step verification codes, recovery codes, or Play Console administrator access with a testing service.
Keep opt-in continuous
A tester account must remain opted in through the relevant continuous period. Removing a tester, changing the track, or using a link that does not match the released app can interrupt the evidence you need to review.
Check the audience and opt-in status before the period begins and whenever a track setting changes. The developer should collect genuine representative tester participation and feedback rather than treating an execution log as a substitute for it.
Release and update continuity
Keep the app available on the same closed track while testing. When you publish an update, keep the package and access path aligned so the next install or update can be observed without breaking the tester path. When a change is picked up during a managed run is covered in publishing an update during a closed test.
Record what changed in the app and why. Google’s current production-access application asks about tester engagement and feedback and about app changes, so maintain your own feedback collection and product-improvement record alongside operational facts.
Evidence to retain
Keep the closed-track configuration, opt-in status, release/version history, tester-engagement and feedback notes, and the changes you made in response. These are developer-owned records for an honest production-access application, and how to read the daily execution record explains what each observed value beside them means.
For one Android app, LuneTest provides 15 tester accounts and a 15-day managed window as an operating buffer. It records observed install, update, launch, version, outcome, and retained screenshot facts in the customer workspace.
Common blockers
Common blockers include a tester not being on the intended closed track, a stale or mismatched opt-in link, no installable release, an update published to another track, or an interrupted opt-in period.
Resolve the underlying Play Console configuration before assuming a run record explains the issue. Where an app installs but does not start, recording a launch failure separately from Crash and ANR keeps the two apart in your notes. If an app changed materially, keep the update available and document the change for your own tester-feedback and production-access work.
LuneTest service boundaries
LuneTest is a managed execution and evidence service. It does not provide public ratings or reviews, usability interviews, fabricated feedback, or guaranteed approval. It does not request Google passwords or Play Console administrator access.
Execution records do not replace genuine representative tester participation, the developer’s own feedback collection, or product improvements. Google alone decides test recognition and production access.
Next action
Confirm your current Play Console requirement, prepare the exact closed track and opt-in link, and use the related LuneTest pages below to understand the managed execution scope before you contact us.
If you are still deciding whether to run the test yourself or hand it to a managed service, choosing a Google Play closed testing service sets out the seven things worth comparing first.
Related pages
- Google Play Closed Testing: 12 Testers for 14 Days Checklist
- Choosing a Google Play Closed Testing Service: Seven Checks
- Recording a Launch Failure Separately from Crash and ANR
- Add Tester Emails to Your Closed Track
- Check the Closed-Test Opt-In Link
- Publishing an Update During a Closed Test
- How to Read the Daily Execution Record