DEV Community: Dev Connect

Why your Google Play testers are not counting

Dev Connect — Mon, 17 Aug 2026 08:15:05 +0000

Short answer: They usually are not counting because they are not opted into the closed track, the 14-day clock has not completed, they slipped below the minimum, or they are in internal testing, which does not count toward the closed-test requirement.

Your testers are usually not counting because Play Console only counts testers who are opted into the correct closed test, and for personal accounts created after 13 November 2023, that closed test must stay at 12 opted-in testers for 14 continuous days before production access can be requested. Internal testing does not count toward that requirement.

The part people get wrong is simple: adding email addresses is not the same as getting counted. A tester has to open the closed-test opt-in link and stay opted in. If they leave the test, uninstall in a way that ends participation, or move between test tracks, the count can stop matching what you expected. Google says testers who opt in, test for less than 14 days, and then opt out do not count, even if they later opt back in.

The inconvenient part is that the clock is strict. The 14 days must be continuous. If you reach 12 and later drop below 12, the count does not stay safely banked for production access. You need 12 opted-in testers again, and the 14-day window has to be satisfied with that continuous stretch.

Another common reason is that the testers are in the wrong track. Internal testing is useful for fast QA and can include up to 100 testers, but it is separate from the closed-testing requirement for production access. A user who opts into your internal test is not eligible for an open or closed test until they opt out of internal testing and then opt in to the other track.

That means a tester can be real, active, and useful, but still not count in the place you are checking. Play Console is not asking, “Did someone try the app?” It is asking whether the right testers are opted into the right closed test for the full required period.

If your testers say they joined, confirm the exact opt-in path. They need the closed-test invitation or opt-in link for that app, then they need to accept it with a Google account that remains in the test. If you only shared the app by APK, by sideloading, or through another channel, that may help your debugging, but it will not satisfy the closed-test counter in Play Console.

If the number is lower than expected, check for these issues first: some testers never opened the opt-in link, some opted into internal testing instead of closed testing, some left the test before day 14, and some were added too late to count for the full window. Google also notes that your app may still be held back if testers are not engaged with the app during the closed test.

If you are trying to debug a stalled count, use this order: verify that the testers are on the closed track, verify that each one is opted in, verify that you have at least 12 opted-in testers, and verify that the 14 days have been continuous. Do not assume the counter should behave like a simple headcount of invited emails. It is a track-based eligibility check, not a mailing list tally.

A second misunderstanding is thinking internal testing can stand in for closed testing. It cannot. Internal testing is for quick distribution to up to 100 testers, while closed testing is the track that counts for production access under the personal-account rule. If your testers are all sitting in internal testing, Play Console can still show that you do not have the closed-test requirement met.

A third misunderstanding is expecting the count to update the way a spreadsheet does. Play Console is enforcing policy, not just displaying enrollment. So the right question is not only “How many testers do I have?” but also “How many testers are currently opted into the closed test, and have they stayed there long enough without interruption?”

If you are close to the threshold, be careful with churn. A tester leaving, changing tracks, or failing to complete the opt-in process can break the run. The simplest practical fix is to keep a small buffer above the minimum so one person dropping off does not force you to restart. Google’s requirement is 12, but the margin you keep above that is your own risk management, not a policy change.

If you want to reduce confusion for testers, send them only the closed-test opt-in link for the app, then ask them to stay opted in and keep the app installed for the full window. That does not guarantee production access, but it does align with what Play Console actually counts.

For teams building on DevConnect, this is also where reciprocity matters. The platform is meant for real testing exchange on owned projects, not for mass automation or artificial activity. If you need a place to coordinate testers on work you control, use the testing process itself, then keep the closed-test requirements separate from anything else you do. https://devconnectplatform.com?ref=devto

In short, testers are not counting when the track is wrong, the opt-in is incomplete, the 14-day period is not continuous, or the count dropped below the minimum. The fix is to make the closed test the source of truth and keep 12 testers opted in there for the full 14-day stretch.

