Google Play Production Access Questionnaire: How to Answer Every Question

After completing 14 days of closed testing with 12 or more testers, you apply for production access through Google Play Console. The application includes a questionnaire that many developers treat as a formality and many reviewers treat as the deciding factor in approval decisions. Here is exactly how to answer it.

Why the Questionnaire Matters So Much

Google's production access review is conducted by human reviewers, not just automated systems. The questionnaire is your opportunity to demonstrate that real testing happened and that you took the results seriously.

Applications with generic one-sentence answers are rejected at a significantly higher rate than applications with specific, detailed answers. In 2026, with Google's increased focus on app quality, the questionnaire has become more important than ever.

Before You Start: Documentation You Need

The questionnaire asks about specific things that happened during your testing period. Before you open the application, gather the following:

Your release history showing every update you pushed during the 14 days with dates and descriptions of what changed.

Feedback you received from testers, whether through a testing service dashboard, email, direct messages, or bug reports.

Specific bugs or issues that were identified during testing.

Specific improvements or fixes you made in response to tester feedback.

If you used TestSlot, your dashboard shows individual tester activity, any bug reports submitted through the platform, and day-by-day participation records - exactly the documentation you need.

The Questions and How to Answer Them

The questionnaire structure changes periodically but consistently covers these areas:

What type of testing did you conduct?

Be specific. Do not just say closed testing. Explain that you conducted a 14-day closed testing period with 12 verified real-device testers who participated through the official Google Play closed testing mechanism.

What feedback did you receive from testers?

This is the most important answer. Be specific and honest. Reference real feedback.

Bad answer: Testers found the app to be good and working correctly.

Good answer: Testers reported that the app loading time on the home screen was slow on older devices running Android 9 and 10. One tester noted that the settings menu was not accessible via the back button. Two testers reported confusion about the onboarding flow on smaller screen sizes.

What changes did you make based on tester feedback?

Directly reference the feedback you just described and explain what you changed.

Bad answer: We improved the app based on feedback received.

Good answer: In response to loading time feedback, we optimized our image loading library and reduced initial load time by approximately 40% on Android 9 and 10 devices (v1.0.2, released on day 5 of testing). We fixed the back button navigation issue in the settings menu (v1.0.3, released on day 9). We redesigned the onboarding flow with larger tap targets and clearer instructions for small screen devices (v1.0.4, released on day 12).

How many testers participated in your testing?

State the number clearly. Include that they were on real physical Android devices if applicable.

What was the duration of your testing period?

State 14 days clearly with dates.

Describe your app's purpose and target audience.

Be clear and honest. This is a policy check as much as a testing question. Make sure your description matches what your app actually does.

The Formula That Gets Approved

The formula is simple: specificity plus honesty plus evidence of iteration.

Specificity means naming real issues with real details - not app was slow but home screen loaded in 4 seconds on Android 9, below our 2-second target.

Honesty means describing real problems - do not pretend testers found nothing. An app with zero issues found during testing is a red flag that testing was superficial.

Evidence of iteration means showing that you responded to what testers found with real code changes. Multiple updates during the testing period with specific release notes demonstrate a genuine development loop.

What Happens If Your Application Is Rejected

If Google rejects your production access application, they provide a reason. Common reasons include insufficient evidence of testing engagement, policy violations in the app itself, or incomplete information in the questionnaire.

Read the rejection reason carefully. Address the specific issue. If the rejection mentions testing engagement, review your tester participation records and ensure your next application demonstrates that testers were actively using the app, not just installed.

You can reapply after addressing the rejection reason. The 14-day testing period does not need to be repeated unless the rejection specifically states the testing was insufficient.

Build your questionnaire answers on real data from TestSlot's dashboard at testslot.io.