No. Nothing in Google’s testing requirements says your testers have to be new, different, or unique to each app. The same 12 people can test every app you publish.
What does change per app is the test itself. Each app needs its own closed test, with at least 12 testers opted in for 14 continuous days. The people in that group can be identical every time.
What Google actually requires
The rule is that a personal developer account created after 13 November 2023 must run a closed test with a minimum of 12 testers who have been opted in for at least the last 14 days continuously.
Read that carefully. It sets a requirement on:
- How many testers (at least 12)
- How long they are opted in (14 continuous days)
- Which track (closed testing)
It says nothing about who those testers are, whether they have tested for you before, or whether they must be different from the last group. Google’s own guidance even suggests recruiting from friends, family, colleagues and classmates, which are exactly the people you would reuse.
So what is per app and what is per person?
| Thing | Per app or reusable? |
|---|---|
| The closed test itself | Per app. Each app runs its own test |
| The 14 continuous days | Per app, and per tester within it |
| The people testing | Reusable. Same group is fine |
| Tester opt-in | Per app. They must join each app separately |
| The production access form | Per app |
The practical consequence: if you build a group of 12 to 16 reliable testers once, you can carry that group across every app you launch. You only have to solve the recruitment problem properly one time.
The catch nobody mentions: testers must opt in again
Reusing people does not mean reusing their opt-in. Closed testing opt-in is tied to a specific app, so for every new app your testers have to open that app’s opt-in link, click Become a tester, and install it.
This is where reused groups quietly fail. Everyone assumes that because they tested your last app they are automatically on the new one, nobody opts in, and your tester count sits at zero while you think the clock is running.
Send the new opt-in link explicitly, and confirm the count in Play Console before you start counting days.
The 14 days is per tester, not just per test
This trips up developers who swap testers mid-test. Google states that it will not count testers who opted in, tested for less than 14 days, then opted out, and that even if they opt back in, the 14 days must be consecutive.
In other words, each individual tester needs their own unbroken 14-day stretch of being opted in. If someone drops out on day 10 and you add a replacement, that replacement starts their own 14-day count from the day they join.
This is the practical argument for recruiting more than 12. Start with 14 to 16 people and a couple of dropouts do not push your finish line back by a fortnight.
Does the requirement ever go away?
It applies to personal developer accounts created after 13 November 2023. Organization accounts registered to a legal business entity are exempt, and personal accounts created before that date are not subject to it.
Community reporting and developer experience vary on whether every subsequent app needs its own test once an account has production access, and Google’s public documentation does not spell this out clearly. The safe assumption is that each new app needs its own closed test until you have seen otherwise on your own account. Check the Publishing overview for your specific app in Play Console rather than relying on what happened for someone else.
How to build a tester group you can reuse
- Recruit 14 to 16, not 12. The buffer absorbs dropouts without restarting anyone’s 14-day clock.
- Keep a single list. One spreadsheet of tester emails you can paste into every new app.
- Tell them what testing involves before they agree: open the app on most days for two weeks, not just install it.
- Send the opt-in link separately for each app, and confirm the Play Console count before counting days.
- Give them something back. Reciprocal testing, early access, or credit in the app all work better than asking for favours repeatedly.
Frequently asked questions
Can my 12 testers be the same friends every time?
Yes. There is no rule against reusing people. What matters is that they genuinely use each app during its test.
Do testers need different Google accounts per app?
No. The same Google account can be a tester on as many of your apps as you like.
Can I use the same testers for apps on different developer accounts?
Yes. Testers are just Google accounts on a list, not tied to a single developer.
If a tester already tested my last app, does that count toward the new one?
No. The 14 days is measured per app. Their history with a previous app of yours does not carry over.
What if the same testers stop engaging by my third app?
This is the real risk with reusing a small group. Engagement fades when people have no reason to use the app. If your record is thinning across launches, refresh part of the group rather than pushing the same people through another 14 days.
How many testers should I actually recruit?
Fourteen to sixteen. Twelve is the floor, and being at exactly the floor means one dropout puts you below the requirement.
Build the group once
The recruitment problem only has to be solved properly one time, but most developers solve it badly and then repeat the pain on every launch. Testers Community assigns verified testers within 6 hours, keeps them active for the full period, and replaces anyone who goes inactive, so your 14 days are never reset by a dropout. Submit your app to start, or read the full closed testing requirements.
