DEV Community: Jay

12 Testers for 14 Days: What "Continuously" Really Means

Jay — Fri, 30 Oct 2026 12:14:11 +0000

To publish to production, a new personal developer account has this task on the Play Console dashboard: Run your closed test with at least 12 testers, for at least 14 days.

It looks simple, and the countdown moves forward by itself, so many developers assume they just have to wait 14 days. But what Google means by "continuously" is much stricter than that countdown.

Do all 12 testers have to start on the same day? What if someone opts out halfway? Do testers have to open the app every day? You'll find different answers online, and some of them contradict each other. This post goes through Google's own wording, point by point.

1. What Google actually says

Start with the original wording. Hover over that task on the dashboard and a tooltip spells it out:

When you apply for production access, at least 12 testers must be opted-in to your closed test. They must have been opted-in for the last 14 days continuously

Play Console Help goes into more detail in App testing requirements for new personal developer accounts, and the sections below quote it line by line.

Put together, it comes down to 3 key phrases:

When you apply: the requirement is checked at the moment you click "Apply for production"
The last 14 days: counted backward from the day you apply
Opted in continuously: those 12 people have to stay opted in for the whole 14 days

2. Do all 12 testers have to start on the same day?

No. Google doesn't require everyone to join on the same day. The countdown starts on the day the 12th tester opts in.

For example:

Day 1: 10 people opt in
Day 3: the 11th person joins
Day 5: the 12th person joins

The 14-day countdown starts on day 5, so the earliest you can apply is day 19. The first 4 days with 10 people don't get you there any sooner.

So the slower you gather testers, the longer you wait. It's best to get everyone together first and start at the same time.

3. The countdown doesn't stop, but "continuously" can still break

On the surface: the 14 days never seem to break

As covered in Google Play closed testing: 5 things new developers get wrong, the 14-day countdown on the dashboard works like this:

It starts once the 12th account opts in, whether or not anyone installs or opens the app
Once it starts, it doesn't stop on its own, even if some testers opt out

If you only look at the dashboard, the 14 days almost never break. You just wait and they run out.

In reality: these 5 things break "continuously"

The countdown is just a timer. It doesn't check whether your testing was really continuous. Of the 5 cases below, the first two are about the rules; the other three don't show up in the count at all, but they do show up in review.

① A tester opts out

This is the one Google states most clearly:

Testers who opt in, test for fewer than 14 days, and then opt out do not count toward the requirement.

If a tester opts out and opts back in later, the 14 days must be consecutive to count toward the minimum requirement of 12 continuous opted-in testers.

So if someone opts out halfway, the countdown keeps running, but that person no longer counts toward "12 continuous testers". If you have exactly 12, losing one means you no longer meet the requirement. That's why you should always stay above 12 and keep some margin.

② Your application is rejected

In our own experience, when an application for production access is rejected with "More testing required", the countdown restarts on the day of the rejection. The 14 days you already ran don't carry over to the next round.

③ Opted in, but never installed

A tester opens your opt-in link and taps Become a tester, and your opted-in count goes up by 1. But they may never install your app.

The count doesn't break at all, but your installed audience is 0. In review, that looks like nobody tested.

④ Uninstalled halfway

Uninstalling the app is not opting out. A tester who uninstalls your app is still opted in, so your opted-in count doesn't drop and the countdown isn't affected.

But installed audience in Play Console drops, and the statistics show clearly that testing stopped partway.

⑤ Installed, but never opened

The app stays installed, but nobody opens it. If Daily Active Users (DAU) stays close to 0 for a long time, your testers aren't really testing.

Google lists this explicitly as a reason for more testing:

Reasons for required continued testing include having fewer than 12 opted-in testers or insufficient tester engagement during the testing period.

Summary

Case	Countdown	Counts as a tester	In review
① Opts out	Keeps running	No	You may fall below 12
② Application rejected	Restarts	—	Another round of testing
③ Opted in, never installed	Keeps running	Yes	Low installed audience
④ Uninstalled halfway	Keeps running	Yes	Installed audience drops
⑤ Installed, never opened	Keeps running	Yes	DAU near 0

Only case ② restarts the countdown. In the other 4, it keeps running as usual. But Google can see all 5 when it reviews your application.

To find installed audience and DAU in Play Console, see the first two sections of "More testing required" on Google Play: 5 reasons and fixes, with screenshots and steps.

4. So do testers have to open the app every day?

