Last reviewed against Google Play Console Help: October 2026.
Getting 12 testers is only the beginning. The 14-day testing period is when you find out what testers actually experienced, what broke, what confused them, and what you changed before applying for production access — and it is also when most of that information quietly disappears if you are not writing it down.
This article is a working checklist for the fortnight itself: what to track, what to record, how to organise it, and how to turn it into the feedback summary and readiness answers you will need at the end. Google's requirements are quoted and linked; everything else is labelled as a recommended workflow. For the deeper feedback-specific guidance — how to document bugs, what categories of feedback matter, and a feedback summary template — see what to record during your 14-day test. This page is the management and readiness side of the same fortnight.
Quick answer
Keep one running record from day 1, and update it as things happen.
During the test, track the opted-in tester count, the dates each tester joined, the build version under test, which features were covered, the issues found, the feedback received, the fixes you shipped, and your readiness decisions. Nothing here is unusual except the timing: the value comes from writing it down while the test runs, not from reconstructing it on day 14.
Two different things are being mixed together whenever this topic comes up, so it is worth separating them once:
Google-required information
- At least 12 testers opted in continuously for the preceding 14 days when you apply
- A summary of your testing feedback — Google states you must summarise it when applying
- Answers about recruitment, engagement, feature use, changes made and readiness
Recommended testing records
- A day-by-day log of builds, features, issues and actions
- A bug register with reproduction steps and fix versions
- A record of what you changed and whether you retested it
The left column is what Google asks for; the right column is how you answer it well. Google does not require a spreadsheet, a specific tool, or any particular format — it asks you to maintain a record of received feedback and to summarise it. The rest is practical.
What Google requires
Google Play Console Help states that developers with personal accounts created after November 13, 2023 must run a closed test with a minimum of 12 testers opted in continuously for at least 14 days before the app is eligible for distribution. Until then, Production and Pre-registration stay disabled.
At the moment you apply: "At least 12 testers must be opted in to your closed test when you apply for production access, and they must have been opted in continuously for the preceding 14 days." (Play Console Help.)
Google also requires you to summarise your testing feedback when applying, and it tells developers to "maintain a record of received feedback" because reviewing it regularly helps identify recurring themes and prioritise improvements. That is the official reason to keep a record at all.
What Google does not publish: any daily open quota, minimum session length, required number of bug reports, or scoring formula. There is no official template, no required tool, and no defined number of "enough" feedback items. If a page quotes you a specific daily-activity requirement, it is not describing a Google rule.
The rest of this article is the practical layer: what to log, when, and why it pays off on day 14.
Your 14-day testing record
One table, kept in whatever you already use — Google Sheets, Excel, Notion, a plain document, or your own dashboard. The point is that the same structure is updated daily so nothing is lost.
Eight columns cover the whole fortnight:
| Field | What goes in it |
|---|---|
| Date | The day you are logging (Day 1 … Day 14) |
| Tester count | Opted-in count as shown in Play Console, plus anyone who left |
| Build version | The version code or version name currently under test |
| Features tested | Which screens or flows were exercised that day |
| Issues found | Bugs and usability problems, referenced to your bug register |
| Feedback received | What testers told you, in their words where possible |
| Action taken | What you did about it: fixed, deferred, or not an issue |
| Next step | The one thing you will do next — usually retest or ship a build |
Recommended 14-day workflow
A sensible shape for the fortnight. This is a recommended testing workflow, not an official Google-mandated schedule — Google defines the 14-day opt-in requirement, not a day-by-day plan.
Day 1 — setup and baseline: confirm the count, note the build, send instructions
↓
Days 2–4 — core feature testing: onboarding, auth, main flows
↓
Days 5–7 — bug discovery and first feedback review
↓
Days 8–10 — fixes shipped, affected areas retested
↓
Days 11–13 — regression pass and final feedback
↓
Day 14+ — final review and production-access preparation
Master tracking table
If you only copy one thing from this article into a spreadsheet, copy this. The two rows below are a filled example, not real data.
| Date | Testers | Build | Features | Issues | Feedback | Action | Status |
|---|---|---|---|---|---|---|---|
| Day 1 | 12 | 1.0.0 | Signup, onboarding | Crash on signup (Android 12) | "It closed when I signed up" | Logged; fix started | Open |
| Day 6 | 13 | 1.0.1 | Signup, search | Search returns empty state | "I could not tell if it found nothing" | Added empty-state copy | Retested |
What to track every day
A five-minute daily pass — practical guidance, not a Google requirement, but the difference between a summarisable test and a fortnight you cannot describe.
- ☐ Current tester / opt-in status
- ☐ Current build or version under test
- ☐ Which features were tested
- ☐ Important issues discovered
- ☐ Feedback received
- ☐ Reproduction steps where relevant
- ☐ Device and OS detail for anything device-specific
- ☐ Whether a fix is needed now or can wait
- ☐ Whether a new build should go to testers
On privacy: record which tester reported something where it helps you follow up, but keep personal information out of the log. You do not need names, phone numbers or email addresses to write a good testing record — an identifier like "Tester 4" is enough, and storing less is safer.
What to track each week
A weekly pass widens the lens from "what happened today" to "where is this test going". Recommended workflow, not an official quota.
| Week | Review |
|---|---|
| Week 1 | Tester participation and whether anyone has gone quiet · major bugs and crashes · usability problems · which features have actually been covered · the first feedback themes |
| Week 2 | Regression testing of everything you changed · whether fixes actually resolved the reports · the updated build and who installed it · unresolved issues you are consciously accepting · production readiness · remaining risks |
Week 1 tends to be about discovery; week 2 is about verification. If you enter day 8 without a written list of open issues, the second week becomes guesswork.
Tester count and opt-in status
The requirement is about one number, and it is worth tracking it against the states people confuse it with:
- Invited / added — the address is on your tester list. This is capacity. Google counts nothing yet.
- Opted in — the tester completed the opt-in with the invited account. This is the number the requirement is written about, and the one to log daily.
- Testing — they installed and are using the app. Track this yourself; it is what produces the feedback.
- Feedback — what they reported. Not a Play Console counter, but the material your application is built from.
Log three things daily: the opted-in count, any change to it, and the date each replacement joined. Google's FAQ explains why that date matters: testers who opt in, test fewer than 14 days and then opt out do not count, and opting back in restarts their 14 consecutive days.
Keep the practical risks visible in the same log: whether the count has stayed at or above the minimum, whether anyone has left, and whether a replacement is needed. A buffer above 12 is practical risk management, not a Google requirement. Retention tactics are covered in keeping 12 testers opted in for 14 days, and what breaks the window in what resets or breaks your testing period.
Track every build you test
Builds are the spine of a 14-day test. Without a version against each entry, you cannot tell whether a bug was fixed before or after it was reported — or whether the complaining tester was even on the new build.
Record these fields per build:
- Build version — the version code or name testers are running
- Release date — when it went to the track
- Main changes — what actually changed
- Features affected — what needs retesting as a result
- Known issues — what you shipped anyway, and why
- Feedback received — what testers said about this build
- Fixes after feedback — what changes made it into the next one
A worked example of how a fortnight can look — illustrative only:
| Build | What it was | What it contained |
|---|---|---|
| 1.0.0 | Initial test build | Baseline for login and onboarding |
| 1.0.1 | Fix release | Fixed a login crash; clearer onboarding |
| 1.0.2 | Fix release | Payment flow improvements; a layout issue |
Worth knowing: Google states that once testers install, their app automatically updates to the test version within a few minutes — so a "still broken" report may simply predate the update. Your build column is how you tell.
Features tested
Coverage is the part of a closed test that rarely gets tracked, and it answers Google's question about whether testers used your available features. Google's guidance is to encourage testers to use as many features as possible to provide holistic feedback.
Start from your own app rather than a generic list. A coverage checklist that often applies:
☐ Authentication
☐ Onboarding
☐ Home screen
☐ Navigation
☐ Core feature(s)
☐ Search
☐ Notifications
☐ Payments / subscriptions
☐ Settings
☐ Profile
☐ Logout
☐ Offline behaviour
☐ Error states
Adapt it. Not every app has payments, notifications or accounts, and a feature you do not have is not a gap. The point of the checklist is to spot the areas that got no attention at all — the settings screen nobody opened, or the offline path nobody tried.
Bugs and issues
Keep a register separate from the daily log, so a single bug is described once and referenced from wherever it came up.
| Field | Example entry |
|---|---|
| Issue | Signup closes the app |
| Device / Android | Pixel-class device, Android 12 |
| Build | 1.0.0 |
| Steps to reproduce | Open app → tap Sign up → enter a password under 8 characters → submit |
| Expected / actual | Expected a validation message; the app closed instead |
| Severity / status | High · fixed |
| Fix version / retested | 1.0.1 · retested by the same tester |
Why this beats "the app doesn't work". A report with steps, a build and a device is something you can act on, verify, and describe later. A report without them is a feeling — and it is very hard to summarise honestly on a production-access form. If you need help getting good reports out of testers in the first place, the questioning techniques in what to record during your 14-day test are worth reading before this section is.
Tester feedback
Google's guidance is to provide a clear feedback channel (email, a website or a messaging forum), to say what kind of feedback you want, and to maintain a record of received feedback so recurring themes stand out. Testers can also leave private feedback through Google Play, which appears on the Testing feedback page in Play Console (Monitor and improve > Ratings and reviews > Testing feedback).
How to log it so it stays useful:
- Keep the tester's own words for anything you might quote later, then add your own summary line.
- Tag each item with the build it relates to and the feature area — that is what makes themes visible at the end.
- Record the outcome, even when the outcome is "not an issue" or "deferred". A decision you made is part of the record.
- Check your channels once a day rather than letting three days of messages pile up unread.
Do not invent a required volume of feedback. Google asks you to collect, review and summarise it; it publishes no minimum count of reports or bugs.
Feedback → fix flow
Individual reports are noise until you group them. The habit that pays off is a short four-beat loop, repeated for every meaningful piece of feedback:
Feedback → Decision → Change → Retest
and then record what you verified
Grouped examples — illustrative, not real user quotes:
| Theme | What testers said | Action |
|---|---|---|
| Onboarding | Unsure what to do after signing up | Added clearer next-step guidance |
| Performance | A screen took too long to load | Optimised the load path |
| Navigation | Could not find Settings easily | Updated the navigation structure |
Three feedback items became three themes and three decisions. That is a summarisable test — and notice that a single theme can carry several reports, which is exactly what Google's advice to watch for "recurring themes" is pointing at.
Changes made from feedback
This is the record that turns a fortnight of testing into an application answer. For every meaningful change, capture four things:
What testers reported ↓ what you changed ↓ which build contains it ↓ whether it was retested
The production-access form asks what you changed based on what the closed test taught you, and Google's guidance is to respond to feedback and resolve identified bugs during the testing period. A four-column record answers that question directly, months later, without reconstruction.
| Reported | Change | Build | Retested |
|---|---|---|---|
| Signup crash on Android 12 | Fixed a null check in the signup handler | 1.0.1 | Yes — reporter confirmed |
| Onboarding unclear | Added next-step guidance on first run | 1.0.1 | Yes — two testers |
Two honest notes about this record. First, "we decided not to change this" is a legitimate outcome worth writing down, especially with the reason. Second, a change you never retested is not verified — say so in the record rather than implying it was.
Pre-launch report
The pre-launch report is the automated half of your testing evidence, and it runs whether or not you are watching for it. Google states that pre-launch reports are generated automatically when you upload an app bundle or APK, or when you save a release to production, subject to device-lab capacity, and that they include tests for (Play Console Help):
- Stability issues
- Android compatibility issues
- Performance issues
- Accessibility issues
Mechanically, Google installs your build on a set of Android devices in its test lab, launches it, and crawls it for several minutes — typing, tapping and swiping. When the report is ready you get a summary showing the number of errors, warnings and minor issues by type, plus a launch recommendation. You can also customise it: provide test account credentials if your app has a sign-in screen (use a test account, never real credentials), supply a Robo script or game loop, add up to three deep links as extra entry points, and view results for up to five languages.
Two practical limits: test devices cannot test apps without a main launch activity — launchers, widgets, keyboards and watch faces are excluded. And credentials are for testing only, so keep a dedicated test account.
Review it during the test, not after it. Treat it as a second opinion alongside your testers: it finds crash, compatibility, performance and accessibility issues that human testers may never hit, but it cannot tell you whether your onboarding makes sense or whether anyone would want the app. It is a complement to the closed test, not a replacement for it — and reviewing it before you apply is a sensible part of readiness.
Day 14 final review
Before you apply, sit down with your record and confirm each of these. Practical checklist — completing it makes you eligible to apply, it does not guarantee approval.
- ☐ Required tester count satisfied — 12 or more opted in
- ☐ Required opt-in period satisfied — continuously for the preceding 14 days
- ☐ Important features genuinely tested and covered
- ☐ Major bugs reviewed, with severity and status recorded
- ☐ Tester feedback reviewed and grouped into themes
- ☐ Changes made where appropriate, with the build that contains them
- ☐ Latest build tested, including a regression pass on what you changed
- ☐ Pre-launch report reviewed, with significant issues addressed or consciously accepted
- ☐ Production readiness assessed honestly
- ☐ Production-access answers drafted from your actual records
Production access preparation
Once at least 12 testers have been opted in continuously for the preceding 14 days, you can apply from the Dashboard in Play Console. The form has three sections — About your closed test, About your app/game and About your production readiness — and the questions map almost one-to-one onto the record you have been keeping:
| Google asks about | Which part of your record answers it |
|---|---|
| Tester recruitment | Your tester list notes — where the testers came from and which account each used |
| Tester engagement and feature use | Your feature coverage checklist and daily log |
| Whether usage matched expected production behaviour | Your observations on how testers used the app versus your intended audience |
| Feedback and how you collected it | Your feedback log, theme groupings and the channel you used |
| Changes made from testing | Your reported → change → build → retested table |
| Target audience and app value | Your reasons for choosing the testers you did, and the problem the app solves |
| Production readiness | Your day-14 review, open-issue list and pre-launch report review |
Google emails the account owner when the review completes, and its published guidance is that review usually takes seven days or less, but can occasionally take longer. Meeting the requirement makes you eligible to apply — it does not guarantee approval, and Google documents two reasons it may ask you to keep testing: fewer than 12 opted-in testers, or insufficient tester engagement during the testing period. Full walkthrough: how to answer the closed testing questionnaire. If it is refused, why production access is still refused after 14 days covers recovery.
Do not reconstruct your testing history at the end
This is the single habit that decides whether the rest of this article helps you.
The workflow that fails
Day 1–14: test and react.
Nothing written down.
Day 14: try to remember what testers said, which build fixed what, and why you changed the onboarding.
The workflow that works
Day 1: start the record.
Daily: add one line for builds, issues and feedback.
After each meaningful item: record the action.
After each build: record what changed.
Day 14: summarise what already exists.
The failure mode is timing, not laziness. Two weeks is plenty of time to forget the wording of a complaint, which build a tester was on, or whether you verified a fix. Reconstructing that later produces a summary that is vague exactly where Google wants specifics.
The second-order benefit is motivation. A running record makes progress visible: you can see coverage widening, open issues falling, and the build number climbing. That is far easier to keep going than a mental tally.
14-day checklist
The whole article on one screen. Recommended workflow, not a set of Google requirements.
Before day 1
- ☐ Opt-in link ready, app status is Published, testers confirmed opted in
- ☐ Testing instructions and one feedback channel prepared
- ☐ Record started: record table, bug register and feature checklist created
During the test
- ☐ Daily: opted-in count, build, features, issues, feedback, action
- ☐ Weekly: participation, themes, fixes shipped, open issues
- ☐ Every build: version, changes, affected features, known issues
- ☐ Every fix: which build carries it, and whether it was retested
Before applying
- ☐ 12+ testers opted in continuously for the preceding 14 days
- ☐ Feedback summarised by theme; changes and retests documented
- ☐ Pre-launch report reviewed; production-access answers drafted
Frequently asked questions
What should I track during Google Play closed testing?
A daily record of the opted-in tester count, the build under test, the features covered, issues found, feedback received and the action you took — plus a separate bug register and a feature coverage checklist.
Do I need to keep a testing log?
Google does not require a specific tool or template. It does tell developers to maintain a record of received feedback and requires you to summarise your testing feedback when applying — so a log is the practical way to satisfy that.
What should I record about tester feedback?
The tester's own words, the build and feature area it relates to, and the outcome — fixed, deferred, or not an issue. Keeping the original wording makes the final summary far easier to write.
Should I track every app build?
Yes, if you ship more than one. Without a version against each entry you cannot tell whether a report predates a fix — Google notes that an installed app updates to the test version within a few minutes, so timing matters.
What should testers test during the 14 days?
As many of your real features and flows as possible. Google's guidance is to encourage testers to use as many features as possible to provide holistic feedback. Track coverage against your own feature list rather than a generic one.
What should I check before applying for production access?
At least 12 testers opted in continuously for the preceding 14 days; features covered; issues reviewed; feedback summarised by theme; changes documented with their build; the pre-launch report reviewed; and honest readiness answers.
Does Google require daily tester activity?
No. Google publishes no daily open, minutes or session requirement. It does name insufficient tester engagement as a reason it may require continued testing, so genuine use matters. More on that question.
Should I keep screenshots of my testing progress?
Screenshots are useful for your own reference — especially for visual bugs and pre/post comparisons — but Google does not ask you to submit them with the application. Write the record so it makes sense without them.
What should I do if testers find bugs?
Record it with steps, device, Android version and build; assess severity; fix what matters; ship it; and ask the reporting tester to retest. Then note the outcome — Google's guidance is to respond to feedback and resolve identified bugs during the testing period.
Does completing the 14-day test guarantee production access?
No. Completing the requirement makes you eligible to apply; Google reviews the application and decides. It may ask you to continue testing, for example if you have fewer than 12 opted-in testers or insufficient tester engagement.
Final checklist
If you take one thing from this page: start the record on day 1 and add one line a day. The bug register, the coverage checklist, the pre-launch review and your application answers are all downstream of that habit.
- ☐ One record, started on day 1 and updated daily
- ☐ Build versions logged, so every report has a version behind it
- ☐ Feature coverage tracked against your app's real features
- ☐ Feedback grouped into themes, not left as a pile of messages
- ☐ Changes documented with the build that carries them, and retested
- ☐ Pre-launch report reviewed before you apply
- ☐ Answers drafted from the record — not from memory
About this guide. 12 Testers Community organises Google Play closed testing for indie Android developers. This article reflects that workflow and Google's published documentation; it is not affiliated with Google, and nothing here guarantees a production-access decision.
Wider reading: the complete 14-day guide for 12 testers, how long closed testing takes, and — if your count is the problem rather than your records — 10 reasons your closed test is stuck. Looking for testers in the first place? 7 legit ways to get 12 testers.
Need help organising your Google Play closed test?
12 Testers Community runs managed closed testing for Android developers — real testers on real Android devices, structured testing instructions, tester coordination and feedback support, so you get the coverage and the written record you need instead of a fortnight you cannot describe.
Start your closed test or read the plans and pricing first. We do not promise Google approval — no one can.
