Google Play closed testing: 12 testers, held 14 consecutive days

Stripped of the surrounding guidance, the requirement is four measurable things: at least twelve testers, each of whom has opted in, held continuously for at least fourteen days, on a closed testing track. Satisfy all four and Play Console unlocks the production access application. Miss any one and the form stays shut, with no explanation offered beyond the requirement itself.

Two words in that sentence do more work than the rest. Opted in means the tester accepted the invitation, not that you listed their address. Consecutive means the count has to hold across the whole window rather than average out across it — there is no credit for a good fortnight with a bad Tuesday in the middle.

Everything else you have read about this rule is commentary. The four conditions are the rule, and a test that satisfies them passes regardless of how the testers were found.

The requirement attaches to personal developer accounts created on or after 13 November 2023. Accounts registered as an organisation are outside it, and personal accounts older than that date were never brought inside it. If you are not sure which you hold, the account type is on the developer account page in Play Console, and it is worth checking before you spend a fortnight on a rule that may not bind you.

The part that catches people out is what happens next. The requirement is assessed per app, not per account, so passing it once buys you nothing for the app you ship after this one. Studios shipping four or five titles a year are running this fourteen-day window four or five times a year, which is exactly why it is worth making it a scheduled line item rather than a scramble.

The rule arrived as part of a broader effort to keep abandoned and half-finished apps out of the public store. The reasoning is straightforward: two weeks of genuine use by a dozen people surfaces the crashes, the confusing first-run, and the projects that were never really going to be finished — and it surfaces them before the general public ever sees the listing.

That framing explains the shape of the review. Reviewers are not counting installs; they are looking for a pattern that is consistent with people actually using software. Twelve opt-ins in the first hour followed by thirteen days of silence is a recognisable shape, and it is not the shape of a real test.

It also explains why the questionnaire at the end is weighted so heavily. A test that genuinely happened produces things to say about it. A test that was performed for the reviewer's benefit produces two vague sentences, and reviewers read a great many of both.

Play Console offers three testing tracks and only one of them advances you toward production access. Internal testing takes up to a hundred testers, goes live within minutes, and contributes nothing at all to the requirement. Open testing is a public beta, discoverable on the store, and likewise does not substitute for the closed track.

Closed testing is the one that counts. Testers join through an opt-in link, by email list or Google Group, and the fourteen-day clock runs on this track alone.

The order that works: keep the build on internal while it is still moving daily, promote to closed once twelve people could use it for a fortnight without hitting a wall, and treat open testing as something you may want after production access rather than before it.

The free routes are real and we point people at them: friends with Android phones, developer communities running reciprocal testing swaps, your own mailing list if you have one. They cost nothing but attention, and the trade is that reciprocity has to be honoured — every person testing your app for a fortnight expects a fortnight of yours in return.

What they share is an attrition problem. People who joined as a favour drop off around day four, and the count you need to hold for two weeks is precisely the thing informal arrangements are worst at holding.

The paid route converts a social problem into a scheduling one, which is the whole of its value. Before paying anyone — us included — the questions worth asking are: are these people on their own devices, is the activity spread across the window or bunched at the start, and what happens if Google still refuses. Vague answers to any of the three tell you what you need to know.

This is the distinction that decides most closed tests, and it is almost invisible until it has already cost you a fortnight. Adding an email address to the tester list does not notify anyone, does not enrol anyone, and does not move the number Google reads. The invitation only becomes a tester when that person opens your opt-in link and accepts.

So there are two numbers, and they are rarely equal. The length of your tester list is the one that looks reassuring. The opted-in count is the one the requirement is measured against, and if you only ever look at the first, you can run a confident, diligent test that was never counting at all.

Send the opt-in link directly, to each person, and confirm they landed on the accept screen. It is a tedious five minutes that removes the single most common failure in the process.

Two things end a run. The first is the opted-in count falling below twelve at any point in the window — someone leaves the test, changes phone, or clears an account, and the streak has a hole in it. The second is the closed track going away: the release unpublished, the track paused, a rollout halted while you fix something urgent.

Almost everything else developers worry about is harmless. Adding testers mid-window does not reset anything. A tester having a quiet day is not a breach. Uploading a new build to the same track is fine, and covered in the next chapter.

The practical defence is margin. Running at exactly twelve means the first dropout puts you under the line, usually around day nine, with no time to recruit and no way to recover the days already banked. Sixteen on the track means four people can vanish and the fortnight still finishes.

A closed test is not a freeze. You can push new builds to the track throughout the window, and doing so does not reset the fourteen days as long as the track stays live and your testers stay opted in.

There is an argument for actively wanting to. Testers report something on day three, you ship the fix on day five, and the questionnaire at the end has a genuine before-and-after to describe. That is a materially stronger application than fourteen unchanged days, because it demonstrates the thing the rule exists to encourage.

The one caution is scale. A release that changes the sign-in flow or ships a new permission prompt mid-window can strand testers outside the app, and a build that crashes on launch converts your remaining days into nothing. Ship fixes freely; save the rewrite for after approval.

Once the testers are opted in, the work becomes maintenance. The roster is checked against the track daily, and anyone who leaves — new phone, new job, lost interest — is replaced from the bench rather than left as a gap in your count. This is the part you are actually paying for; recruiting twelve people is easy on day one and hard on day nine.

Activity is paced deliberately across the window rather than front-loaded, because a fortnight of real use and a fortnight of compliance theatre look different to anyone reading the pattern, and only one of them is what the rule asks for.

Written feedback lands with you around day ten, ahead of the fourteenth, so you have time to ship a fix and describe it in the application rather than discovering an issue the morning you were planning to apply.

On the fifteenth day the production access form opens: roughly ten questions about how you recruited your testers, what the testing surfaced, and what you changed as a result. The temptation is to treat it as paperwork attached to a box you have already ticked. It is not — it is assessed, and thin answers get applications returned even when the fourteen days were clean.

What reads well is specificity, because specificity is what a real test produces and a performed one cannot fake. Dates. Numbers. The actual bug someone hit on a mid-range device, the change you shipped on day six, what the crash rate did afterwards. What reads badly is the generic paragraph, and reviewers see a great many generic paragraphs.

We hand you draft answers built from your own test — the real dates, the real counts, the real feedback — to edit into your own voice. It is a first draft with the facts already in it, not a template with blanks.

A refusal does not mark the app or the account. You can apply again, and roughly a third of the apps that reach us have already been through exactly this. What matters is resisting the instinct to immediately re-run the same fortnight, because an identical test with fresh faces reliably produces an identical outcome.

There are only really two diagnoses. Either the test itself did not hold — the count dipped, the activity was bunched into the first two days, the track went down — or the test was fine and the application was thin. They call for completely different fixes, and it is usually possible to tell which from the console history and the answers that were submitted.

If your test ran its course with us and Google still refused, email us the refusal and the money goes back to the original card. No form, no arguing your case. If you would rather run it again than take the refund, we will do that instead.

Approval usually comes back within a couple of days of applying, and it unlocks publishing to everyone for this app. The requirement is discharged for this title permanently — you never repeat the fourteen days for it, whatever you ship afterwards.

Two things are worth knowing on the way out. The next app you publish under the same personal account starts from zero, so build the fortnight into the plan rather than rediscovering it a week before launch. And the closed track you just spent two weeks populating is genuinely useful infrastructure: a standing group of people who will look at a release candidate before the public does, which is a better position than most launched apps are in.