Google doesn't say testers must open the app every day, and it doesn't set a number of minutes. Missing a day or two won't restart the countdown.

But when you apply for production access, the questions ask about tester engagement, for example:

Whether testers used all available app features

Whether tester usage matched expected production user behavior

You'll often see this claim online: "As long as testers don't opt out or uninstall, it doesn't matter whether they use the app." That's only half right. If testers don't opt out, they keep counting and the countdown can finish. But if the app just sits there and almost nobody opens it, you're likely to get "More testing required" in review.

A safer approach: you don't need every tester to open the app every single day, but across the 14 days your DAU line should always have data.

5. 3 common myths

"All 12 testers must install on the same day." No. The countdown starts on the day the 12th tester opts in. See section 2.
"Once the countdown finishes, you've tested for 14 continuous days." The countdown doesn't stop when testers opt out, never install, uninstall, or never open the app, but all of these break the real "continuously". See section 3.
"Miss opening the app one day and the 14 days start over." No. What restarts the countdown is a rejected application, not a missed day. See section 4.

6. How to get through the 14 days safely

Put the sections above together and it comes down to a few things:

Gather everyone first, start together: don't make the early testers wait for nothing
Keep a margin: have a few more than 12, so one person opting out isn't a problem
No opting out, no uninstalling: tell testers up front not to opt out or uninstall the app during the 14 days. Google makes the same point in its help page: "Inform your testers that they need to remain opted in to your closed test continuously for at least 14 days."
Use the app naturally every day: no need to pad screen time, but keep your DAU line from going empty

BetaLobby is a platform where developers help each other through closed testing, built around exactly these points:

Teams of 16: each app gets 15 testers, a margin above 12
Everyone starts together: once all members have installed their teammates' apps, the 14 days start at the same time
Daily check-ins: each check-in really opens your app, and you can see in the app how many testers checked in each day
4 hearts of slack: missing a day or two doesn't break Google's rules, but not using the app for a long time hurts in review. So everyone has 4 hearts, and TRUST is only deducted after missing more than 4 days in the 14

In the end, the "continuously" Google wants isn't a dashboard countdown that reaches 14 days. It's 12 or more people really using your app throughout those 14 days.

Originally published on betalobby.com.

Google Play closed testing: 5 things new developers get wrong

Jay — Thu, 29 Oct 2026 11:52:55 +0000

For a new personal developer account, the rule for production looks simple: at least 12 testers, opted in to your closed test for at least 14 days in a row.

In practice, from development through closed testing to production, a few points are easy to misunderstand, and getting them wrong often costs an extra round of testing.

1. Opted in is not installed, and installed is not opened every day

When a tester opens your opt-in link (play.google.com/apps/testing/<package>) and taps Become a tester, the opted-in count in Play Console goes up by one right away.

That only means they opted in. It doesn't mean they installed your app, and it certainly doesn't mean they open it every day.

Play Console tracks these as three separate numbers:

Opted-in testers: what the application requirements count
Installed audience: people who actually have your app installed
Daily Active Users (DAU): people who opened your app on a given day

Where to find the last two, and why they matter so much when you apply for production, is covered with screenshots in "More testing required" on Google Play: 5 reasons and fixes.

2. The 14-day countdown is not 14 days of real testing

On the dashboard, the countdown for "Run your closed test with at least 12 testers, for at least 14 days" is easy to read as proof that your test is good enough. It has little to do with how well you tested:

It has nothing to do with installs. Whether or not anyone actually installs or opens your app, the 14-day countdown still starts.
The 14 days don't stop. Once the 12th Google account opts in, the countdown officially starts, and it won't stop on its own before day 14, even if some testers opt out (Google's requirement is still at least 12 testers for 14 days in a row, so it's best to stay above 12).
It resets automatically. Think of the 14 days as an hourglass that flips itself. If your last application was rejected, the countdown restarts on the day of the rejection, again regardless of installs or testing activity.

That's why this number can't be your measure of a good test: when the countdown finishes, it only means you can apply. It doesn't mean your test passed.

3. Internal testing is not closed testing

After you create a new app in Play Console, the dashboard lists a series of tasks, and internal testing is first. Many developers assume it's a required step toward production and spend real time on it.

Play Console says so right under that task: "This is optional, and you'll still need to run a closed test before publishing to everyone in production."

Internal testing doesn't count toward production access. The required part is closed testing: the 12 testers / 14 days rule only counts your closed testing track.

