Set up an open, closed, or internal test

Using Play Console, you can test your app with specific groups or open your test to Google Play users.

Testing your app allows you to fix any technical or user experience issues with minimal user impact, so you can release the best version of your app on Google Play.

Before you start

  • Email requirements: Users need a Google Account (@gmail.com) or a Google Workspace account to join a test.
  • Monetization changes: If you make changes to your app’s pricing, it affects your app's current and future versions across all tracks.
  • Country availability changes: If you make any changes to the countries and regions your app is distributed in, it affects your app's current and future versions across all tracks.
    • Note: There are some monetization and country availability exceptions for internal tests. For details, go to the section on setting up an internal test.
  • Release:
    • You must test your app before you can release it to production.
    • After publishing an open, closed, or internal test for the first time, it may take a few hours for your test link to be available to testers. If you publish additional changes, they may not be available for testers for several hours.
  • Add organizations to a test:
    • To add testers associated with an organization that uses managed Google Play, go to the Managed Google Play tab on your app's Advanced settings page (Setup > Advanced settings) and check the box next to "Turn on.”
    • If your app is private, you also need to add the organization associated with your test to your targeted list.
  • Reviews: Feedback from your test users won't affect your app's public rating.
  • Paid apps: If you’re testing a paid app using an open or closed test, testers still need to purchase it. If you’re testing a paid app using an internal test, testers can install your app for free.

Difference between an internal, closed, and open test?

You can create releases on three testing tracks before you release your app to production. Each phase of testing helps you gather the feedback you need to make improvements to your app throughout its development.

Internal testing: Create an internal testing release to quickly distribute your app to up to 100 testers for initial quality assurance checks. We recommend running an internal test before releasing your app to the closed or open tracks. If needed, you can run internal tests concurrently with closed and open tests for different versions of your app.

Closed testing: Create a closed testing release to test pre-release versions of your app with a wider set of testers to gather more targeted feedback. Once you've tested with a smaller group of colleagues or trusted users, you can expand your test to an open release. On your Closed testing page, an alpha track will be available as your initial closed test. If needed, you can also create and name additional closed tracks.

If you're testing an existing app that you've published before, only users in your test group will receive an update for your closed version.

Open testing: Create an open testing release to run a test with a large group and surface your app's test version on Google Play. If you run an open test, anyone can join your testing program and submit private feedback to you. Before choosing this option, make sure your app and store listing is ready to be visible on Google Play.

Collapse All Expand All

Tips

How do I start?

We recommend starting with an internal test, then expanding to a small group of closed testers.

Why should I run an internal test?

When you create an internal test, you can immediately release your app to your internal testers. This can help you identify issues and receive feedback earlier in your development process. An internal test is:

  • Fast: You can distribute apps via the internal test track much faster than the open or closed tracks. When you publish a new Android App Bundle to the internal test track, it will be available to testers within minutes.
    • Note: If you're publishing an app for the first time, it will be immediately available to internal testers, but will have a temporary name and store listing information for up to 48 hours.
  • Flexible: You can adjust internal tests to support different testing stages, such as quality assurance checks, and post-launch debugging.
  • Safe: With the internal test track, your test app is distributed to users securely via the Play Store.
Can I run multiple tests per app at the same time?

If you want to run multiple tests on the same app, keep the following in mind:

  • At any time, you can run multiple closed tests and one open test.
  • If a user opts to your app's internal test, they're no longer eligible to receive the open or closed test. To regain access to the open or closed test, the user must opt-out of the internal test and back into the open or closed test.

Step 1: Set up test details

Choose a testing method

Internal test: manage up to 100 testers

You can create a list of internal testers by email address. An internal test can have up to 100 testers per app.

When setting up an internal test, keep the following in mind:

  • Country distribution: You can add users from any location to your internal test. If an internal tester is located in a country where your app's production, or open or closed testing version isn't available, the user will still receive access to the internal test.
  • Payment: For paid apps, testers can install your internal test version for free. Testers need to pay for in-app purchases, unless they're also added to a licensed testers list.
  • Device exclusion rules: Device exclusion rules don't apply to internal testers.
  • Policy and security reviews: Internal tests may not be subject to the usual Play policy or security reviews.

Start an internal test

Create an email list of your testers

If you've already created an email list, skip to the "Add testers" instructions.

  1. Open Play Console and go to the Internal testing page (Testing > Internal testing).
  2. Select the Testers tab.
  3. Under “Testers,” select Create email list.
  4. Enter a list name. You can use the same list for future tests on any of your apps.
  5. Add email addresses separated by commas or click Upload CSV file. If you use a .CSV file, put each email address on its own line without any commas. 
    • Note: If you upload a .CSV file, it will overwrite any email addresses you've added.
  6. Select Save changes, then Create.

