On this page (9 sections)
Don’t just repeat the same 14 days
The closed-testing requirement has a minimum duration and a minimum tester count, but Google evaluates the quality of the test when you apply for production access. If the first test was thin — testers who joined and disappeared, features nobody used, no feedback — repeating it produces the same evidence and the same answer. Change what the test demonstrates, not just the calendar.
What Google is looking at
The application asks how you recruited testers, how they engaged, what feedback you got and what you changed. Those questions describe the evidence a good test produces. Design the next test to produce it.
Tester eligibility and opt-in
- Testers must join through your testing link or the Play Store listing and stay opted in for the whole period. Someone who opts out on day nine resets your count for the requirement.
- Testers need to be real people with their own Google accounts and devices. Shared devices, emulators or accounts you control do not demonstrate anything and can be treated as abuse.
- Pick testers who resemble your real users. Twelve developers testing a fitness app produce different evidence than twelve people who use fitness apps.
Meaningful engagement
Opt-ins are counted automatically; engagement is what convinces a reviewer. A useful test looks like this:
- Each tester installs the app and opens it on several days across the period
- Testers complete the main task the app exists for, not just onboarding
- Account creation, permissions prompts, uploads, purchases and notifications are exercised where they exist
- You can see the usage in your analytics, backend logs or crash reporting
Twelve opt-ins are not automatically twelve meaningful testers. If only three of them used the app, plan for more recruits or a longer window so that the required number actually tests.
Feedback, issues found and fixed
Ask testers for feedback in a way you can quote later: a short survey, a messaging group, or in-app feedback. Record bugs and confusing screens as they come in. Fix what you can during the test and push updated builds to the closed track — a changelog with real entries is strong evidence of a real testing process.
Do not invent bugs or feedback
Fabricated feedback, purchased engagement and bot traffic violate Google Play policy and can escalate a testing problem into an account enforcement problem. Report what happened. If nothing happened, that is the problem to fix.
No invented rules
You will find advice online quoting daily-minute quotas, exact session counts or “secret” engagement thresholds. Google has not published such numbers at the time of verification, and we will not invent them. The safe target is straightforward: real people, using the real features, over the required period, producing feedback you acted on.
Prepare a testing evidence summary
Before you reapply, write a short internal summary. It makes the application answers specific and it shows you whether the test was actually adequate.
| Item | What to record |
|---|---|
| Testers | How recruited, how many opted in, how many stayed for the full period |
| Engagement | Days active, features used, sessions (from your analytics or logs) |
| Feedback | Quotes or summaries; where it was collected |
| Issues found | Bugs, crashes, confusing flows — with the build in which each was fixed |
| Changes shipped | Versions pushed to the closed track and why |
| Readiness | Privacy policy, Data safety, listing and content rating all match the current app |
Reapplication checklist
- Required tester count opted in and retained for the required continuous period
- Core flows exercised by most testers; you can point to the evidence
- Feedback collected and at least some of it acted on, with a changelog
- Known crashes fixed; the build you will promote is the build that was tested
- Application answers are specific and consistent with what Google can observe
If you already had good testing, diagnose first
If your first test was genuinely solid and you still received “more testing required”, another identical test is unlikely to change the result. The cause may be the way the application was answered, a readiness issue in the app, or a policy concern surfaced during review. Send us the notice, your answers and your evidence summary; we will tell you whether a new test is warranted or whether something else needs to change first.
How we help with a “more testing required” result
We read your closed-test evidence the way the requirement is written: opted-in tester count and continuity, which features the testers actually reached, the feedback you received and what you shipped in response, and whether your application answers describe that test truthfully. Where the gap is technical — onboarding that testers abandon, a crash on a common device, a feature that cannot be reached without a backend fix — we can change the app before the next test. We do not recruit or simulate testers, we do not write “feedback” for you, and we cannot influence Google’s decision; what we can do is make the next 14 days count.