Internal testing is still a useful tool for sending a new build to a few trusted people fast. If you just want to install a new version yourself without waiting for closed testing review, try internal app sharing (Test and release > Testing > Internal app sharing) instead: upload a build and get an install link, no review, and only people with the link can install it.

Two things to watch with internal app sharing:

The test phone has to turn on "Internal app sharing" in the Play Store settings first, or the link won't open
Google re-signs internal app sharing builds with a different key. If your app uses Google Sign-In, add the internal app sharing certificate fingerprint to your OAuth client in Google Cloud too, or sign-in fails in that build

4. Closed testing countries are separate from production

When picking countries / regions, many developers worry they can't change them later, so they only select the few countries they plan to launch in. That's a misunderstanding:

They're independent. Closed testing and production are separate tracks, each with its own countries / regions setting. Selecting every country for closed testing doesn't affect launching production in just a few.
You can change them anytime. Both tracks' countries / regions can be edited whenever you like. Just remember to go to Publishing overview and send the changes for review. They take effect once approved.

If your closed test is only open in a few countries, testers elsewhere get "Item not found" when they open your link. It's one of the 5 causes of "Item not found" on a closed testing link. So go ahead and select all countries / regions for your closed testing track. Recruiting testers gets much easier.

5. Meeting 12 testers / 14 days doesn't guarantee production access

This is the last one, and the most expensive. Once all three requirements are ticked on the dashboard and Apply for production is clickable, a lot of people assume they're done.

Those three requirements are only the bar for applying. After you submit, Google reviews your test: whether testers really used the app, whether you shipped updates based on feedback during the test, and how seriously you answered the questions. Fall short, and you get a "More testing required" email and another 14 days.

For how to check each part, see "More testing required" on Google Play: 5 reasons and fixes.

Final thoughts

The closed testing rule fits in one sentence, but every number in it can mean something other than what you think. Getting these 5 points straight can save you at least one extra round.

BetaLobby is a platform where developers help each other through closed testing, designed around exactly these traps:

Everyone shares one Google Group, so you join once and can test every app on the platform
Team mode requires your closed test to be open in all 178 countries / regions, so no teammate gets blocked by region
Each daily check-in really opens your app, and you can see in the app how many testers checked in each day

Whether you get production access is still up to Google. But making sure testers actually install your app and actually open it every day is the part you can get right.

Originally published on betalobby.com.

"More testing required" on Google Play: 5 reasons and fixes

Jay — Tue, 20 Oct 2026 15:44:00 +0000

You found 12 testers, ran your closed test for 14 days straight, clicked Apply for production, and a few days later this landed in your inbox: More testing required to access Google Play production.

I got this email more than once while applying for production access myself.

The email gives only two reasons, and both are vague:

Testers were not engaged with your app during your closed test
You didn't follow testing best practices, which may include gathering and acting on user feedback through updates to your app

Then it asks you to "test your app using closed testing for an additional 14 days with real testers" before applying again.

Google doesn't publish exactly how it reviews applications, so what follows isn't an official answer. It's what I learned from being rejected and finally approved: the 5 things most worth checking.

Installed audience
Daily Active Users (DAU)
App quality and updates during the test
How you fill in the application questions
Whether your testers are real

Go through them before you start the next 14 days.

1. Installed audience: opted in is not the same as installed

The most common misunderstanding about closed testing: the number of testers who opted in, the number who installed your app, and the number who open it each day are three different numbers. Play Console showing 12 opted-in testers doesn't mean 12 people installed your app. There are several more assumptions like this, which I covered in 5 things new developers get wrong about closed testing.

To see real installs, open Play Console and click Statistics in the left menu. By default it shows Installed audience for the last 28 days.

One catch: the chart is split by Country / region, with 5 rows selected by default (all countries plus your top 4), so you see several lines at once. Open that filter, keep only All countries / regions, untick the rest, and click Apply. The single line left is your total installed audience.

Play Console defines it as the number of users who have your app installed on at least one device that has been turned on in the last 30 days. It counts people, not installs, so one person installing on two phones counts once.

I also noticed something in my own tests: when several devices on the same network (the same Wi-Fi, say) installed the app with different accounts, installed audience only went up by 1. That isn't part of Google's definition and I'm not sure why it happens, but if most of your testers are family or coworkers in one place, keep an eye on it.

How many do you need? My advice: before you apply, keep this at 12 or more. Higher is better.

