What to record during closed testing
closed testing log · feedback summary · tester engagement · production readiness questionnaire
What you typically see
- When you apply for production access, Play Console asks structured questions about your closed test, the app, and readiness (O1).
- Without dated notes, answering “whether testers used all features,” “how feedback was collected,” or “what changed after testing” becomes guesswork.
- O1 also recommends keeping a record of received feedback and summarizing it on the application.
What public docs say
Fields below are derived from O1’s application questions and best-practice guidance — not invented metrics.
From About your closed test (O1)
- How easy it was to recruit testers
- Whether testers used all available app features
- Whether tester usage matched expected production user behavior, including differences
- A summary of feedback and how feedback was collected
From About your production readiness (O1)
- Changes made based on closed-test learnings
- How you determined the app/game is ready for production
From O1 best practices / FAQ
- Clear test instructions and a clear feedback channel
- Diverse testers; remind them to stay opted in for 14 continuous days
- Review feedback regularly; tip: maintain a record of received feedback
- Act on feedback (bugs and UX) before production
- If authentication is required, provide valid working credentials for reviewers
What to fix (fields to capture)
Use any spreadsheet or note doc. Capture at least:
Headcount & continuity
- Closed-test start date
- Target apply date (after 14 continuous days with ≥12 opted in)
- Daily or weekly snapshot: opted-in count
- Names/IDs of testers who opted out early (their days do not count per O1 FAQ)
Instructions & access
- Link or text of test instructions given to testers
- Feedback channel(s): email / site / messaging / Play testing feedback
- Reviewer / test login credentials stored in Console (if auth required)
Engagement (maps to form)
- Features covered vs not covered
- Whether usage looked like expected production behavior (and what differed)
- Devices / OS versions exercised (optional but useful for your own notes)
Feedback ledger
- Date · tester · channel · quote or paraphrase · theme · status (open / fixed / won’t fix)
- Recurring themes rolled up for the feedback summary answer
Changes & readiness
- Build/version shipped during closed test
- List of changes made from testing
- One-paragraph “why ready for production” draft for the form