Google Play internal vs closed testing: which to use

Use internal testing to get a build to your own team quickly. It supports up to 100 testers, and a new build usually reaches them within minutes. Use closed testing when you need a larger, controlled group outside the team. If you have a personal developer account created after November 13, 2023, Google also requires a closed test before you can publish to production.

Open testing is the third track. Anyone can find and join it on Google Play. It suits a public beta, not an early check.

The details below come from Google's Play Console Help on setting up test tracks. Play Console changes over time, so confirm current limits there.

The three testing tracks at a glance

	Internal testing	Closed testing	Open testing
Who it is for	Your team, for quick QA	A wider, invited group	Anyone who wants to join
Size	Up to 100 testers per app	Email lists of up to 2,000 users each, up to 50 lists per track; Google Groups also work	Large groups
How testers join	Email list, then the opt-in link	Email lists or Google Groups, then the opt-in link	Visible on Google Play
Speed	Available "within minutes"	A new test link "can take several hours" after the first publish	Same as closed
Review	"Might not be subject to standard Play policy or security reviews"	Not stated as exempt	Not stated as exempt
Multiple tracks	One	You can create and name additional closed tracks	One

Google also notes that for paid apps, internal testers can install the test version for free.

When to use internal testing

Internal testing is for fast feedback from people you trust: developers, QA, and maybe a product owner. Typical uses:

• Checking that a build installs and launches on real devices
• Verifying a fix before it goes to a wider group
• Testing a release candidate the same day it is built

Because internal tests may skip the standard policy and security reviews, a build that works internally can still meet review problems later. Do not treat a clean internal test as proof that a production submission will pass review.

Internal testers cannot find the app by searching Google Play. They need the opt-in link.

When to use closed testing

Closed testing suits anything larger or more formal:

• A beta with real customers or design partners
• Separate groups, such as one closed track for a partner and another for staff
• Testing that needs more than 100 people
• The testing requirement for new personal developer accounts

Each tester has to opt in with the link. Google says the opt-in link "displays only when an app status is 'Published'," so plan for the delay before you announce a beta.

The 12-tester rule for new personal accounts

If your developer account is a personal account created after November 13, 2023, Google requires a closed test before production. Its testing requirements say you must run a closed test "with a minimum of 12 testers who have been opted in continuously for at least 14 days."

After that, you apply for production access from the Play Console dashboard. The application asks about your closed test, your app, and its production readiness.

Practical points:

• Internal testing does not count. The requirement is a closed test.
• "Continuously" matters. A tester who opts out partway may no longer count toward the 14 days. Recruit a few more than 12.
• Start early. The 14 days run from when testers are opted in, not from when you created the track.
• Account type matters. Google states the rule for personal accounts. If yours is an organization account, check the current requirements for it.

Moving testers between tracks

Google says that to move a tester from internal testing to an open or closed test, "the user must first opt out of the internal test."

That matters when a team member also wants to test the closed-track build. Decide which track each person belongs to before sending links.

A simple path for most teams

1. Internal testing for every candidate build, so the team catches obvious problems within minutes.
2. Closed testing for a wider group before release, or for the 14-day requirement on a new personal account.
3. Production with a staged rollout, so the first public release of each update reaches a small percentage first. See Google Play staged rollout: percentages, halts, and fixes.

How Specita tracks Google Play testing tracks

Specita reads Google Play track state with a dedicated, read-only service account. It shows which release is on which track and links store releases to your Android versions by release name or version code. Track state tells you where a build was distributed. It does not tell you how many testers installed it. The Google Play setup guide lists the viewing permissions Specita needs.