People close to the product
Colleagues, clients and existing users. Highest opt-in rate and the most useful feedback, but rarely enough people on their own and vulnerable to the same person being asked repeatedly.
How to Get 12 Testers for Google Play
Where testers actually come from, how to keep twelve opted in through the window, and the tracking mistakes that quietly reset your progress.
What the twelve-tester figure refers to
A testing prerequisite, not a target
Google asks developers on personal accounts to run a closed test with a minimum number of testers who stay opted in for a continuous period before production access is granted. The figure most often cited is 12 testers staying opted in for 14 continuous days.
Two things are important about that. The first is that Google sets the number and the duration, and has changed them before. The second is that the requirement is a threshold to clear, not a target to hit exactly: matching the number does not oblige Google to approve anything, and falling short does not stop you running a better test.
Why the number is not the hard part
Getting twelve people to say yes is an afternoon's work for most teams. Getting twelve people to opt in with the correct Google account, install the build, and remain opted in continuously is a two-week coordination problem with no natural checkpoint.
The failure mode is rarely that you cannot find testers. It is that you believe you have twelve testers when what you actually have is twelve invitations and nine opt-ins.
Where testers actually come from
Most teams end up with a mix. Each source has a different failure mode, which is worth knowing before you rely on it.
Developer and testing communities
Places where developers trade opted-in installs. Fast to fill a roster, but participation is transactional: expect the minimum activity needed to count, and expect some to drop out.
Paid tester pools
Predictable numbers and faster to assemble. Costs money, and feedback quality and genuine app usage vary considerably between providers.
Your own channels
Newsletters, Discord servers, beta lists and social followings. Slower to convert but they produce testers with a real reason to keep the app installed.
Keeping twelve testers counted correctly
Track opt-ins, not invitations
The single most effective change you can make is to stop counting invitations. Track two separate facts per tester: whether they have opted in with the invited Google account, and when they were last active. A roster that holds both is a roster you can make decisions from.
- Record the exact Google account each tester was invited with, and have them confirm the account they opted in with.
- Treat 'invited' and 'opted in' as different states. Never sum them into one number.
- Record the date each tester opted in, so you can compute the continuous period rather than infer it.
- Check activity during the window. A tester who opted in on day two and stopped on day four will silently cost you the run.
The mistakes that cost the most time
- Inviting the wrong Google account. The tester signs in with their personal account while the invite went to a work address, and the slot stays empty.
- Duplicated addresses. Two rows for one person gives you a roster of twelve that contains eleven testers.
- Assuming a conversation is an opt-in. Verbal agreement does not install anything.
- Checking participation once, at the end. By then every fix is a restart.
- Replacing testers without checking the effect on continuity. A gap can break the continuous period you are relying on.
Answering the question in one look
"Do we have twelve testers?" should be a fact you can read, not an inference you have to make.
Four states, counted separately
- Invited: the address is on the roster and the invite has gone out
- Opted in: the tester has accepted with the Google account that was invited
- Active: the tester has opened the build recently enough to count as participating
- Reporting: the tester has raised at least one finding against the current build
The count you report is the second state. The count you act on is the third. Keeping them apart is what stops a campaign looking healthy while it quietly is not.
The roster, in the product
A real capture from the running application. Status, progress against the checks each tester committed to, and when they were last active, on one row per tester.
1. Five active of eight total: pending, testing, active and completed are four separate states. Sample data.
Questions about testers
Get the Roster Right From Day One
Tell us how many testers you need and when the window should start. We will build the roster, track opt-ins and flag anyone who goes quiet while there is still time to act.
Policy statements on this page reviewed 2026-09-27. Always confirm current requirements with Google.