Quick answer
"More testing required" is the outcome of a production-access application, not a policy strike against your app. Google reviews the closed test you ran and the answers you gave, then emails the account owner. If the review is not satisfied, you are asked to keep testing. Start by confirming which decision you received, then what your own records establish about eligibility, app use, feedback and readiness.
If your app or release was rejected for a named issue instead, follow that issue's correction and resubmission instructions. More testers do not clear a policy decision.
This post is the diagnosis: which decision you received, what each piece of evidence can and cannot establish, and what to correct before you apply again. It draws on the closed tests PrimeTestLab runs every week, and on Google's guidance, linked at the point of use. Current as of September 11, 2026.
How to read this post
- Google requirement A mandatory eligibility, submission, or policy condition.
- Google guidance Google recommends it, or the application asks about it. No threshold is published.
- Our suggestion A working practice from the tests we run, not a rule you are measured against.
On this page
First, identify what Google rejected
Three different decisions all get called "closed testing rejected", and they need different work. Match the wording you were actually given.
Which message did you get?
| What you received | What it means | What to do next |
|---|---|---|
| Dashboard says testing eligibility is incomplete | The dashboard identifies an unmet testing condition. Check the specific condition shown before deciding what needs to continue. | Finish the closed test: at least 12 testers, each opted in for the last 14 continuous days. |
| "More testing required" after applying | Your application was reviewed and not approved yet. Google asks you to continue testing; the decision and the account-owner email carry the concerns that were identified. | Work through the five areas below, correct what you find, then reapply from your account. |
| App or release rejected for a stated issue | A decision about the app itself, naming a policy or quality problem. Not a judgment on your tester count. | Follow the correction and resubmission instructions for the issue named. More testers will not resolve it. |
A locked Production track on its own does not tell you whether testing eligibility, an application decision, or another account step is the thing still outstanding. Route yourself with the specific message you were given, not with the lock.
Sources: app testing requirements and production access, and publishing and review status.
Confirm the requirement applies to you
Google requirementThe requirement applies to personal developer accounts created after November 13, 2023. Google states these accounts must meet specific testing requirements before an app is eligible to be published. If yours is affected, three things happen in order:
- 1Run a closed test, not only an internal test.
- 2Keep at least 12 testers opted in for 14 continuous days.
- 3Apply for production access and answer the questions about the test, the app, and readiness.
Eligibility is not approval
Meeting the requirement makes you eligible to apply. The application is reviewed on its own, so a clean 14 days is the start of the process, not the end of it. Full detail: how the tester requirement works.
Diagnose the problem in five minutes
Open Play Console next to this list and answer each question honestly. Anything you cannot answer is where to start reading.
What this does and does not do
This reads nothing from your Play Console account and cannot confirm your tester count or opt-in dates. It only puts what you already know into the order the review asks about it.
Next step
Use the reapplication guide for the steps after a more-testing decision. If your diagnosis shows you need more human testing, compare testing support. If Google named an app or policy problem, fix that first; another group of testers will not solve it.
Five areas to check after a production-access denial
Areas to investigate, in the order you can investigate them. They are not ranked by how often they cause a denial, because no published data establishes that ordering.
Tester eligibility or continuity is incomplete
Google asks for a minimum of 12 testers opted in for at least the last 14 days continuously. Continuity is per tester: someone who opts in, tests for under 14 days and opts out does not count for that broken period. A returning tester can qualify again after a new uninterrupted 14-day opt-in period.
What to check
- Confirm you are on the closed track. A tester still enrolled in an internal test has to leave it before your closed test reaches them.
- Count people who have opted in, not addresses you added to a list. Adding an address does nothing until that person accepts the link.
- Ask testers to stay opted in through the point when you apply for production access, not only for the 14 days before it.
Illustrative: continuity is per tester
If 15 testers joined together and one leaves, the remaining 14 may still qualify, because each kept their own unbroken period. A replacement who joins later starts their own clock and does not inherit the elapsed time of the tester who left.
Keep a small buffer above the minimum. Exactly 12 testers qualifies, so a buffer is our practice for absorbing an opt-out without dropping below the line, not something Google asks for.
Sources: app testing requirements for new personal developer accounts, and set up an open, closed, or internal test for tester lists and opt-in links. Walkthroughs: check tester invitations and opt-in and internal versus closed testing.
Testers did not meaningfully use the app
The application asks whether testers used the features, and whether usage resembled what you expect in production. Google also says you can be asked to continue testing when testers were not engaged. The reviewed guidance does not specify a numerical engagement threshold, so the work is describing real use.
Three numbers that are not the same number
| Metric | What it counts | What this metric establishes |
|---|---|---|
| Opted-in testers | People who accepted the opt-in link for your closed track and have stayed opted in. | The eligibility number, and the only one of the three tied to the 12 and 14 rule. |
| Installed audience | Users with your app installed on at least one device they used in the previous 30 days. | The app reached a device in use. It does not establish that anyone opened it. |
| Daily active users | People who opened the app on a given day. | Opens happened. It still does not say which features were used, or what testers made of them. |
Source: view app statistics. Google does hold usage data, so engagement is not invisible to it. What is undocumented is which signals the review weighs, and at what level.
What to check
- Give testers a short brief naming the flows you want exercised, and one channel to reply on.
- Ask for specific observations, not a verdict: what they tried, on which device, what happened.
- Ask testers to revisit an important fix once it ships, so the record shows a change being checked.
Ask testers to complete the tasks that matter for your app, report what they see in their own words, and revisit important fixes after they land. A fixed instruction such as "open the app once a day" is an optional testing routine, not a Google rule.
Feedback and application answers lack specific evidence
The application asks you to summarize the feedback you received and the changes you made. Google recommends recording feedback themes as you go, and that log is the difference between a specific answer and a general one.
Illustrative test record (structure, not content to copy)
| Build, workflow, environment | Finding | Action or verification |
|---|---|---|
| Build 8; password reset; Android 14 | Retry message was unclear | Clarified in Build 9; tester checked it again |
| Build 9; saved settings; Android 13 | Settings persisted after reopening | Recorded as passed; no change needed |
This is a suggested record format, not a required Google template or attachment. Use the columns for structure, never the rows as facts to paste in. Recording a successful check matters as much as recording a problem: it is what lets you answer the readiness question without inventing an issue.
What to check
- Use the testing feedback section in Play Console, plus any channel you gave testers. Public store ratings are not part of this.
- Group the feedback into themes first, so one loud report does not become the whole summary.
- Preserve the specific observation, whether you quote the tester or summarize it accurately.
- Confirm the features you describe in the application were present in the tested build and were actually exercised. Note anything tested separately or left outside this test.
Sources: set up an open, closed, or internal test and production access guidance. A reusable log template is in our recovery post, and prepare accurate production-access answers works through the form itself.
Findings were not addressed or readiness is unclear
The application asks what you changed based on what you learned, and Google recommends acting on feedback during the test. No release quota appears in the guidance reviewed, so what matters is whether the answer reflects what the test established.
What to say when nothing needed changing
If testing surfaced nothing that had to be fixed, describe the workflows checked, the devices they ran on, and the results, then explain the readiness decision from that record. Inventing an issue, or shipping a cosmetic release so you have a change to report, makes the answer weaker.
What to check
- Address the genuine findings first, and say which build carried each fix.
- Connect each change to the feedback that prompted it, so the answer reads as cause and effect.
- If an important issue is still open, resolve it before you present the app as ready.
Where this answer goes wrong
The weak answer says testing went well. The strong answer names what was checked, what was found, what was done, and how it was verified. The specific answer is easier to assess.
Access, stability, or functionality problems remain
Google does not allow apps that crash, freeze or otherwise do not function normally. A review also has to be able to reach the app: where anything sits behind a sign-in, working credentials and instructions go with the release.
What to check
- Supply working review sign-in details, and any steps needed to reach restricted features, for the build you submitted.
- Confirm testers can install and open that build. Anyone still in an internal test has to leave it first.
- Run a pre-launch report, then check crash and ANR signals for the flows your testers used, and fix what is reproducible.
What a clean report does not prove
Pre-launch reports run automatically when capacity permits. Credentials or a custom configuration may be needed to reach protected content and exercise the relevant flows. A clean automated result is also not a manual test. Android vitals draws on opted-in diagnostic data from a subset of devices and operating-system versions, so an unavailable view can reflect too few data points inside the filters you selected. Its published bad-behavior thresholds concern technical quality, not a production-access pass mark.
Sources: functionality, content, and user experience, prepare your app for review, use a pre-launch report to identify issues, and monitor technical quality with Android vitals.
What each piece of evidence can and cannot establish
Knowing which question each artifact answers is what separates a tester problem from an evidence problem or an app problem.
AnswersWhether you were eligible to apply: at least 12 testers, each opted in for the last 14 continuous days.
Does not answerWhether any of them used the app, or whether your answers were specific enough.
AnswersHow many users opened the app on each day shown.
Does not answerHow many times each person opened it, which features they used, or what they thought of the experience.
AnswersThat the selected view does not have enough data to identify issues under the current filters.
Does not answerThat the app did not crash. Vitals uses opted-in data from a subset of devices and versions, so an empty view can mean too few data points were collected, not that nothing went wrong.
AnswersThat another developer reported that wording. Worth reading for the shape of the decision.
Does not answerWhat your own account was told. Reproduced community messages are anecdotal and cannot set your timing.
AnswersA specific observation you can act on and describe, in the tester's own words.
Does not answerWhether it is widespread. One report is a lead; the pattern across testers is the finding.
What to check before reapplying
Google guidance- 1Read both the Play Console decision and the account-owner email, and follow the instructions provided for your app.
- 2Complete any additional testing period your app was actually given, and keep the closed track running while you do.
- 3Keep resolving the concerns the decision named, then reapply using the instructions shown in your account.
Two conclusions not to draw
A missing duration is not permission to reapply immediately. And an instruction to continue testing is not proof that every tester's elapsed time was erased: the public guidance reviewed does not specify a universal reset rule, so treat both as unknown until your own account says otherwise.
Google describes the review that follows as usually seven days or less, while saying it can occasionally take longer. That is the review, not the testing before it. Step by step: how to reapply after a more testing required decision.
Source: production access next steps.
How to keep testers engaged
Google guidanceGoogle says many developers recruit through friends, family, colleagues, communities and social channels, and recommends testers who represent your target users, diverse enough to surface device-specific issues.
Recruitment can fail when participation and feedback are not managed: a 14-day commitment with no structure around it competes with everything else in a volunteer's week. Three participation and feedback problems to watch for:
Where a self-managed group loses the window
Source: app testing requirements, which is where Google discusses recruiting testers. Options are compared in legitimate ways to find 12 testers.
Self-managed or managed testing
Both routes clear the same requirement. The difference is who watches the count and chases the feedback for 14 days.
| What the application depends on | Self-managed group | Managed testing |
|---|---|---|
| Holding 12 opted-in testers for 14 continuous days | Yours to monitor. An opt-out can delay eligibility if it leaves too few qualifying testers. | Monitored for you, with the roster held above the minimum. |
| Real devices | Whatever your volunteers happen to own. | Real Android devices spanning Android 7 to 17. |
| Getting started | As long as recruiting takes. | Testers typically begin within 4-6 hours. |
| Feedback you can summarize | Depends entirely on how you collect it. | Collected through one channel and reported back to you. |
| Cost | Free, plus your own time for 14 days. | From $19.99 for 12 testers. |
Neither route changes how the application is reviewed. Managed testing removes the participation risk; it does not answer the feedback and readiness questions for you, and no one can promise an approval.
Testing support
Our suggestionIf your diagnosis points at participation, PrimeTestLab runs the closed test for you: opted-in testers on real devices for the full 14 days, kept above the minimum, feedback in one place. If the gap is a broken sign-in or a named policy issue, more testers will not move it.
Starter
12 Real Testers
$19.99
Enterprise
25 Real Testers
$27.99
Professional
20 Real Testers
$29.99
That completion figure is our own operational record, not a Google approval rate: the managed test held the required tester count and an unbroken opt-in period through its end date.
Questions and answers
Why does Google Play say "More testing required"?
Your production-access application was reviewed and has not been approved yet, so Google is asking you to keep testing. Its examples include not having 12 opted-in testers, and testers not being engaged during the closed test. Read both the Play Console decision and the email sent to the account owner for the concerns identified.
Do I need 12 testers opted in for 14 continuous days?
For a personal developer account created after November 13, 2023, yes. Google requires a closed test with a minimum of 12 testers opted in for at least the last 14 days continuously. Exactly 12 qualifies, and invited addresses do not count until each person opts in.
One tester opted out during the 14 days. Do I have to start over?
Not necessarily. Continuity is measured per tester, so anyone who kept their own unbroken period still counts. The broken period itself does not count, but a returning tester can qualify again after a new uninterrupted 14-day opt-in period. What does not happen is inheritance: a replacement who joins later starts their own period rather than taking over the elapsed time of the tester who left.
What should I answer if testing did not reveal anything to fix?
Describe the workflows you checked, the devices they ran on, and the results, then explain your readiness decision from that record. No release quota appears in the guidance reviewed, and nothing in it says you must ship an update during the test. Inventing an issue only makes the answer weaker.
Can I reapply immediately after a denial?
Apply again once the root cause is fixed, and let your own readiness set the timing. Some messages name an additional period of closed testing; others only say to continue testing and give no duration. A missing duration is not permission to reapply immediately, and the public guidance reviewed does not specify a universal reset rule.
How long does Google take to review a production-access application?
Google describes the review as usually seven days or less, and says it can occasionally take longer. That covers the review only. The closed test before it is a separate 14 continuous days, and any additional testing your decision asks for is separate again.
Your next step
Go back to the five-minute check and take the first question you could not answer. Fix that one thing, write down what the test actually established, and reapply using the instructions in your own account. If the gap is participation rather than evidence, arrange testers before the next attempt so the window does not break again mid-test.
Bottom line
"More testing required" is a decision about the test you ran, the answers you gave, and whether the app is ready. The floor is fixed and public: at least 12 testers opted in for 14 continuous days, for a personal developer account created after November 13, 2023. Above it, your answers should explain accurately what the test established. Clear wording cannot substitute for meaningful testing or a functioning app.
Official Google documentation