Why Does Google Play Say More Testing Is Required?

Even after completing a closed test and applying for production access, Google Play may tell you that more testing is required.

This article separates what Google publishes from what it does not: the reasons Google’s documentation names, what the production-access application actually asks, the thresholds Google leaves unspecified, and what to check and improve before you reapply.

Quick answer

Google can require additional closed testing even after your test reached the numerical 12-tester / 14-day threshold.

Google’s published Help documentation currently identifies two reasons that can require continued testing:

1. Fewer than 12 testers were properly opted in, or
2. Tester engagement during the testing period was insufficient.

In Google’s wording, reasons for required continued testing include fewer than 12 opted-in testers or insufficient tester engagement during the testing period. The production-access application also asks what testers actually did, what feedback you received, how that feedback was collected, what you changed, and why the app is ready for production.

Reaching the threshold makes you eligible to apply; the application then evaluates the evidence your test produced. Use this table to decide what to check first:

What Google officially says

Google’s Play Console Help article “App testing requirements for new personal developer accounts” publishes the following points.

The testing requirement. For personal developer accounts created after November 13, 2023, at least 12 testers must be continuously opted in for the preceding 14 days before you can apply for production access. Google’s wording:

Developers with personal accounts created after November 13, 2023, must run a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days.

The published reasons for required continued testing. Google names the following examples:

If your app requires additional testing, you may need to continue running your closed test. Reasons for required continued testing include having fewer than 12 opted-in testers or insufficient tester engagement during the testing period.

What Google does not publish. Google’s published Help documentation does not provide a fixed daily-open requirement, minimum session duration, minimum action count, or required number of feedback messages.

Not publicly specified

Google does not publish a fixed session-length threshold, a required number of launches per day, or a universal minimum number of actions that every tester must perform.

How engagement is weighed during an application review is likewise not published. Anything more specific than the sentences above — how many minutes each tester must use the app, how many features they must open, or how the decision is scored — is outside Google’s published documentation.

What the production-access application actually asks

The production-access application is where your testing evidence is evaluated. Google’s form currently asks the following.

About your closed test

• How easy it was to recruit testers for your app
• Details about tester engagement during the closed test:
  • whether testers used all available app features
  • whether tester usage matched expected production-user behavior, including details about meaningful differences
• Summarize the feedback received from testers, and describe how feedback was collected

About production readiness

• The changes made based on what you learned from the closed test
• How you determined that the app is ready for production

Every question above asks for a concrete, factual account of your test. That is why the diagnosis below separates the published testing reasons from application evidence gaps: the first is about the test itself, the second is about what your answers can demonstrate.

Published reason 1: The qualifying tester requirement was not satisfied

The first published reason is mechanical: the qualifying state was not satisfied when you applied.

The requirement is defined per tester. It is satisfied only when 12 testers individually satisfy continuous opt-in for the preceding 14 days — it is not one global timer that starts when the test goes live. If testers joined on different days, a qualifying tester opted out, or a qualifying tester was removed or replaced before completing the required continuous period, the point at which 12 testers qualify together may move later.

Common situations where the qualifying period differs from what you expected:

• The twelfth tester joined several days after the test started
• A tester opted out partway through the period
• A qualifying tester was removed from the list before completing the required continuous period
• A tester participated with a different Google account than the one that was invited
• A person was added to the email list but never completed opt-in — being on the list is not the same as completing opt-in

Compare the status shown in Play Console with each tester’s participation confirmation rather than counting invitations sent.

For a per-tester walkthrough of the qualifying state, see How to Check Google Play Closed Testing Progress: 12 Testers & 14 Days.

Published reason 2: Tester engagement was insufficient

The second published reason concerns what testers actually did during the testing period. Google’s application asks whether testers used all available app features and whether their behavior resembled expected production-user behavior, so a test in which nobody meaningfully used the app leaves you little to describe.

Engagement that produces describable evidence typically covers:

• First launch and onboarding, including permission prompts and initial setup
• The core user journey from sign-in through the main task
• Main feature usage, not only installation
• Expected failure paths: offline states, denied permissions, invalid input
• Repeated realistic use where appropriate, such as returning on another day

This does not mean Google requires every feature to be used by every tester. Google publishes no such rule. What the application asks you to describe is what testers actually used and how it compares with the behavior of future production users — so the test should generate evidence you can report honestly.

