Do You Need 12 Testers for Every App on Google Play?
Guide · Last updated September 30, 2026 · 7 min read
Senior full stack developer specializing in Laravel, React, and Firebase. Helped 1,200+ Android developers pass Google Play Closed Testing and publish apps. Expert in Play Console, production access, and Android app publishing.
Do you need 12 testers for every app?
Per app, yes
Each app that needs production access runs its own closed test.
Same testers, fine
There is no rule that testers must be new people.
Fresh 14 days each time
The continuous opt-in window applies to each app.
Updates do not restart it
Apps already in production keep updating normally.
Per app, per test, per window
Three things are counted separately. Conflating them is what makes this requirement feel unpredictable.
Your tester pool can be reused
Nothing in Google's requirement says the twelve people must be new to you. If a group already trusts you enough to test one app, they can test the next one too.
You cannot copy the test across
There is no mechanism to carry a completed closed test from one app to another. Each app gets its own track, its own tester list, and its own 14-day window.
Parallel apps still need parallel windows
Two apps in flight at the same time each need their own qualifying window. Running them together is possible; running them off one 14-day period is not.
Releases inside the test are expected
Google recommends continuing the closed test while you resolve issues and says updating before releasing to production helps reduce low ratings. Shipping a fix mid-window is normal practice, not a reset.
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.
Google also states that the requirement is checked as of the application: testers must be opted in when you apply, and must have been opted in continuously for the preceding 14 days. Each app's application is a separate check against that app's own test.
What each situation actually needs
The common cases developers ask about, with the answer that applies to each.
| Situation | Is a new closed test required? |
|---|---|
| Your first app on a new personal account | Yes — 12 opted-in testers for 14 continuous days |
| A second, unrelated app on the same account | Yes — its own closed test, its own 14-day window |
| An update to an app already in production | No — normal release review applies |
| A new app where the testers already tested your last app | Yes, but they must opt in to this app and stay for 14 days |
| A second app in the same category or brand family | Yes — Google's requirement attaches to the app |
| An app that already has production access on another account | Depends on that account, not on the app |
Based on Google's article, which scopes the requirement to personal developer accounts created after November 13, 2023, and measures testers per test. Confirm against your own Play Console Dashboard where possible.
You can reuse testers, but not the test
The distinction between a person and a qualification is the whole of this section.
The relationship with your testers.
A group that has already been through a 14-day window knows what "stay opted in" means, which usually makes the second run smoother than the first.
The qualified status itself. Nothing in Play Console lets you mark a closed test as reused for another app.
The new app needs its own track, its own tester list, and a fresh 14-day continuous window.
One practical wrinkle we hit in parallel campaigns: a tester can be opted in to more than one closed test at the same time, so running two apps together is possible. What you cannot do is count the same person twice toward one app's minimum.
Our observation rather than a documented rule: treat each app's window as independent and do not assume a single tester group can be stretched across three apps without one of them slipping.
How to plan when you have more than one app
The sequencing decision is the one that costs money if you get it wrong.
Count your queued apps before you start, not after the first one finishes.
Decide up front whether to run the windows in sequence or in parallel.
Confirm every tester will opt in again for the new app, in writing.
Size the group above 12 for each app, especially when running two at once.
Keep the same confirmation routine for every window — it is the part that fails.
If you have two apps and a group of exactly twelve, the arithmetic is unforgiving: one dropout in either window takes both apps below the minimum at once. This is the situation where a buffer stops being a nicety and starts being the plan.
Testing two apps? Plan both windows together
Campaigns include a tester buffer and daily opt-in confirmation, so one dropout does not take two apps below the minimum.
12 testers per app: FAQ
Multiple apps, reused testers, and what updates actually change.