Most guides tell you that the closed test lasts 14 days. Fewer tell you what to do on each of those days. This is a practical timeline you can adapt, not a promise that Google will approve anything on a schedule.
The goal is simple: by the end of the window, you have at least 12 testers who have been opted in continuously, real feedback you can describe, and a production-access application that sounds like it came from someone who was paying attention.
Before day 1: prepare the pieces
Do this before you invite anyone.
- Build: a release build that installs and opens on a normal Android device.
- Track: a closed testing track with the release rolled out.
- Testers: a list of 14–15 real people, not exactly 12.
- Opt-in link: the link from the testers section of the closed track.
- Feedback channel: a short form, a group chat, or both.
- Tracker: a simple sheet with name, email, opt-in date, device, and status.
- Store listing: enough content for testers to understand what they are testing.
If the app crashes on launch, fix that first. A closed test is not a debugging queue for a build that was never run.
Day 1: get the first opt-ins
Send the opt-in link with clear instructions:
- Open the link on the Android device.
- Sign in with the Google account you added.
- Accept the invitation.
- Install the app from Google Play.
- Open it once and tell me it worked.
Do not count email addresses. Count opt-ins and installs. Aim for 12 or more on day 1, with a few extra in progress.
At the end of the day, check the Console tester count and your tracker. If someone is missing, ask them which Google account they used.
Days 2–3: stabilise the group
This is the unglamorous part. Confirm that the people you added are actually in.
- Replace anyone who cannot install.
- Check country and device compatibility if someone cannot find the app.
- Make sure testers installed from the testing page, not the public listing.
- Send a short "what to test" message.
A useful first task: ask testers to complete onboarding and the main flow, then report anything confusing or broken.
Days 4–7: collect real feedback
Now the test should feel like a test, not a waiting room.
Ask testers to try:
- the core journey from start to finish;
- one secondary flow;
- a settings or profile screen;
- a failure case, such as bad input or no network.
Keep the ask small. A five-question form is better than a 30-question survey nobody finishes.
If a tester finds a blocking bug, fix it and release a new build. A normal update does not reset the 14-day clock by itself. Tell testers what changed and ask them to update.
Days 8–10: widen the coverage
By now you should have a stable group and some feedback. Use the middle of the window to look beyond the happy path.
- Test on a low-end device if you can.
- Try a different Android version.
- Check the app after a reboot.
- Test with a slow or offline connection.
- Ask a tester to use the app for a few minutes without guidance.
This is also a good time to review your store listing and declarations. A policy or content issue discovered now is easier to fix than one discovered after you apply.
Days 11–13: prepare the application
Do not wait until day 14 to think about the production-access questions.
Write short notes on:
- what you tested;
- who your testers were and how you found them;
- what feedback you received;
- what you changed as a result;
- what remains untested or limited.
Check the Console:
- Is the tester count still at least 12?
- Has everyone stayed opted in?
- Is the closed-testing checklist complete?
- Are there any policy or account warnings?
If the count dropped, replace testers early enough to matter, or plan to extend the window. A replacement on day 12 will not have 14 days by day 14.
Day 14: apply
When the Console shows the requirement as satisfied, open Production → Apply for access and answer the questions.
Be specific. "We tested onboarding, the main dashboard, and the payment flow with 14 testers over 14 days" is better than "we tested the app." Mention the changes you made and the limitations you know about.
Then submit once. Do not create duplicate applications or a second app to speed things up.
After day 14: wait without breaking things
Google reviews the application. The response can take time.
While you wait:
- keep the testers opted in until you have a decision;
- do not remove the closed track;
- do not publish a production release before you are approved;
- do not submit the same application repeatedly.
If you are rejected, read production access rejected before changing anything. The rejection usually points at a specific gap, not a verdict on the app.
A simple tracker
| Day | What to check | Done |
|---|---|---|
| 1 | 12+ opt-ins and installs | |
| 3 | No access or country issues | |
| 7 | First feedback and fixes | |
| 10 | Wider device and network testing | |
| 13 | Production answers drafted | |
| 14 | Console checklist complete, apply |
The short version
- Prepare before day 1; start with 14–15 testers.
- Count opt-ins, not invitations.
- Collect feedback in the first week and fix what matters.
- Check the group and the Console before the window ends.
- Apply once, with specific answers.
- Keep the test alive while you wait.
Next: how to apply for production access, or how to keep testers opted in.
Our team’s note
If this answered the question but your situation still feels messy, send us the screenshot or the rejection email. Some things are easier to solve in a two-minute conversation than another article.