Frequently asked

Does internal testing count toward the 12 tester requirement

No. Internal testing is a separate track for up to 100 testers, and it does not count toward the closed-test production-access requirement.

Do testers need to do anything after they opt in once

They need to stay opted in for the full continuous 14-day period. If they opt out and later return, the interrupted days do not count as one continuous stretch.

What if I have 12 invited testers, but Play Console shows fewer

Then some of them probably never completed closed-test opt-in, are on the wrong track, or have not stayed opted in continuously long enough.

Can I use internal testing instead of closed testing to get production access

No. Internal testing is useful for QA, but production access for newer personal accounts depends on a closed test with 12 opted-in testers for 14 continuous days.

Sources

Originally published at devconnectplatform.com, where it is kept up to date.

Why I made it free with no ads, and what that costs me

Dev Connect — Mon, 17 Aug 2026 08:15:04 +0000

DevConnect is free. There is no advertising, no paid tier that unlocks the useful parts, and no algorithm deciding who deserves reach. People ask how that is supposed to work, which is fair.

The reasoning

Every developer platform I have watched go bad went bad the same way. It started useful, grew, needed revenue, and the cheapest revenue is attention. Once attention is the product, the feed stops showing you what is good and starts showing you what keeps you scrolling. Nobody decides to ruin it, it just follows from what is being sold.

The second failure is subtler. Once there is a paid tier, the free tier has to be worse on purpose. That is not a bug in the business model, it is the business model.

I did not want to build either of those, so I removed the option early, while it is still easy to remove.

What it costs

Money, obviously. It runs on a small budget and I pay for it.

But the real cost is slower. Without advertising there is no budget to buy attention, so growth has to come from the thing being useful enough that someone tells someone else. That is a much slower loop than paying for installs, and there is no shortcut in it.

It also means I cannot promise scale. The platform is small right now. Anyone who tells you their new community is thriving is either lucky or lying, and you will find out which within a minute of signing up.

What I am actually betting on

That a place with no ads, no gatekeeping and no rage-bait is worth being small for a while. And that people who build things would rather be somewhere honest than somewhere busy.

If that sounds like you: https://devconnectplatform.com?ref=devto. Posting is free, the job listings show salaries, and the tester exchange is there because everyone shipping to Google Play needs the same favour from someone.

If it does not, that is genuinely fine. I would rather be useful to a few hundred people than optimised for everyone.

Paying 30 dollars for 12 Google Play testers, or trading with someone who needs the same thing

Dev Connect — Sun, 16 Aug 2026 08:15:03 +0000

If your Play developer account is newer than 13 November 2023, you need 12 testers opted in for 14 continuous days before you can ship to production. There is no way around it, so a small industry appeared to sell you the way through it.

It costs somewhere between 20 and 50 dollars. Here is an honest comparison with the alternative.

What you get when you pay

Accounts. Twelve of them, opted in, staying opted in for the two weeks. The counter moves and you ship.

What you do not get is information. Those accounts will not tell you the onboarding is confusing, that the app crashes on a three year old device, or that nobody understands what the second tab is for. If you thought you were buying a beta test, you were buying a checkbox.

That is fine, as long as you know it. Sometimes a checkbox is exactly what you need, because you already tested the app with people who care.

What you get when you trade

The other option is finding developers in the same situation. Everyone with a new Play account needs the same 12 testers, so the incentive is symmetric in a way it almost never is: you install their app for two weeks, they install yours.

The cost to you is nearly nothing. You already have an Android device, and keeping one more app installed is not work. The value to them is the same thing you need.

And unlike bought accounts, the person testing your app is a developer who will notice things, and sometimes tell you.

Where it goes wrong

Trading fails when one side disappears. Someone installs, gets busy, uninstalls in week two, and your count drops below 12 without any notification. That is not dishonesty, that is what favours look like without a deadline.

