Google Play 12 Testers: How to Find Real Ones

If you opened a personal Google Play developer account after 13 November 2023, you cannot ship to production until you have run a closed test with at least 12 testers who have been opted in continuously for the 14 days before you apply. That is the requirement in Google's own words, and the two parts that trip people up are "opted in" and "continuously": a tester counts from the moment they accept the opt-in link, and someone who joins, tests for a few days and then opts out does not count at all. Everything else you have heard about the rule is either the application questionnaire, which is judged separately, or someone selling you testers.

I went looking for a clean answer to this because half the pages that rank for it are companies charging twenty dollars for a dozen installs. That is a bad trade, and I will explain why below. The good news is that twelve humans is a smaller number than it feels like at 11pm on the night you finish your app, and the recruiting problem is much more tractable once you separate the hard requirement from the soft one.

What does Google actually require before production access?

Google's app testing requirements for new personal developer accounts page is the only source worth trusting here, and it is short. The requirement applies to personal Play Console accounts created after 13 November 2023. Organisation accounts are a different situation. When you apply for production access, at least 12 testers must be opted in to your closed test, and they must have been opted in continuously for the preceding 14 days.

Read that twice, because the shape of it matters:

• The clock is attached to each tester, not to the release. Twelve people opted in on day one and still opted in on day fifteen satisfies it. Twelve people who cycled in and out over a month does not.
• Opting in is a deliberate action the tester takes. Adding an email address to a list is not enough. Google's closed testing setup docs explain the two ways to manage this: an email list, where you can hold up to 200 lists of up to 2,000 addresses each, or a Google Group, where people have to join the group first and then follow your opt-in link. Both end with the tester clicking through and accepting.
• Anyone on your internal testing track is not eligible for the closed test, even if you also list them as a closed tester. Internal testing tops out at 100 people and exists for a different job. If you have been quietly using internal testing with your five closest friends, move them across deliberately and confirm each one has opted in.

Then there is the second half, which nobody labels clearly: the application itself. Google's questionnaire has three sections. It asks about your closed test (how hard recruiting was, whether testers used all the features, whether their usage matched what you expected, and a summary of the feedback you received), about the app or game (target audience, value proposition, and your estimated install range for the first year), and about production readiness (what you changed as a result of testing and how you decided you were ready).

Those are not trick questions, but they are questions about a real test with real people. You answer them from memory of actual conversations, or you answer them from nothing.

Why do paid tester pools put your account at risk?

The services selling twelve testers for the price of a takeaway solve the wrong half of the problem. They can produce opt-ins. They cannot produce the second half, and the second half is what you get graded on.

Think about what you type into the questionnaire after buying a pool. "Did testers use all the features?" You do not know. "Did usage match your expectations?" You have no expectations to compare against. "Summarise the feedback." There isn't any, so you either leave it thin or you write something you cannot support. If Google comes back and says your app requires additional testing, you continue running your closed test and you are two weeks further from launch with nothing learned.

There is a policy dimension too, and it is worth reading rather than taking on trust. Google's user ratings, reviews and installs policy states that developers must not attempt to manipulate the placement of any app on Google Play, and names inflating install counts by illegitimate means, incentivised reviews and ratings, and automated services as examples. Paying strangers to install an app so a counter reaches twelve sits close enough to that line that I would not walk it with the account I plan to ship every future app from. The upside is two saved weeks. The downside is the account.

Tester swap communities are a softer version of the same trade. Some of them work fine and produce genuine users. But a swap where both sides install, never open the app again and quietly wait out the fortnight gives you exactly the same empty questionnaire. If you use one, use it as a source of people you then actually talk to.

Where do you find twelve people who will really open it daily?

Twelve is small. You almost certainly know twelve people with Android phones; the problem is that asking feels like a favour you cannot repay. So rank the sources by how good the resulting feedback is, and start at the top.

1. People who already asked about the app. Anyone who replied to a build-in-public post, starred the repo, or said "let me know when it's out" has pre-qualified themselves. Go back through those replies by name. This is the single highest-yield source and almost nobody mines it properly.

2. The niche community your app is for. Not r/androiddev, where everyone is a developer looking for testers of their own. If you built a climbing log, the climbing forum you already post in. Post about the thing, not the test. Ask for people who would use it, and mention that testers get the app free forever if that is true.

3. Builder favour trades. Other indie makers understand what fourteen days of opt-in means because they need it too. A trade where you both genuinely use each other's apps and send real notes is worth more than either of you buying testers. Favors.dev exists for exactly this kind of swap, and the trade only works if both sides deliver something usable.

4. Friends, family and colleagues. Google's own guidance suggests these are fine, and recommends recruiting a diverse group that reflects your target audience so you catch bugs that only hit certain users. Treat them as the buffer, not the base. They will install on day one and forget by day four unless you give them a reason.

5. Anywhere your app is publicly listed. A live listing works while you sleep. Ours is free and reviewed by a person before it goes up, so a closed test posted to our showcase sits in a grid that builders actually browse rather than in a link dump. That is not a traffic promise, it is a surface.

Recruit more than twelve. Aim for eighteen to twenty opt-ins, because the number that matters is how many are still opted in on the day you apply, and attrition is normal. If you want a deeper method for finding testers when you have no following at all, our beta tester checklist covers the questions to ask once you have them, and the first 100 people guide covers the recruiting funnel above the twelve.

How do you keep testers active for fourteen straight days?

