THE DEVELOPER’S FIELD GUIDE
How to prepare your Google Play closed test
A working build is the starting point. Give your testers a clear route into the app, a few meaningful tasks, and a simple way to tell you what needs fixing.
Who needs 12 testers for 14 days?
Google requires personal developer accounts created after November 13, 2023 to run a closed test with at least 12 testers continuously opted in for the preceding 14 days before applying for production access. An opt-out interrupts that tester’s continuous period. Meeting the minimum lets you apply; it does not guarantee approval. Check Google’s account-specific testing requirements and your Play Console dashboard.
Set up the closed test in Play Console
- Complete your app setup and open Test and release → Testing → Closed testing. Create or select a track.
- Add your tester email list or Google Group in the track’s tester settings.
- Create a release, upload your app bundle, resolve the required checks, and roll out the release to that track.
- Share the opt-in link with eligible testers. They need to join with the Google account you authorized before installing the test build.
Use Google’s test-track setup instructions for the current console workflow. If access fails, check the authorized account, release availability, and whether the tester is enrolled in an internal test; Google explains how to switch tracks.
Recruit people who can actually try your app
Start with the kind of person your app is designed for. A budgeting app needs someone willing to enter a realistic sample budget; a running app needs someone able to try its recording flow. Ask about availability and device compatibility before sending a link.
Our suggestion: write a short invitation with the app’s purpose, the expected commitment, and the feedback channel. For managed coordination, review TestCircle’s Google Play testing package. Developers retain control of Play Console and confirm enrollment themselves.
Write tasks with an observable outcome
A task should tell someone what to achieve without explaining every tap. That gives you a chance to discover where the interface is unclear. Here is a starter brief for a fictional notes app; adapt it to your actual features.
- Create a new account and find where to add your first note.
- Save a note, close the app, and check whether it is still there when you return.
- Edit the note, then delete it. Tell us whether the result was clear.
- Increase your phone’s text size and check whether you can still finish the same task.
Add a place for “I could not finish” and an explanation. A failed task can be more useful than an unqualified “looks good.” Use sample data so testers do not need to enter private information to exercise a feature.
Keep a small, useful feedback log
For each finding, record the task, app version, device, reproduction steps, expected result, actual result, and follow-up status. Group duplicate reports, then give the tester a specific fix to check.
Example finding: “The Save button disappears when the keyboard opens on a small screen.”
Useful follow-up: “In build 8, try creating a note with the keyboard open. Can you reach Save without dismissing it?”
See our illustrative testing report for one way to organize findings. It is a fictional example, not a completed customer test.
Prepare for the production-access application
Google asks about tester engagement, feedback, and changes made before launch. Keep accurate notes as you test, and use your actual results when applying. Google can ask for more testing. Read the official production-access guidance.
Our suggested closing check: revisit the main user journey on the latest build, identify unresolved problems, and decide which ones should block your release. Do not treat a calendar deadline as evidence that a broken feature is ready.