Google’s published guidance for engagement is also practical: give testers clear instructions, specify the type of feedback you want, and provide a feedback channel such as email, a website, or a messaging forum.

Application gap 1: You cannot describe concrete tester feedback

Google’s application asks you to summarize the feedback received from testers and to describe how feedback was collected. Before changing anything else, check whether you can answer those two requests from your records.

Records such as the following do not let you do that:

There were no problems.
Everything worked for everyone.

Instead, record the tested features and conditions in concrete terms:

Twelve testers checked registration, sign-in, image upload, and history storage.
Two testers said the save-completion state was difficult to understand, so we changed the button text and added a completion message.
We published the revised build to the same track and asked the testers to verify the change again.

If no feedback channel existed during the test, there is nothing to summarize — set one up before the next round. For the items worth asking testers about, see What Feedback Should You Collect During Google Play Closed Testing?.

Application gap 2: Your answers are generic instead of app-specific

Copying sample text written for another app often produces answers that could describe any app. Generic answers make it difficult to provide the concrete information the application asks for: which features the testers used, what they reported, and what changed as a result.

Answers grounded in your own test include:

1. Who the testers were and how they were recruited
2. What they tested
3. Specific feedback received
4. Changes or improvements made
5. What was checked before requesting production access

Use How to Answer the Google Play Production-Access Application as a structure, but replace every example with facts from your own app.

Application gap 3: The application does not match what was actually tested

The application should describe the test that actually ran. Do not claim that an untested feature was tested.

If the closed-test build had a disabled purchase flow, describe the actual scope instead:

This closed test focused on the free features and account-management flows.
The purchase flow was checked separately with license testers.

If that separation did not happen, do not write it. Describe the test as it ran, and cover the missing area in the next round.

What to do before reapplying

When Google Play asks for more testing, do not immediately resend the same answers. Work through the following order.

1. Read the exact Play Console / email notice

Save the exact wording of the notice before changing anything. Google’s notification content can change over time, and your own notice takes precedence over the general guidance in this article. If your Play Console or rejection email explicitly instructs you to run an additional 14 days of closed testing, follow that instruction for your app.

2. Verify the qualifying tester state

• Are at least 12 testers currently participating?
• Are they using the invited Google accounts?
• Did they complete opt-in?
• Has anyone left the test?
• Can they receive the latest version?

3. Define realistic test scenarios

Choose scenarios that resemble production use — first launch and onboarding, the core user journey, main features, and expected failure paths — and give testers written instructions for them.

4. Collect and organize feedback

5. Fix or consciously defer issues

You do not need to implement every tester suggestion. For important feedback, record whether you:

• Fixed it
• Intentionally deferred it
• Rejected it, and why
• Retested the changed behavior

What the application asks for is that you can explain what you did about the feedback you received.

6. Retest changed behavior

Publish a revised build when necessary: increase the versionCode and distribute it on the same closed-testing track, then confirm that testers received it and that the changed behavior works. An update is not automatically required in every case. If you make a change based on tester feedback, keeping a retest record is a useful way to support your explanation of what changed and why you considered the revised behavior ready.

7. Rewrite the application from actual evidence

Clearly explain what was added after the previous application:

After the previous application, we conducted additional closed testing.
Testers reported that the sign-in failure guidance and save-completion state were unclear, so we revised the wording and screen transition.
We then asked testers to check the revised build and confirmed that the target flows completed successfully.

For the full second-round workflow — organizing the previous test record, prioritizing feedback, and making the difference from the previous application explicit — see How to Reapply After Google Play Requires More Testing.

Actions to avoid

• Inventing tester activity that did not occur
• Claiming changes that were not implemented
• Repeatedly submitting the same answers within a short period
• Asking people only to join without using the app
• Treating any checklist as a promise of approval

No outside service can guarantee production access.

Summary

A more testing required result means Google reviewed your application and decided that additional testing is needed. Google publishes two example reasons — fewer than 12 opted-in testers and insufficient tester engagement — and the application asks for evidence: what testers did, what feedback they gave, how it was collected, and what changed.

Check whether:

• At least 12 testers individually satisfy continuous opt-in for the preceding 14 days
• Testers actually used the app in ways you can describe
• Specific feedback was recorded and summarized
• Feedback led to fixes, conscious deferrals, or further verification
• The application answers match what really happened

For a step-by-step reapplication process, see How to Reapply After Google Play Requires More Testing.