Closed testing vs internal testing: which one Google requires

If you have been running an internal test for two weeks and production access is still locked, this is why:

Internal testing does not satisfy the requirement. You need a closed test.

It is an easy mistake. Both tracks distribute pre-release builds to testers, both show up under Testing in Play Console, and internal testing is faster and easier to set up — so it is the one people reach for first.

The tracks, side by side

| | Internal testing | Closed testing | |---|---|---| | Testers | Up to 100, by email address | Far larger; email lists or Google Groups | | Review | Skipped or minimal | Full review before it goes live | | Speed to testers | Minutes | Hours to days on first submission | | Opt-in link | Yes, for named testers | Yes, shareable with your tester list | | Counts toward production access | No | Yes |

The last row is the only one that matters for your immediate problem.

Why Google draws the line there

The requirement exists to make sure an app has been in front of a genuine group of people before it reaches the store. Internal testing is deliberately frictionless: up to 100 addresses you type in yourself, no meaningful review. That is exactly what you want for your own team, and exactly what you would use to trivially satisfy a requirement if it counted.

Closed testing goes through review and is built around a real tester list. It is a weaker signal than a public launch and a much stronger one than emailing yourself.

Switching over

If you have been on the wrong track, you have not lost your work — but the 14-day clock starts from your closed test, not from whenever your internal test began. Move today.

1. Play Console → Testing → Closed testing. Create a track (the default is usually named "Alpha").
2. Add your testers. An email list works; a Google Group is easier to manage at twelve or more, since people join without you editing a list each time.
3. Upload your build and roll out. Expect review on first submission — budget a day or two.
4. Copy the opt-in link and send it to your testers. Nobody counts until they accept it.
5. Verify the opted-in count in Play Console before you start counting days. This is the step people skip, and it is why some tests quietly run at 9.

Keep the internal track. Using internal for fast iteration and closed for the requirement is a genuinely good setup, and the two do not interfere.

The part that is actually hard

Setting up the track takes twenty minutes. Finding 12 real humans who will install your app and leave it installed for a fortnight is the part that stalls launches for weeks.

That is the problem TestersWiz exists for: developers in the same position test each other's apps, every opt-in is verified against the developer's own Play Console list, and check-ins provide evidence the testing actually happened. Browse apps looking for testers, or read how it works for developers.

The honest caveat

Play Console's interface and Google's requirements both change. Verify against the official Play Console Help documentation before acting. Google alone decides production access, and TestersWiz is not affiliated with Google.