Just started recruiting and see nothing? The data isn't real-time and usually lags by two or three days. Give it time.

2. Daily Active Users (DAU): installed but never opened doesn't count

This is the metric people overlook most. Many developers assume that if testers install the app and don't uninstall it for 14 days, the test "counts". But the first reason in the email, "testers were not engaged with your app", is exactly about this.

To check it, stay on the Statistics page, open the Installed audience metric picker, and choose Engagement > Daily Active Users (DAU). Play Console's definition is simple: the number of users who opened your app on a given day.

The country filter you set earlier stays on, so again read the All countries / regions line. If the chart is empty, don't panic. DAU lags even more than installed audience, often by several days.

How much DAU do you need? Around 12 a day is ideal, but don't obsess over the exact number. What matters is that the line has data every day. If it stays close to zero for the whole test, your testers aren't really opening your app, and the risk of rejection goes up a lot.

So when you recruit testers, be clear: installing isn't enough, they need to open the app every day for 14 days.

3. App quality, and whether you shipped updates during the test

Almost every first-time developer misses this. Many think closed testing is about finding testers. The real focus is the app itself. Getting 12 testers only meets the baseline. Whether you get production access has a lot to do with your app's quality and how you iterate during the test.

App quality. There's no strict bar, but at minimum:

Your privacy policy and the App content declarations in Play Console are filled in correctly
The app is complete, not a single-screen shell
Use Android's official app quality guidelines as a reference

Updates during the test. The second reason in the email, "you didn't follow testing best practices, which may include gathering and acting on user feedback through updates to your app", is about this.

The 12 testers / 14 days rule exists so developers polish their apps before going public, instead of flooding the store with low-quality apps. If you're building your app seriously, you'll find more to fix during closed testing than you expect. So ship new versions during the test, whether or not testers sent feedback.

There's no official number. From my experience: release at least 3 versions with real changes in each round of testing, and write down what each one changed. You'll need it for the questions.

4. The application questions: where you show you're serious

This matters as much as anything above. If you rush through the questions, or reapply without changing a word of your old answers, you'll most likely get another rejection and another 14 days.

There's no model answer, and don't copy anyone else's. But a few things raise your chances a lot:

Be completely honest. The first question asks whether you used a paid testing provider. That answer, the changes you made, your intended audience: nothing made up, nothing exaggerated.
Use the space. Each text box allows up to 300 characters. If you tested properly, filling it is easy. I'd aim for at least about 260 characters per answer.
Keep the grammar clean. If you're unsure, let AI check your grammar, but don't let it write your answers from scratch. It easily invents facts, which breaks the first rule.
Update for this round. When you reapply, the boxes are pre-filled with your previous answers. Don't just click Next. Go through each one and change whatever is different this time. You'll also get an extra question about what you changed since your last application: new recruiting channels, the updates you shipped.

To prepare ahead, try our free production access questionnaire: all 9 questions word for word as in Play Console, with the same 300-character count, and drafts that stay in your own browser.

5. Are your testers real?

This is the most complicated one and the hardest to pin down. Google doesn't say how it decides who is a "real tester", but any of these may land you here:

Too few installed users, or almost no DAU
Testers installing and opening your app on emulators
Dozens of accounts all on the exact same device model

If you used a paid testing service, had enough testers, and were still rejected, ask whether that usage would look like real use from Google's side.

Checklist before you reapply

Before the next 14 days, check each one:

Installed audience in Statistics is 12 or more
Daily Active Users (DAU) has data every day
You shipped at least 3 versions with real changes during the test and noted what each changed
Your privacy policy and App content declarations are correct, and the app is complete
Every answer is honest, uses the space, and was updated for this application
Your testers are real people on real devices

Final thoughts

A rejection doesn't mean your app is bad. Most of the time, the test just didn't show Google enough real use and iteration.

I learned all this the hard way, one rejection at a time. It's also why I built BetaLobby, a platform where developers help each other through closed testing. 16 developers form a team and install each other's apps, so everyone gets 15 testers at once. Your testers are developers in the same spot as you, who also need to pass closed testing. Each daily check-in really opens your app, and you can see in the app how many testers checked in each day. Emulators can't join teams, pair, or check in. It's completely free, with no paid testing of any kind.

Whether you get production access is still up to Google, and no platform can guarantee it. But real testers, real daily use, and real iteration during the test are the parts you can control.

Originally published on betalobby.com.