Internal Testing vs Closed Testing vs Open Testing

Google Play Console gives you three testing tracks before production, and choosing between internal testing vs closed testing vs open testing decides who can install your app, how fast builds reach them and whether anyone can find the test on Google Play. This guide compares the three tracks side by side, using only what Google documents in its Help Center articles Set up an open, closed, or internal test and Control when app changes are reviewed and published.

The short version: internal testing is for a small trusted group and fast iteration, closed testing is for a wider group you control, and open testing puts a test version on Google Play for anyone to join.

The three tracks at a glance

Google describes the purpose of each track as follows. Internal testing distributes your app quickly to up to 100 testers for initial quality assurance checks. Closed testing lets you test pre-release versions with a wider set of testers to gather targeted feedback. Open testing runs a test with a large group and makes the test version visible on Google Play, where anyone can join and submit private feedback.

Question	Internal	Closed	Open
Who can join	Testers you list by email	Testers on your email lists, Google Groups or organizations	Anyone
Size	Up to 100 testers per app	Up to 200 email lists of up to 2,000 users each; up to 50 lists per track	Unlimited, or a limit you set of at least 1,000
Needed before you start	Nothing; can start before app setup is complete	Completed app setup	For new personal accounts, production access
Visible on Google Play	No	No; testers use a link	Yes
Country targeting	Doesn't apply; testers from any location	Yes (not on additional closed tracks)	Yes
Paid apps	Testers install for free	Testers must purchase	Testers must purchase
How many at once	Can run alongside closed and open tests	Multiple closed tests	One open test

Internal testing: small, fast and trusted

Internal testing is built for speed. Google says that when you publish a new Android App Bundle to the internal test track, it becomes available to testers within minutes, and first-time uploads are available to internal testers immediately, showing a temporary name and store listing information for up to 48 hours. You manage internal testers with an email list, up to 100 testers per app.

Internal testing is also the only track you can use before app setup is complete. You can start an internal test before completing app setup, and you can test an app that is not fully configured once you have a valid app bundle. Google notes a few consequences: users see a temporary name for the app on Google Play before its first review, the package name is fixed once you upload an artifact, and purchases made in apps on the internal test track or in draft are subject to spend limits.

Several rules differ from the other tracks:

• Countries: you can add users from any location. If an internal tester is in a country where your production, open or closed version isn't available, they still get the internal test.
• Payment: for paid apps, internal testers install the test version for free. They still pay for in-app purchases unless you add them to a license testers list.
• Devices: device exclusion rules don't apply to internal testers.
• Reviews: Google says internal tests might not be subject to standard Play policy or security reviews, and apps active on internal testing tracks are exempt from inclusion in Google Play's Data safety section.

Two review caveats apply. If your app's first release is on the internal test track, that submission must be reviewed before it can be published; Google says reviews can take a few hours or up to seven days, or longer in exceptional cases. This does not apply to internal test apps that are not fully configured. And if your previous submission was rejected, the next one must be reviewed before it becomes available, even on the internal track. Otherwise, internal test updates are not subject to reviews, but may be subject to retroactive reviews after going live.

Closed testing: a wider group you control

Closed testing sits between the two. Google describes it as a way to test pre-release versions with a wider set of testers after testing with a smaller group of colleagues or trusted users. A closed testing track is available as your initial closed test, and you can create and name additional closed tracks if you need them, for example for different teams working on different features.

You choose testers in three ways: email lists, Google Groups (only members can join, and they must join the group before opting in) or organizations that use managed Google Play. Closed testing requires completed app setup. Testers cannot find a closed test by searching Google Play before an open test or production release, so you share an opt-in link with them, and each tester opts in themselves.

For previously published apps, only users in your test group receive updates for closed versions. In paid apps, closed testers must purchase the app. You can target closed testing releases to specific countries, although additional closed tracks don't support country targeting.

For new personal developer accounts, closed testing also carries a requirement the other tracks don't: it is the track where you need at least 12 testers opted in continuously for 14 days before applying for production access. Our guide to Google Play closed testing requirements explains who that applies to, and the closed testing setup guide walks through the steps.

Open testing: visible on Google Play

Open testing puts your test version on Google Play. Google recommends making sure your app and store listing are ready for visibility before choosing it, because anyone can join an open testing program and submit private feedback.

How users find an open test depends on your app's state. For early access apps, meaning new apps not yet published to production, users can find the open test through search on Google Play. For apps with an active production version, users can opt in to the open test directly from your store listing. Anyone with the open test URL can also join.

You can leave the number of open testers unlimited, which is the default, or set a limit, which must be at least 1,000. You can run one open test at a time. For personal developer accounts created after November 13, 2023, open testing becomes available only after you gain production access, so it cannot stand in for the closed test.

Which version does each tester receive?

When someone is a tester on more than one track, Google's version rules decide what they get. A device receives the app version with the highest version code that is compatible with the device and published to a track the user is eligible to receive. All users are eligible for production; users in closed testing are eligible for production and closed testing; users in open testing for production and open testing.

To be eligible for a test track, a user must both be included in the track's configuration and actively opt in to that test. Internal testing has an extra rule: users who opt in to internal testing aren't eligible for open and closed testing, even if they are listed as testers there, and receive only the version on the internal track. To join a closed or open test, they must opt out of the internal test first.

The same rule means that if you publish an app bundle with a higher version code to production than to a test track, testers on that track receive the production release.

Which track should you use?

Google's own recommendation is to start with an internal test, then expand to a small group of closed testers. From there, the choice follows from what you need:

• Fast checks with your own team: internal testing. Builds reach testers within minutes, and you can use it before app setup is complete.
• Targeted feedback from a group you choose: closed testing. It is also the track new personal accounts need for production access.
• Broad feedback from anyone on Google Play: open testing, once your app and store listing are ready to be public and, for new personal accounts, after production access.

The tracks are not exclusive. Google says you can run multiple closed tests and one open test at the same time, and internal tests can run concurrently with closed and open tests for different app versions. If you use managed publishing for a product launch, Google strongly recommends publishing your app to a closed testing track first.

Rollouts, countries and ending a test

Some release tools work across tracks. You can release updates to production and test tracks using a staged rollout, where an update reaches a percentage of users that you increase over time. By default, testing releases match the country availability you set for production, and you can customize country targeting for open and closed testing releases; country targeting doesn't apply to the internal track.

To end any test, go to the track's page, click Manage track and then Pause track. Google notes that after ending a test, testers don't receive updates, but the app stays installed on their devices. Feedback from testers on any track doesn't affect your app's public rating, and testers can't leave public reviews on test versions.

Frequently asked questions