The fix is not trust, it is over-recruiting. Get 15 to 20, not exactly 12, so one person leaving does not restart your two weeks.

What I built

A tester exchange at https://devconnectplatform.com/app-testing.?ref=devto Free, no ads, and it tracks who actually completed tests for other people so that reliable testers get matched first.

There is also a free tracker for the 14 days that needs no account at all: https://devconnectplatform.com/tools/closed-test-tracker?ref=devto

It is new and small, so I will not pretend there is a crowd waiting. But the mechanism works because both sides need the same thing, and that is the part money cannot buy you.

Put the salary in the job post. All of it.

Dev Connect — Sun, 16 Aug 2026 08:15:02 +0000

Every developer has had this conversation. Four interview rounds, a take-home task, and then a number that was never going to work, which both sides could have known in the first minute.

The usual defence of hiding it is that the range depends on the candidate. That is true, and it is also why a range exists. "60 to 80 thousand depending on experience" costs the employer nothing and saves everyone a week.

What actually happens when you hide it

You do not get more applicants, you get worse ones. People who know their market rate filter out listings without a number, because experience taught them what the silence usually means. The people who stay in the funnel are the ones with the least information about what they are worth, and hiring them cheaply is a short-term win with a long-term bill attached.

You also lose the ones you most wanted. Someone who is currently employed and reasonably paid will not spend four evenings on a process to discover the number is 20 percent below where they are.

The counter-argument that is actually real

Existing employees will compare themselves to the listing. That is a legitimate worry and it has one honest answer: if publishing your range causes trouble internally, the trouble already existed and you were just not being told about it.

What we do about it

On DevConnect, a job listing cannot be posted without a salary range. Not "competitive", not "DOE", a number. It is a required field, so there is nothing to negotiate about it.

That is not a moral position, it is a practical one. A job board where half the listings hide the number is a job board where you have to open every listing to find out if it is worth your time, and that makes the whole thing worth less.

You can see what that looks like here: https://devconnectplatform.com/jobs.?ref=devto It is free to post, there is no advertising, and there are not many listings yet, because it is new.

If you are hiring and your range genuinely cannot be published, that is worth sitting with for a minute. Usually it can.

I shipped a product without being a "real" developer. Here is what that actually looks like.

Dev Connect — Sat, 15 Aug 2026 13:35:38 +0000

I do not have a computer science degree. I write code with AI doing most of the typing. And I have a product in production with real users on it.

That sentence makes some people angry, so let me be precise about what it does and does not mean.

What it does not mean

It does not mean I do not understand what I ship. If you cannot read what the model wrote, you cannot tell when it is wrong, and it is wrong often enough that this matters. The failure mode is not bad syntax, the code usually runs. The failure mode is code that runs and does the wrong thing quietly.

It also does not mean it was fast. Building the thing was fast. Making it correct took much longer, and most of that time went into problems the model could not see: what should happen when two people do the same thing at once, what a stranger can read that they should not, what breaks when a table has ten thousand rows instead of ten.

What it does mean

The bottleneck moved. It used to be "can I write this". Now it is "do I know what should be written". That is a better bottleneck to have, and it is also a harder one to fake, because there is no model that will tell you what your product should be.

The skill that pays off is not prompting. It is reading a diff and asking why. Every time I skipped that step I paid for it within a week.

The part nobody warns you about

You will build something that works and then discover the hard part was never the building. Getting the first ten people to care is harder than any technical problem I hit, and no amount of tooling helps.

That is the honest version. If someone is selling you the story where AI makes you a founder in a weekend, they are selling you the easy half.

Why I am writing this

I run https://devconnectplatform.com, a place for people who build real products with AI. It is free, there is no advertising, and it is small. I am not going to pretend otherwise.

What is there: a feed where people post what they are building, communities, developer jobs where the salary is on the listing, and a tester exchange for the Google Play closed-testing requirement.

If you are building this way too, I would rather hear what you are stuck on than pitch you anything.

