Google Play Internal Testing vs Closed Testing
A simple comparison of internal and closed testing, and which one you need before applying for production.
Read the guide →
You may be building more than one app, or planning a second one while the first is in testing. Recruiting 12 new people for every app is slow, so it is natural to ask: can the same testers test several apps? Short answer: opt-in works per app, and nothing we found in Google's documentation forbids it. The long answer is about engagement, bookkeeping and the mistakes that cost you days. Here is how to do it well.
Yes, in practice the same person can opt in to the closed tests of several apps, because each test has its own opt-in link and its own tester list. Google's testing help page describes opt-in as a per-test action, and the requirements page talks about the testers of your app. We could not find a statement from Google about testers who also test other apps, so we cannot say how, or whether, Google treats overlap. We recommend you plan for genuine use of each app rather than counting heads.
Reusing the same list is easy: tick it on each app's track. If you want the setup details, see email list vs Google Group and our guide to adding testers.
Google's production access questionnaire asks about your closed test, including how you ran it and what you learned. Google also says the review can ask for more testing when there are too few opted-in testers or tester engagement is low. A tester who has two apps on their phone but opens neither is worth less than one person who uses one app daily. That is the real limit on reuse: attention.
| Testers per person | What usually happens |
|---|---|
| 1 app | Best engagement. The person remembers what to do. |
| 2 apps | Fine if the person opens both a little each day. |
| 3 apps | Possible, but reminders become necessary. |
| 4+ apps | Engagement drops. Expect people to leave or to stop opening apps. |
Say you need 12 testers for each of three apps and you expect 20 percent to drop out. Without reuse you would recruit 45 people. With a shared pool you can do much less, as the table shows. These are planning examples, not Google rules.
| Approach | People needed | Notes |
|---|---|---|
| Separate testers for each app | 3 × 15 = 45 | Most variety, slowest to recruit |
| Fully shared pool | 15 to 18 | Everyone tests all three apps. Highest burden per person. |
| Partial overlap | 25 to 30 | A core of 10 shared people plus separate testers per app |
The buffer maths comes from the 12 testers rule: people needed = testers required ÷ (1 − expected drop-out).
| Person | App A: joined | App A: day 14 | App B: joined | App B: day 14 | Notes | |
|---|---|---|---|---|---|---|
| Example | name@gmail.com | Oct 1 | Oct 15 | Oct 4 | Oct 18 | Prefers evening reminders |
Recruit new people when you are close to the 12 minimum, when the same group has already given you all the feedback they can, or when you need testers on different devices or countries. If you need a quick, reliable pool, a testing service supplies real Android testers so you do not depend on friends who lose interest.
Google's help pages describe opt-in per app and per test, and we did not find a Google rule that forbids the same person from testing more than one app. Each app needs its own opt-in link and its own 14 days.
No. Each app has its own closed test, and the testers must be opted in to that app's test for 14 days.
Google does not describe how it reviews tester overlap. The production access questionnaire asks about your test and tester engagement, so real, active use is what matters most.
Different people give you more varied feedback, but it is not required by anything we found in Google's documentation. Real use of each app is more important than the number of new faces.
Google says that a user opted in to the internal test cannot receive open or closed test versions until they opt out of internal testing.
Realistically two or three at the same time. Past that, daily use of every app drops, and your test engagement suffers.