Play Console offers three ways to get a build into people's hands before it reaches everyone: internal testing, closed testing and open testing. They look similar in the console, but they are designed for different stages of a release, and on a new personal developer account only one of them helps you get to production.
This article explains what each track is for, how they compare, and the order that makes sense for a brand-new app.
The three tracks at a glance
| Internal testing | Closed testing | Open testing | |
|---|---|---|---|
| Who can join | Up to 100 testers you name by email | Testers on your email lists or in your Google Groups | Anyone who finds the test on Google Play |
| How testers join | Opt-in link | Opt-in link | Join from your store listing or the opt-in link |
| Speed | Built for fast iteration | Goes through review | Goes through review |
| Visible on Google Play | No | No | Yes, as an early access or testing program |
| Counts for the 12 testers, 14 days rule | No | Yes | No |
| Available on a new personal account | Yes | Yes | Only after production access is granted |
Internal testing: your team, fast
Internal testing is meant for you and the people building the app with you. You can add up to 100 testers by email, and new builds are designed to reach them quickly, which makes it the right place for checking that a release works before anyone outside the team sees it.
Use it to confirm the bundle installs from Google Play, that sign-in, in-app purchases and other Play services behave correctly with the production package name, and that nothing is broken on the handful of devices your team owns.
There is also internal app sharing, a separate feature that lets you upload a build and share a link without managing a track at all. It is handy for quick checks with a colleague, but it is not a testing track and does not count either.
Closed testing: invited testers, and the track that counts
Closed testing is for a wider group of people you invite. Testers are added through email lists or Google Groups, open your opt-in link, accept the invitation and install the app from Google Play. The app is not visible to the public, and only invited accounts can install it.
For personal developer accounts created after November 13, 2023, this is the track that matters most: you need at least 12 testers opted in to a closed test for 14 continuous days before you can apply for production access. See the requirement explained for how the days are counted.
When to use closed testing
- Meeting the 12 testers, 14 days requirement on a new personal account.
- Beta testing with a specific group, such as early customers, a company's staff or a community you control.
- Running several tests in parallel. You can create additional closed tracks, for example one per feature or per client.
Closed testing releases go through Google's review, so allow time for that before testers can install. Our closed testing setup guide covers every step.
Open testing: public beta
Open testing makes your test version visible on Google Play. Anyone can find it and join, and you can cap the number of testers if you want to keep it manageable. People who join receive the test version of your app instead of the production one.
It is ideal for a large public beta before launch, or for trying out a big redesign on volunteers who opted in for early access.
On a new personal account, though, open testing is not available until your app has production access. Developers sometimes hope to use it to recruit testers for the requirement, but the requirement must be met through a closed test first.
Production: everyone
Production is the release everyone on Google Play can install. On new personal accounts it is unlocked app by app: finish the closed test, click Apply for production on the Dashboard and answer Google's questions. Our guide to answering the production access questions shows what reviewers look for.
Even after launch, production supports staged rollouts: you can release an update to a percentage of users first and increase it as long as crash rates stay healthy. Think of it as a fourth safety net after the testing tracks.
The order that works for a new personal account
- Internal testing for a few days: install from Google Play yourself, check sign-in, billing and the main flows.
- Closed testing for at least 14 days with 12 or more engaged testers. Ship at least one update based on what they report.
- Apply for production and answer the questions with specifics from the closed test.
- Production with a staged rollout, and optionally open testing for future betas once it is unlocked.
You do not have to move the same build through every track. It is common to keep internal testing running for the team while the closed test carries a slightly older, more stable build.
Common points of confusion
Promoting a release between tracks
You can promote a release from internal to closed testing, or from closed testing to production, instead of uploading the bundle again. The version code stays the same, which keeps your release history tidy.
Testers on more than one track
If the same person is a tester on several tracks, they generally receive the build with the highest version code available to them. If your closed testers report seeing a newer internal build, check who is on which list.
Removing a tester
Removing someone from your email list or Google Group means they no longer count as an opted-in tester. Do it deliberately, and make sure you stay above 12 during the 14 days.
Which track for which situation
| Situation | Track to use |
|---|---|
| You want to check a build on your own phone before anyone else sees it | Internal testing |
| Your new personal account needs 12 testers for 14 days | Closed testing |
| A client or company wants to try the app privately | Closed testing, with their Google Group |
| You want a public beta with thousands of volunteers | Open testing, once production is unlocked |
| You need to share one build with a colleague right now | Internal app sharing |
| You are releasing an update and want to limit risk | Production with a staged rollout |
The most common mistake on new accounts is spending the first week of testing on the internal track, then discovering it never counted. If your goal is production access, put your testers on a closed track from the start and use internal testing only for your own quick checks.
Summary
Use internal testing for quick checks with your team, closed testing for invited testers and the 12 testers, 14 days rule, open testing for public betas once production is unlocked, and production with a staged rollout for the launch itself. If finding closed testers is your bottleneck, here are the realistic options, including services such as TesterBie that run the closed test on real Android phones. Prices are on our pricing section.
Frequently asked questions
Does internal testing count for the 12 testers requirement?
No. Only testers opted in to a closed testing track count toward the requirement of at least 12 testers for 14 continuous days.
Can I use open testing instead of closed testing on a new account?
No. On personal accounts created after November 13, 2023, open testing becomes available together with production access, after the closed testing requirement has been met and approved.
Can I run internal and closed testing at the same time?
Yes. The tracks are independent. Many developers keep a fast-moving internal track for the team while the closed test runs on a more stable build.
Do closed testing reviews take as long as production reviews?
Both go through Google's review, and timing varies. The first review for a new app is often the slowest, so submit your closed testing release as early as you can.