Google Play testing tracks explained: internal, closed, open, and which one gates production

Dev Connect — Sat, 15 Aug 2026 13:35:37 +0000

Google Play gives you three testing tracks plus production, and the names do not make the differences obvious. Here is what each one is for and which one is standing between you and shipping.

Internal testing

Up to 100 testers, available within minutes of upload, no review to wait for. This is your build-and-check loop, meant for your own team and people you can message directly.

What it is not: internal testing does not count towards the closed-testing requirement. People lose days here assuming it does.

Closed testing

A limited group you invite by email list or Google Group. Reviewed by Google before testers can install, so expect a wait on the first release.

This is the track that gates production. If your personal developer account was created after 13 November 2023, you need at least 12 testers opted in to a closed test for 14 continuous days before you can apply for production access. The days only count while the number stays at 12 or above, which is the detail that costs people weeks.

Open testing

Anyone with the link can join, and your app appears in Play with a "Early access" label. Good for gathering real-world feedback at volume, useful for stability data on many device models.

Open testing does not replace the closed-test requirement either. It is a distribution choice, not a shortcut.

Production

What you are trying to reach. After you have met the closed-testing requirement you apply for production access, and Google reviews the app. That review usually takes a few days, sometimes longer, and it is a separate wait from the 14 days.

The order most people end up using

Internal while you are still fixing things, because it is instant. Closed as soon as the build is worth two weeks of someone's attention, because that clock is the long pole. Open afterwards if you want broader feedback before production.

The practical consequence is that you should start recruiting closed testers earlier than feels necessary. The build does not have to be finished, it has to be installable and not embarrassing, because the two weeks run in parallel with the work you are still doing.

If you are in that closed test now, count the days from when you actually had 12 opted-in testers rather than from upload: https://devconnectplatform.com/tools/closed-test-tracker

Where to actually find Android beta testers, and what does not work

Dev Connect — Sat, 15 Aug 2026 13:15:48 +0000

If your Play developer account was created after 13 November 2023, you need 12 testers opted in for 14 continuous days before you can ship to production. So you need 12 humans with Android devices who will keep your app installed for two weeks.

Here is an honest look at where people go for that.

Posting in subreddits

The obvious move, and the one that gets people banned. Most developer subreddits treat "please test my app" as self-promotion, and the ones that allow it have a dedicated thread that everyone ignores. If you do try it, read the rules first, because a ban costs you the account, not just the post.

What does sometimes work is answering other people's questions for a while first, so you are a person and not a request. That takes weeks, which you may not have.

Paid tester services

They exist, they charge somewhere between 20 and 50 dollars, and they do deliver accounts. The question is what those accounts are. If they are farms, you get 12 installs that behave identically and never open the app, which does technically satisfy the counter and teaches you nothing about your app.

If you are paying for feedback, this is the wrong purchase. If you are paying to satisfy a checkbox, it works, and you should know that is what you bought.

Friends and family

Free, willing, and the usual reason people fail. Not because they mean badly, but because a favour has no deadline. Three of them will forget to install, one will uninstall to free up space in week two, and you will not find out until the count resets.

If you go this route, over-recruit heavily and check the count yourself instead of trusting that everyone did what they said.

Trading with other developers

The one arrangement where the incentive is symmetric. Every developer with a new Play account needs the same 12 testers you do. Testing someone else's app for two weeks costs you almost nothing, and it buys you the same from them.

That is what I built the tester exchange for: https://devconnectplatform.com/app-testing. It is free, there are no ads, and the reason it works is not the software, it is that both sides need the trade.

Whatever you choose, count properly

The 14 days only run while at least 12 testers are opted in, and one drop-out can put you back near the start. Count from the day you actually reached 12, and watch for drops. Free tracker if you want one, no account: https://devconnectplatform.com/tools/closed-test-tracker

Your Google Play closed test is not completing. Here is why.

