Most developers know what the production access form asks, but not what a good answer looks like. This guide shows invented examples for five kinds of app. Use them to see the level of detail, and then write your own: your answers should describe your app and your test. Copying someone else's text is one of the mistakes we warn about in the questionnaire guide. The questions come from Google's testing requirements, which says the form has three parts. This guide covers parts 1 and 3.

The pattern behind a good answer

A good answer has three things: a specific fact (a feature, a number, a device), what you did about it, and an honest limit (what was not tested). Compare:

• Weak: "Testers liked the app and found no problems."
• Strong: "Testers used the scanner and the history screen daily. Two reported that the flash button was hard to find, so we moved it. Nobody tested the export feature."

1. A utility app (a fictional QR scanner)

Tester engagement: "Testers used scanning and history every day. The settings and export screens were tried by about half of them. Real users will scan in many lighting conditions, which our testers covered less."

Feedback received: "Collected through a messaging group and private feedback in Google Play. Main themes: the flash button was hard to find, scanning was slow in dim light, history had no search."

What we changed: "Moved the flash button to the main screen, improved the dim-light focus, and added search to history."

How we decided it was ready: "No crashes in the last build across four devices, and the three main issues were fixed and re-tested."

2. A game (a fictional puzzle game)

Tester engagement: "Testers played every day for two weeks. Most reached level 15, a few reached level 30. The shop was opened by few."

Feedback received: "Daily notes in a group chat. Themes: level 12 was too hard, the tutorial was too fast, sound effects were too loud."

What we changed: "Made level 12 easier, slowed the tutorial, and added a volume slider."

3. A finance app (a fictional budget tracker)

Tester engagement: "Testers added expenses and reviewed charts. Real users may enter hundreds of items, which we did not test. Nobody connected a real bank account, because the app does not offer that."

Feedback received: "Written notes through a form. Themes: category names were unclear, the monthly chart rounded numbers confusingly."

What we changed: "Renamed three categories and showed exact amounts on the chart."

4. An AI app (a fictional photo caption helper)

Tester engagement: "Testers tried captions on many photos. Results differed across photos. We asked testers to report any caption that was wrong or inappropriate."

Feedback received: "Most reports were about slow captions on weak networks and a few wrong captions."

What we changed: "Added a loading indicator, a retry button, and a way to report a bad caption."

5. A learning app (a fictional flashcard app)

Tester engagement: "Testers made decks, studied daily and used the reminders. The sharing feature was not tested because it needs two accounts."

Feedback received: "Notes through a messaging group. Themes: the reminder time could not be changed, card flipping felt slow."

What we changed: "Added a reminder time setting and sped up the flip animation."

Part 3: "How did you decide it was ready?"

Whatever your app, say what you checked and what you accepted. For example: "We fixed every crash and the three main usability issues. We know of two minor display problems on small screens, and plan to fix them in the first update." Honest limits make an answer more believable.

Before you write

Keep your feedback record open and copy facts from it. The examples above are fiction, and your answers must be true. Check your list against the production access checklist.

ClosedTest is an independent service and is not affiliated with Google.