Production Access Questions: How to Answer

Google's production access questionnaire is organized around three areas once your closed test clears the 12-tester/14-day bar: what happened during your closed test, information about your app itself, and why you believe the app is ready for production. The three sections below follow that order, so you can work through the form top to bottom. Two of the most important questions in the whole form sit in the first section — what you tested, and what you did with the feedback you got.

1. About your closed test

This section is about tester engagement and the feedback you received — not just the count and duration. Google's own documentation lists having fewer than 12 opted-in testers, or insufficient tester engagement, among the reasons it may require more testing after reviewing an application — so reaching the form does not put the tester requirement behind you.

"What did you test?" is answered badly with "everything" and answered well by naming the actual features testers used — the sign-in flow, the core screens, a purchase flow if your app has one — grounded in what really happened during your test.

"What feedback did you act on?" is answered badly by inventing engagement that didn't happen, and answered well either by referencing specific, real issues from your test report and confirming they were fixed, or by saying plainly that no critical issues were found — a clean test is a legitimate, honest answer. Vague answers to either question read as low-engagement testing to a reviewer, even when the raw opt-in count and day count were both fine.

2. About your app

This section typically covers what the app does, who it's for, and what value it provides. It's the most straightforward of the three to answer accurately, because it's about the product rather than the test — your own store listing and app description are the source material, and the answer should match them rather than describing a more ambitious app than the one you're submitting.

3. Why your app is ready for production

This section asks you to justify, in your own words, why the app is ready to go live — what changed since you started testing, and why you believe it's ready now. This is where referencing a specific fix made in response to real tester feedback (rather than a generic "the app works well" statement) does the most work. A bare assertion that the app functions doesn't answer the question actually being asked, which is why *now*.

Where your answers come from

Testers14 customers get the two closed-test answers generated automatically from their own order's real data — actual tester devices, countries, and logged bug reports — right on their dashboard once the required 14 days are complete, so there's real evidence to start from instead of a blank template. The app and production-readiness sections are yours to write: they're about your product and your judgment, and nobody else's data can supply them.

What an actual closed-test report can contain

To make "grounded in what really happened" concrete rather than abstract, here's what a real closed-test report actually captures — the same categories shown on our live sample dashboard, not a hypothetical list. To be clear: Google does not require a report in this exact form, and having one does not guarantee approval — it's the raw material you'd use to write your own honest answers to Google's actual questionnaire.

Device and country coverage names the actual hardware and locations testers used — not "various Android devices," but specific models across specific countries. Standard checks record which parts of the app were deliberately exercised on every device: install and first launch, rotation, dark mode, small-screen layout, offline behaviour, back-navigation. Bug reports carry a severity rating and a verified flag, so a reviewer (or you, writing your own answer) can distinguish a confirmed high-severity crash from a minor, unverified cosmetic note. Tester suggestions capture feedback that isn't a "bug" exactly, but is still real product input — a specific screen that confused someone, a wait with no loading indicator. A product-perspective note explains, in plain language, what the app's core value is and which flows the test deliberately weighted because of it — the kind of reasoning a production-readiness answer benefits from directly.