Add testers

  1. Open Play Console and go to the Internal testing page (Testing > Internal testing).
  2. Select the Testers tab.
  3. In the “Testers” table, select the user lists you want to test your release.
  4. Provide a feedback URL or email address to collect feedback from testers. Your app's feedback channel will be shown to users on your tester opt-in page.
  5. Copy the shareable link to share the release with testers.
  6. Select Save changes.

Test apps that are not fully configured

You can also create an internal testing release if your app isn’t fully configured. As soon as you have a valid app bundle, you can quickly distribute it to a limited number of testers. If you want to test an app that isn’t fully configured, you should note the following:

  • Before the app is reviewed for the first time, users will see a temporary name for the app on Google Play. You can find your app’s temporary name in the app summary on your app’s Dashboard.
  • As soon as you upload an artifact, the package name for that app is fixed and cannot be changed.
Closed test: manage testers by email address or Google Groups

With a closed test, you can create a list of testers by email address. You can create a total of 200 lists, and each list can have up to 2,000 users. You can create up to 50 lists per track.

Enter the required information to prepare your internal testing release, save your changes, and select Review release.

Start a closed test

Create an email list of your testers

If you've already created your testers list, skip to the "Add testers" instructions.

  1. Open Play Console and go to the Closed testing page (Testing > Closed testing).
  2. Select Manage track
  3. Select the Testers tab.
  4. Under “Testers,” select Create email list.
  5. Enter a list name. You can use the same list for future tests on any of your apps.
  6. Add email addresses separated by commas or click Upload CSV file. If you use a .CSV file, put each email address on its own line without any commas.
    • Note: If you upload a .CSV file, it will overwrite any email addresses you've added.
  7. Select Save changes, then Create.

Add testers

  1. Open Play Console and go to the Closed testing page (Testing > Closed testing).
  2. Select Manage track.
  3. Select the Testers tab.
  4. In the “Testers” section, you can add testers via email or Google Groups:
    • Email: Email is selected automatically. If you want to use email, just select the user lists you want to test your release. 
    • Google Groups: Select Google Groups and enter the Google Group email addresses, which use the format: yourgroupname@googlegroups.com. Only users who are members of the Google Groups you enter will be able to join your test.
  5. Provide a feedback URL or email address to collect feedback from testers. Your app's feedback channel will be shown to users on your tester opt-in page.

  6. Copy the shareable link to share the release with testers.

  7. Select Save changes.
Open test: surface your test app on Google Play