Dev Connect — Sat, 15 Aug 2026 13:15:47 +0000

You have 12 testers. You have waited 14 days. The Play Console still will not let you apply for production access.

Almost always it is one of these five, and none of them announce themselves.

1. Some testers never actually opted in

Joining your Google Group or being on your tester list is not the same as opting in. A tester has to open your opt-in link and accept, with the same Google account that is on the device they test with. People routinely accept with their personal account and install with their work profile, which counts as nobody.

Check the opt-in count in the Play Console rather than your own list of who promised to help.

2. The count dropped below 12 at some point

This is the big one. The 14 days have to be continuous, and the counter watches the number of opted-in testers every day. If someone uninstalled on day 9, you did not lose one day, you went back near the start, and nothing told you.

This is why the advice is always to recruit 15 to 20 rather than exactly 12. Not because Google asks for more, but because people leave.

3. Testers installed but the install did not register

Sideloading the APK does not count. The install has to come through the Play Store on the closed track. If someone grabbed the file from you directly, they are testing your app but they are invisible to Google.

4. You pushed a new release and reset your own clock

Uploading a new build to the closed track is fine. Changing the track setup, removing and re-adding testers, or moving between tracks is where people accidentally restart their own count.

5. The console is just behind

Google updates these counters on a delay, and it is not always the same delay. If everything above checks out and you are on day 14, give it another day or two before assuming something is broken.

How to not be in this situation again

Count the days yourself, from the day you actually had 12 opted-in testers, and watch for drops rather than waiting for the console to tell you. I put together a free tracker for exactly this, no account needed, and the link keeps your progress: https://devconnectplatform.com/tools/closed-test-tracker

The part no tool solves is keeping 12 real people interested for two weeks. What works there is reciprocity: you test someone else's app, they test yours. Everyone in that trade needs the same thing, so nobody has to be convinced. That is the whole idea behind the tester exchange at https://devconnectplatform.com/app-testing, which is free and has no ads.

I built a free tracker for the Google Play 12 testers, 14 days rule

Dev Connect — Sat, 15 Aug 2026 13:15:46 +0000

If your personal Google Play developer account was created after 13 November 2023, you cannot ship to production until you have run a closed test with at least 12 testers opted in for 14 continuous days.

The number that breaks people is not 12. It is 14.

Why the 14 days is the hard part

The days only count while at least 12 testers are opted in. One person uninstalling on day 11 can put you back near the start, and the Play Console does not exactly shout about it. People recruit exactly 12 testers, lose two in the second week, and find out days later that they are counting from zero again.

The fix is not clever, it is just unpopular: recruit 15 to 20, not 12. Assume some will ghost.

The tracker

I got tired of counting days in a notes app, so I built one: https://devconnectplatform.com/tools/closed-test-tracker

You put in the first day your test had 12 testers and how many are opted in right now. It tells you which day you are on, what date you can apply for production access, and what happens if someone drops.

Three things about it:

No account. Nothing is stored on a server. Your progress lives in the page address itself, so you can bookmark the link or send it to the people testing for you.
It does not read your Play Console. It is a calculator, not an integration. The Play Console is the authority, and its own counter can lag a day. Use the tracker to plan, then confirm there.
It warns instead of flattering. If you sit exactly on 12, it says so, because that is the situation that costs people two weeks.

The part a tracker cannot fix

Counting is the easy half. Keeping 12 real people opted in for two straight weeks is the half that fails, and no tool solves that for you.

What does work is reciprocity: you test someone else's app, they test yours. Everybody in that trade needs the same thing, so nobody has to be talked into it. That is the idea behind the tester exchange I run at https://devconnectplatform.com/app-testing, which is free and has no ads.

If you are in the middle of a closed test right now, the tracker is the useful half of this post. Take it, it costs nothing.

Welcome

Dev Connect — Fri, 14 Aug 2026 22:47:55 +0000

We are loking for devs on : https://devconnectplatform.com/