The requirement is continuous opt-in. Engagement is what the questionnaire asks about. So the plan below does two jobs: it protects the opt-in count, and it manufactures the feedback you will need to answer section one honestly.

The principle is that people stay for a story, not a chore. If every message you send is "please open the app", you are a nag. If each message says "here is what changed because of you", you are running a beta.

The fourteen day closed test plan

Day	What you ship	What you send testers
T-3	Closed test track live, opt-in link tested on your own second device	Recruiting asks go out. One personal message each, not a broadcast
T-1	Build that survives a cold install with no account	Confirm each person clicked through and can see the app. Fix the ones who cannot
1	Nothing. Do not ship on day one	Welcome note: what the app is for, the one thing to try, where to send bugs
2	Fix whatever broke on first install	"Two people hit X on install. Fixed. Here is what to try next"
3	Small visible improvement	Ask one specific question, not "any feedback?". "Did the import finish?"
4	Nothing	Quiet day. Do not message. Silence makes the next message land
5	Build with the first requested change	Name the tester whose note caused it, with permission. This is the message that keeps people
6	Nothing	Check your install and crash data. Note who has gone quiet
7	Halfway build	Short progress note: what has been fixed so far, what is next
8	Nothing	One to one nudge to the quiet ones only. Never a group guilt trip
9	Fix from week one feedback	Ask the second specific question, about a different part of the app
10	Nothing	Quiet day
11	Polish build	"Getting close to launch. Anything still annoying you?"
12	Nothing	Start drafting your questionnaire answers from real messages
13	Release candidate	Ask for the one thing they would tell a friend about it
14	Nothing	Thank you note. Say what happens next and whether they keep access
15	Verify the opt-in count in Play Console	Apply for production

Two notes on running it. First, ship something roughly every other day rather than daily; a stream of updates with nothing behind them trains people to ignore you. Second, give testers a feedback channel that takes one tap. Google's guidance recommends exactly this, an email address, a page, or a chat group, plus clear instructions on how to test and how to report a bug. A group chat with twelve people in it will out-produce a bug tracker every time at this scale.

What do you do if someone drops out on day nine?

First, work out whether they dropped out or went quiet. Those are different problems. A quiet tester still counts toward the requirement as long as they remain opted in. Someone who uninstalled the app but never opted out of the test is, by the letter of the requirement, still opted in. Someone who used the opt-out link resets to zero if they come back.

So on day nine, the fix is not panic recruiting. It is:

1. Check the actual count in Play Console, not your mental tally. This is why you recruited eighteen.
2. Message the person directly and kindly. "Totally fine if you're done, just let me know so I can plan" gets an honest answer, and often gets them back.
3. If you are genuinely below twelve, add people now and accept the new clock. A tester who opts in on day nine is eligible on day twenty three. That is five extra days, not a restart of the whole test, and it is far better than applying short and getting sent back.
4. Never ask someone to opt out and back in. It restarts their fourteen days for no benefit.

The other reason to over-recruit is that you cannot see the future of anyone's phone. People change devices, factory reset, run out of storage, go on holiday. Twelve is a floor, not a target.

What should you have ready when you apply for production?

By the time you press apply, have these in a document, because the questionnaire is easier to answer well than to answer from memory:

• A recruiting summary. Where your testers came from and how hard it was. Honest is fine. "Hard, mostly personal asks" is a real answer.
• Feature coverage notes. Which parts of the app got used and which did not. If a feature got no traffic, say so and say what you did about it.
• Expected versus actual behaviour. The gap between what you assumed people would do and what they did. This is the section where a real test is obvious and a bought one is not.
• A feedback summary with specifics. Three or four things people actually said, and what changed as a result.
• Your audience and value proposition in a sentence each, plus a realistic first year install estimate. Realistic. Nobody benefits from an invented number.
• Your production readiness reasoning. What made you decide it was ready, and what you consciously left for later.

Write these as you go, during the fourteen days, not on day fifteen. That is the whole reason the plan above has a message on day twelve.

FAQ

Do the 12 testers have to be different people?

Yes, they are counted as opted in testers, so twelve distinct accounts opted in continuously for the preceding fourteen days. Installing on several of your own devices under the same account does not produce twelve testers, and stacking accounts you control is the kind of inflation Google's ratings, reviews and installs policy names directly.

Does the 14 days have to be consecutive?

The fourteen days are consecutive per tester, and they run backwards from the day you apply. Google's page is explicit that testers must have been opted in continuously for the preceding fourteen days, and that people who opt in, test for a shorter period and then opt out do not count. There is no way to bank days from an earlier stint.

Can friends and family count as testers?

Yes. Google's guidance suggests friends, family, colleagues and classmates as recruiting sources, and also recommends a diverse group that reflects your target audience. The practical caveat is quality rather than eligibility: a friend who installs to be nice and never opens it leaves you nothing to write in the feedback section. Use them, but do not build the whole test on them.

What happens if my production application is rejected?

You keep running the closed test and apply again. Google's own wording is that if your app requires additional testing, you may need to continue running your closed test, which is a hint about what to change rather than a fixed penalty. Treat a rejection as a signal that the test itself was thin: get more genuine usage, gather feedback you can quote, make visible changes based on it, then reapply with a questionnaire full of specifics instead of generalities.

---

Fourteen days is not long when the testing produces something. Post the closed test where builders will actually see it: list your app free on TryMy, and a person reads every submission before it goes live.