Closed or Open Testing on Google Play? A Decision Guide by Situation

If you have a new personal developer account, you need a closed test. That is the track Google's testing requirement is built around. Open testing is optional, and as far as we know it does not replace the closed test. This post helps you decide what to run, in what order, and what to skip.

Rules change, so check the current wording in Play Console Help before you plan your release.

The three test tracks in one minute

Play Console offers three kinds of testing before production. They differ mainly in who can join and how visible the test is.

• Internal testing: a small group you pick, with fast availability. Good for checking that a build installs and runs.
• Closed testing: a group you choose through email lists or similar methods. Only invited people can join.
• Open testing: anyone can find the test and join, usually from your Play Store listing.

Limits, review behavior and how each track is shown can change. The Help page above is the source of truth.

Decide by your situation

You have a new personal account and need production access

Run a closed test. Since November 13, 2023, new personal accounts have had to complete one before applying for production. The requirement started at 20 testers and is now 12 testers opted in for 14 days in a row.

An open test is not a shortcut here. Even if 200 strangers join your open test, that does not obviously count toward the closed-test requirement. Don't assume it does. Read the requirement page for your account type.

You have an older account or an organization account

The 12-tester requirement may not apply to you, so you can choose based on what your app needs. Your account type and creation date matter, so check what Play Console shows for your account instead of relying on a blog post, this one included.

You only want to check that the build works

Use internal testing. It is the lightest option and good for a quick smoke test on a few devices. It won't give you the volume or variety of real-world use.

You want honest feedback from a defined group

Use closed testing. You control who is in, so you can ask for specific things: "try onboarding", "break the checkout flow", "tell me what confused you". Feedback from a small group you can follow up with is usually more useful than a pile of anonymous opinions.

You want to stress-test with a lot of people before launch

Consider open testing, but only after your closed test. It exposes the app to a wider range of devices, Android versions and expectations. It also means the app is publicly discoverable as a test, so it should already be reasonably stable.

What open testing costs you

Open testing is not just a closed test with more people. Think through these trade-offs first:

• Visibility: anyone can join, so a rough build is visible to the public. Rough first impressions are hard to undo.
• Less control: you can't pick who tests or ask a specific person to retest something.
• Noisier feedback: people join for different reasons. Some give detailed reports, many give none.
• Possible review: builds on a more public track may be reviewed by Google, and timing varies. Leave room in your schedule.

None of this makes open testing bad. It is just a different tool, and most solo developers reach for it too early.

A sensible order for most indie developers

1. Internal test to confirm the build installs, signs correctly and doesn't crash on launch.
2. Closed test with enough real people to meet the requirement, plus a few who give real feedback.
3. Fix what the closed test found. This is where most of the value is.
4. Open test (optional) if you want wider device coverage or early public interest.
5. Apply for production once you meet the requirements.

You can skip step 4 and lose nothing. You can't skip step 2 if your account is subject to the requirement.

Mistakes that waste weeks

Treating open testing as a way around the closed test

It sounds efficient, but you may spend two weeks on a track that doesn't satisfy the requirement and then have to start the closed test anyway.

Recruiting exactly 12 testers

The requirement is 12 testers opted in for 14 days in a row. If one person opts out or never installs, you can fall below the line. Recruit a few extra so one dropout doesn't cost you days.

Confusing "opted in" with "actually using the app"

Meeting a number is one thing. Learning something is another. If testers install the app and never open it, you pass a counter but get no useful signal about crashes, confusing screens or slow startup.

Shipping the same build you tested on one phone

Your own device is the least informative test device you have. Different screen sizes, manufacturers and Android versions turn up bugs you can't reproduce at your desk.

Where TesterMob fits

The hard part of a closed test is usually finding 12 people who will stay opted in for two weeks. TesterMob supplies real testers for that. They use their own Android phones, spend about 20 minutes a day in your app and send written feedback. Developers pay $9.99 per app, once, in USDT, with no subscription (see pricing).

There is also an optional Android SDK (an .aar file) that shows daily tester activity in your dashboard, so you can see whether people are actually using the app.

TesterMob is not affiliated with Google and can't guarantee production approval. It handles the tester side of a closed test. Whether you're approved is Google's decision. More detail is in the FAQ.

The short version

• New personal account: run a closed test. It's the one the requirement is about.
• Just checking the build: internal test.
• Want a wider audience after fixing bugs: open test, as an optional extra.
• Not sure what applies to you: check Play Console Help for your account before you start the 14-day clock.

Most developers don't have to choose between closed and open testing. They need the closed test now and may add the open one later.