If you set up an open test, users can find your test app on Google Play. Make sure your app is ready to be visible on Google Play before choosing this option.

  • For early access apps (new apps that haven't been published to production): Users can find your open test via search on Google Play. Once users find your listing, they can install and use your app.
  • For apps with a live production version: Users can opt-in to your open test from your store listing.

You can also share a URL link on a website or email. Every user with the link can access the open test.

Start an open test

  1. Open Play Console and go to the Open testing page (Testing > Open testing).
  2. Select the Testers tab.
  3. Expand the "Manage testers" section. If the "Manage testers" section is empty, make sure you've uploaded an app bundle.
  4. Choose how many testers can use your app:
    • Unlimited: This option is selected by default.
    • Limited number: You can specify a limit (must be at least 1,000).
  5. Provide a feedback URL or email address to collect feedback from testers. Your app's feedback channel will be shown to users on your tester opt-in page.
  6. Copy the shareable link to share the release with testers.
  7. Select Save changes.
Create additional closed test tracks for your development teams

In some cases, you may need additional closed test tracks. For example, you might have different development teams that need to address bugs across different features. If each team creates their own testing track, teams can work on different features at the same time.

With additional test tracks, you can create a list of testers by email address or manage testers by Google Groups. There are no size limits to these groups.

Create an additional test track

  1. Open Play Console and go to the Closed testing page (Testing > Closed testing).
  2. Near the top right of the page, select Create.
  3. Enter a track name. The track title is used in the Play Console and Google Play Developer API as the track name.
  4. Select Create track.
  5. Select the Testers tab.
  6. In the “Testers” section, you can add testers via email or Google Groups:
    • Email: Email is selected automatically. If you want to use email, just select the user lists you want to test your release. 
    • Google Groups: Select Google Groups and enter the Google Group email addresses, which use the format: yourgroupname@googlegroups.com. Only users who are members of the Google Groups you enter will be able to join your test.
  7. Provide a feedback URL or an email address to collect feedback from testers. Your app's feedback channel will be shown to users on your tester opt-in page.
  8. Copy the shareable link to share the release with testers.
  9. Select Save.

Testing tips and support

When you create additional closed tracks, the following features aren't supported:

Manage testers for Google Play games services

If you use Google Play games services, tester groups are automatically shared between your app and Google Play games services.

Testers can try out changes you’ve saved to your game projects, like achievements and leaderboards, before they’re published to real users. You can manage testers individually using their email address or reuse the same testers as your release tracks.

On your Play Game services > Setup and management > Testers page, you can use the testers switch to automatically include any users that are opted in to testing for your app.

To manually add individual testers for Google Play games services:

  1. Open Play Console and go to the Play Games Services testers  page (Play Games Services > Setup and management > Testers).
  2. On the left menu, select Play Game services > Setup and management > Testers.
  3. Type the email addresses you'd like to add. Email addresses must be valid Google accounts that are signed in with Google Play Games Services.
  4. Select Add.

Once users have opted-in to your test group, they can sign in using Google Play Games Services, earn draft or published achievements, and post to draft or published leaderboards.

Step 2: Create a release

Once you've set up the details of your app's test, you can prepare and roll out a release.

For details on managing country availability across your app's alpha and beta tracks, go to distribute app releases to specific countries.

Step 3: Share your app with testers

If you’re running an open or closed test, testers can find your test app on Google Play using their device. If it’s a closed test, your test app will still only be available to testers in your list or group. 

If you’re running an internal or closed test prior to making your app available through open testing or rolling out to production, testers won’t be able to find it by searching on Google Play. You need to share the app’s Play Store URL with testers so they can download your app.

If for some reason your testers are unable to find your app on Google Play, you also have the option of sharing an opt-in link with them. Below are some notes when using an opt-in link:

  • The opt-in link only shows when an app is "Published." Apps in "Draft" or "Pending publication" won't show the opt-in link.
  • After clicking the opt-in link, your testers will get an explanation of what it means to be a tester and a link to opt-in. Each tester needs to opt-in using the link.
  • If you're running a closed test with a Google Group, users need to join the group before opting in to your test.

Step 4: Get feedback

Once your testers have installed your app, they'll automatically be updated to use the test version within a few minutes.

Testers can't leave public reviews on Google Play for your app’s test version, so it's a good idea to include a feedback channel or let your users know how they can provide you with feedback (by email, website, or a message forum).

If you're running an open or closed test, your testers can also provide you with private feedback through Google Play.

Step 5: End a test

To remove users from your app's test: 

  1. Open Play Console and go to the testing page for the test you want to end:
  2. Find the test you want to end and select Manage track.
    • Note: Depending on what kind of test you're ending and how many tests you’re running, you may not need to perform this step.
  3. Near the top right of the page, select Pause track.
  4. After ending a test, testers won't receive updates but the app will remain installed on their device.

Version codes and testing track statuses

Version code requirements

Users receive the version of the app that has: 

  • the highest version code that’s compatible with their device, and
  • been published to a track they're eligible to receive.

All users are always eligible to receive the production track. If an app bundle with a higher version code is published in production than in the test track where the user opted in, the user will receive the production release.

Users eligible to receive multiple tracks will receive the highest version code release published on those tracks.

For a user to be eligible to receive a test track, the user must:

  • Be included in the managed track configuration, and
  • Have opted in to the corresponding test program

For example, all users who opted in to the test program are eligible for the open test track. Users who opted in to the internal test program are not eligible for the open and closed test tracks, even if they're included in the managed testers configuration. These users would not receive the higher version code release published on those tracks.

For more information, learn about versioning your apps.

Testing track statuses

When you're rolling out your release, you may see validation messages that note when users of a given track receive app updates from another track–known as the track's fallback status.  

Fallback terms and statuses

  • Shadowed: One app bundle shadows another app bundle when it serves part or all of the same device configuration and it has a higher version code.
  • Promoted: All of the track's active app bundles are contained in the fallback track's active app bundles (for example, all of the active beta app bundles are also active in production). You may see this if you first release to a testing track and then release the tested app bundles to a more stable release.
  • Superseded: All of the active app bundles in a track is completely shadowed by active app bundles with higher version codes in its fallback track. None of the app bundles in the track are being used to serve users, as they all will be served by and app bundle from the fallback track. This means the testing program represented by the superseded track was abandoned.
  • Partially shadowed: At least one of the active app bundles in a track is shadowed by an app bundle with a higher version code in its fallback track. This means that some of the beta users will be served an app bundle from the beta track, while others may be served by an app bundle from production. This is most likely an error in assigning version codes.

Related content

Was this helpful?
How can we improve it?

Need more help?

Sign in for additional support options to quickly solve your issue

Search
Clear search
Close search
Google apps
Main menu
Search Help Center
true
92637
false