Production access
Production Access Rejected: What ‘More Testing Required’ Means
A recovery plan for Google Play production-access applications that need more testing: audit continuity, evidence, tester relevance, findings, fixes, and release quality.
A request for more testing is not solved by repeating the same 14 days with the same vague evidence. Separate eligibility from test quality, identify the weakest part of the previous application, and run a follow-up cycle designed to close that gap.
First, distinguish a production-access decision from an app rejection
For affected new personal accounts, Google requires a closed test before production access becomes available. Meeting the minimum tester count and continuous duration lets you apply; it does not guarantee approval. Google says the application includes questions about the app, closed test, and production readiness.
A “more testing required” outcome therefore calls for a stronger test and explanation. It is different from a policy rejection tied to a specific release. Read the exact notice in Play Console and any email from Google before changing your build or track.
Audit the previous test across five areas
| Area | Questions to ask | Evidence to improve |
|---|---|---|
| Continuity | Did enough testers remain opted in continuously? Did anyone use the wrong account? | Dated roster, access checks, opt-in monitoring |
| Relevance | Could you explain who testers were and why they matched intended users? | Recruitment source, audience rationale, consent |
| Coverage | Did people test real journeys on representative devices and conditions? | Scenario assignments, device matrix, build numbers |
| Learning | What useful feedback or defects did the test reveal? | Feedback themes, reproducible findings, severity |
| Response | What changed, what was retested, and what risk remains? | Decision log, fixed build, retest result |
A test can meet the calendar threshold yet produce thin evidence. “Twelve people installed it and it worked” does not explain whether testers were relevant, which journeys they exercised, what they reported, or how the product improved.
Run a follow-up cycle that answers the gaps
- Preserve the notice. Save the wording and application date privately.
- Choose the release candidate. Resolve known blockers before inviting the group.
- Recruit for relevance and coverage. Keep a buffer above the minimum.
- Assign scenarios. Give every tester a primary journey and one edge condition.
- Ask focused questions. Request expected-versus-actual outcomes, not generic ratings.
- Triage and retest. Connect each material change to a finding and verification result.
- Keep a decision log. Record deliberate non-changes and known risk honestly.
Reapply from evidence, not optimism
Wait until Play Console shows that you can apply. Draft each answer from the current form, then cross-check every factual statement against your roster, findings, build history, and retest notes. Do not expose tester personal information unnecessarily and do not copy a generic “perfect answer” from another app.
Use the free readiness checkerto reveal missing evidence before submitting again. Production access and policy compliance are separate: recheck the release, store listing, Data safety information, privacy policy, permissions, and account-deletion behaviour as applicable.