Google Play Closed Testing Requirements

Eligibility, tester participation, testing duration and application review: what Google expects, and how to check the current rules for your own account type.

Start Testing Prepare for production access

Play Console production access screen listing the closed testing criteria and the current tester and day counts — The console states the production access criteria against your own app: at least 12 testers opted in, for at least 14 days. Here it reports 12 testers opted in for 13 days continuously, so the apply button stays disabled.

Which accounts the testing prerequisite applies to

This is the first thing to settle, because it decides whether the rest of this page applies to you at all.

1.1

Personal developer accounts

Requirement: For personal accounts created after the policy was introduced, production access is gated behind a closed testing prerequisite.
What it means: If this applies to you, you cannot apply for production access until the testing condition is met. The condition is about opted-in testers over a continuous period, not about how many invitations you sent.
Where to verify: The Play Console shows the production access guidance for your own app, against your own account state. Read that before generic guidance, including this page.

1.2

Organisation accounts

Requirement: Organisation accounts have generally been treated differently, and they carry verification requirements of their own.
What it means: Do not assume a rule you read for a personal account applies to an organisation account, or the reverse. The two tracks differ in both the testing condition and the verification steps.
Where to verify: Check the documentation for your specific account type, and look at what the console asks of the account rather than the app.

1.3

Account verification

Requirement: Developer account verification has to be complete for the account type you hold.
What it means: An incomplete verification blocks the application regardless of how well the testing went, which makes it worth checking before a window starts rather than after it ends.
Where to verify: The console states any outstanding verification against your account.

1.4

A published testing release

Requirement: The app must be published to a testing track and installable by your testers.
What it means: Tester addresses on a track that has no live release do not produce installs, so no days accumulate. Check that the release cleared review before you start counting a window.
Where to verify: The Publishing overview in the console lists changes that have not yet been sent for review or published.

Tester participation

The requirement is written against testers who are opted in, which is a different number from the one most teams report.

2.1

A minimum number of opted-in testers

Requirement: Google asks for a minimum number of testers who are actually opted in to the closed test. The figure most commonly cited is 12.
What it means: Because the threshold is on opted-in testers, an invitation count does not satisfy it. A roster of twelve invitations that produced nine opt-ins is a roster of nine for this purpose.
Where to verify: The production access screen in the console states the current criterion for your app and reports your own opted-in count against it.

2.2

One account fills one slot

Requirement: Each tester opts in with a Google account, and one account fills one slot.
What it means: Duplicate addresses, or a tester who signs in with a different account than the one invited, reduce the real count without reducing the apparent count on your roster.
Where to verify: Compare the console tester list against the accounts your testers actually opted in with, rather than against the list you invited.

2.3

Testers must remain opted in

Requirement: Testers have to stay opted in to the track rather than opting in once and leaving.
What it means: A tester who leaves and rejoins can interrupt the continuous period you are relying on. This is why participation has to be watched during the window rather than checked at the end.
Where to verify: The console reports how many days testers have currently been opted in continuously, which is the figure the application rests on.

2.4

Paid testers

Requirement: Google does not treat payment as the criterion. What matters is that each tester is a real account that genuinely opts in and uses the build.
What it means: Compensating testers is not the problem. Fabricated participation, or accounts that opt in without ever installing the app, is a different thing and undermines the application.
Where to verify: Judge your own roster against that standard before you rely on it, and read Google's policy on the practice rather than a summary of it.

Testing duration

A period, and the continuity of that period, are two separate conditions.

3.1

A continuous testing period

Requirement: Google specifies a continuous period during which testers must stay opted in. The figure most widely quoted is 14 continuous days.
What it means: The word that decides whether you meet this is continuous. A window that ran for fourteen days in which the opted-in count dipped below the threshold is not the same as fourteen continuous days at or above it.
Where to verify: The console tracks the continuous day count for you and states it on the production access screen.

3.2

Interruptions

Requirement: If the opted-in tester count falls below the threshold, or testers leave and rejoin, the continuous run can be broken.
What it means: The safest reading is to treat any shortfall as an interruption and plan around it, rather than to argue afterwards that the average was acceptable.
Where to verify: Record the count daily during the window. The console will tell you the figure it is using, but only once the run is already under way.

Application review

The application is not judged on testing alone, and it is judged on what you say about it.

4.1

Review considers more than the test

Requirement: The application is reviewed alongside the app itself and your store listing.
What it means: Testing organised flawlessly around an app that is not release-ready will not carry the application. The listing and the build have to match what the app actually does.
Where to verify: Read the app's listing as a stranger would, and check it against the build you are about to submit.

4.2

Accuracy of what you submit

Requirement: The information you submit about your testing should describe what actually happened.
What it means: Describing the campaign at its best moment, rather than as it ran, is the kind of inaccuracy that is avoidable only if the campaign was recorded while it was happening.
Where to verify: Cross-check every figure you intend to submit against your own campaign record before you answer the questions.

Understanding an unsuccessful application

The reason given to you is the only authoritative explanation of your case. Diagnosing it from other developers' accounts of their own rejections usually leads to fixing the wrong thing.

Check the opted-in count, not the invite count, across the whole window.
Check the period for gaps caused by testers leaving or rejoining.
Check that the app is genuinely release-ready, separately from the testing question.
Check that the details submitted about the app and its testing agree with the listing and the console.
Check that nothing in the account itself, such as outstanding verification, is blocking the application.

An unsuccessful application is not permanent. If the reason you were given relates to testing, run a further campaign with that problem addressed rather than resubmitting the same position. If it relates to app readiness or listing accuracy, fix that first.

Questions about the requirements

Do the requirements apply to every app I publish?

Can internal testing satisfy the requirement?

What happens if the tester count drops during the window?

Are the requirements the same for organisation accounts?

How often should I re-check the requirements?

Run a Campaign That Meets the Bar

We will set the campaign up around the current requirements for your account: the right tester count, tracked opt-ins and a continuous window you can state precisely.

Policy content reviewed 2026-09-27. Always confirm current requirements with Google.

Start Testing See how it works