In this article

For applicable new personal Google Play accounts, meeting the closed-test minimum allows you to apply for production access; it does not guarantee approval. Organize a real test and retain the evidence needed to explain what you learned, rather than treating testers as a counter to purchase.

Google's current guidance applies to personal developer accounts created after November 13, 2023. It requires at least 12 testers continuously opted in for the preceding 14 days when applying. Verify your account's applicability and current dashboard state in the official testing requirements, checked October 8, 2026.

Separate eligibility from useful testing#

Opt-in continuity answers an eligibility question. It does not demonstrate that someone could sign in, complete the main task or recover from an error. Google asks about engagement, feedback and readiness in the production-access application.

Do not invent a mandatory daily launch count, a minimum session length or a guaranteed approval script. The cited policy does not provide those universal quotas. Your test activities should match your application's real risk and intended audience.

Before recruitment, make sure the build is installable and the core path works with safe test data. Twelve people blocked at the same broken login screen produce little useful evidence about the rest of the product.

Give each tester a meaningful task#

For a hypothetical expense app, tasks might be:

  • Create an account and add a sample expense.
  • Correct an entry without duplicating it.
  • Read the total and explain what period it represents.
  • Recover after a network interruption.
  • Export synthetic data and check the result.

These are examples, not tasks prescribed by Google. A game, fitness app or enterprise tool needs a different test sheet.

Ask testers to report the build version, device, action, expected result and observed result. Provide a private feedback channel. Do not ask them to send real financial records or other sensitive information just to reproduce a test case.

Keep an evidence log you can summarize honestly#

Use a simple record:

text
Build and date:
Task tested:
Feedback or defect:
Impact on intended users:
Change made:
Retest result:
Unresolved limitation:

Link a reported issue to the change and its retest. A vague statement that “all testers liked it” is less useful than a concrete account of the onboarding defect found and corrected.

Monitor continuity in the Console. Google's FAQ explains that opting out and back in does not preserve an uninterrupted qualifying period. Do not substitute a recruitment spreadsheet for the provider's eligibility status.

Apply when you can defend readiness#

Describe your audience, main value, how testers used the app, how feedback was collected and what changed. Answer from records. Do not paste another developer's narrative or fabricate engagement.

If important defects remain, continue testing rather than using a production submission as free quality assurance. If Google requests more testing, compare the explanation with your continuity and engagement evidence, correct the identified gaps, and keep truthful records of the additional work.

Preserve the build-to-feedback connection#

Test results are easier to trust when the tested artifact is identifiable. Keep the version code and release record alongside the feedback log. A later rebuild may contain different dependencies or settings even if the screen looks identical.

If you use AI to summarize the log, verify each claimed fix and observation against the original entries. Our guide to checking AI answers explains why fluent summaries can still invent evidence. The summary should shorten your records, not manufacture them.