Android Bug Report Template for Closed Testing (12 Testers)

A bug report is reproducible when a stranger holding it can make the same failure happen on a comparable device without asking you a single question. For a 12-tester closed test that comes down to ten fields, a numbered starting state, one issue per report, and a rule for who triages it and when.

The template below is the version we run on campaigns. It covers the fields to require, a worked example, the 48-hour hand-off rule, and the part most guides skip: three of the eight questions on Google's production access form are answered from material your reports already contain. If your reports do not carry that material, you will be reconstructing it from memory on day 14.

What makes an Android bug report reproducible?

A report is reproducible when someone else, on a comparable device, can make the same thing happen by following the text alone. That is the whole test. It says nothing about whether the tester understood the cause, because the cause is your job. The report's job is to get you to a screen you can watch.

Google's own bug trackers set the same bar and are explicit about the cost of missing it. Android Studio's bug-reporting guide says: "bugs that have complete information are prioritized. Incomplete bug reports are closed." The Android Open Source Project guide is blunter: "A comment that only states something isn't working is likely to require further information."

Both of those are rules for Google's issue trackers, not for Play Console. That distinction is worth keeping straight, because nothing in Google's closed-testing requirements specifies a report format at all. What Google does publish is an instruction to you: its testing best practices tell developers to "Provide beta testers with clear instructions on how to test your app and report bugs. Specify the type of feedback you want to collect." A template is the cheapest way to obey that sentence, and it is the only part of this article Google actually requires.

The hand-off loop: who triages, and when

Most failed campaigns do not fail on report quality. They fail because nobody owned the reports. Three testers message you on WhatsApp, one emails, two post in the Google Group, and by day 9 you cannot tell which of them you already replied to. The fix is a loop with one owner and a clock, and the clock is the important part.

Two rules make the loop work. First, one triage owner. On a 12-tester test that should be you, not a shared inbox, because the value of the loop is that a single person knows what has already been answered. Second, the 48-hour rule is about state, not about a fix. Within 48 hours every report should be in one of four states, and the tester should be able to see which.

The retest rule is the part campaign managers get wrong. A tester who reported something should be the person who confirms it is fixed, and they need a build with a higher versionCode than the one they reported on. Sending a fix and never asking the reporter to check it leaves you with a closed ticket and no evidence, which is exactly the material Part 3 of the production access form asks about.

The template: ten fields

Ten fields is more than a paid tester will volunteer and fewer than you probably think you need. Ask for the first six and fill the rest in yourself from Play Console, which is covered further down. Every example below is illustrative, written for a placeholder app.

Field 3 deserves one note. Android's build fingerprint identifies the exact software build on the device, not just the model, which is why Google's own security reporting guidance asks for it via adb shell getprop ro.build.fingerprint. Most paid testers will not run an adb command, and that is fine. Ask for it from the two or three testers who report the majority of your issues, and let the rest send a screenshot of Settings, About phone.

A worked example, end to end

Here is the same report after triage, as it would sit in your log. It is illustrative, not a real user's report, but the shape is what matters: a tester wrote six lines, and everything else was added by the person who owned the test.

Read that back as a developer writing a production access application and the value is obvious. The tester's original three sentences would have produced "testers reported upload issues and we fixed them". The completed record produces a named build, a cause, a screenshot, and a tester who confirmed the fix. One is a sentence a reviewer has read a thousand times. The other is evidence.

How three report fields answer three form questions

This is where a bug report stops being housekeeping. Google's production access application asks eight questions in three sections, and three of them take their evidence straight from this log. Google describes the form as the place where you "answer questions to help clarify your app design, testing process, and production readiness".

The engagement question is the one worth preparing for, because it is the documented pivot. Google's page names exactly two reasons an application is sent back for more testing: "having fewer than 12 opted-in testers or insufficient tester engagement during the testing period." The first is a number Play Console already has. The second is a judgement about whether anything happened, and a report log is the only artefact that shows it did.

None of this decides the outcome. Google reviews the application separately and can still ask you to keep testing, and no report format changes that. What the log does is make the honest answer available to you on the day you fill the form, instead of leaving you to summarise a fortnight from memory. Our fuller breakdown of the eight questions is in what to write on the production access form.

What does not belong in a bug report

Half of the triage work on a paid campaign is subtraction. Based on our analysis of 1,500+ closed-testing campaigns, the reports that stall are rarely the complicated ones; they are the ones carrying three subjects and no observation. These are the five that arrive most often, and where each one belongs instead.

When testers will not fill in ten fields

They will not. A tester who was matched to your app 11 days ago and is being paid to be opted in has no reason to produce a disciplined report, and asking for ten fields is a good way to receive nothing at all. The workable answer is a two-tier report: ask the tester for four things, and complete the rest yourself.

What you ask for is a sentence of what they were doing, what they expected, what happened, and a screen recording if they can. That is it. Build, device, date and channel come from Play Console and from the message itself; the triage fields come from you reproducing it. If you have an in-app feedback form, attach the build and device automatically and ask for two fields, because tester effort is the scarce resource in a paid test, not your triage time.

The same principle applies to a report that says the app will not install. That is usually not a defect in the app, and the cause is often a release that was approved but never reached the testers. Approved but testers cannot install covers that path, and testers see app not available covers the opt-in side of it. Neither is fixed by a better bug template, and recognising them quickly is what keeps the log clean.

Keep one row per report, for the whole window

The log itself can be a spreadsheet with six columns: date, tester, build, title, state, change shipped. One row per report, updated when the state changes, never rewritten. Fourteen days of that produces a document you can read in ten minutes and answer three form questions from, and it is the difference between describing a test and describing a calendar.

Two other habits belong in the same file. Note which features no report ever mentions, because that is the coverage gap you will want to name honestly in the engagement answer. And note the builds you shipped, with dates, because "we updated twice during the window" is a sentence a reviewer can check against your release history.

Duplicates deserve a row each, not a merge. Two testers hitting the same defect is not noise in a closed test; it is the clearest evidence you will ever have that testers used the app on their own and reached the same screen. Link the rows so triage treats them as one fix, but keep both in the counts, because the engagement answer asks how many testers were active, not how many distinct bugs existed.

If the window ends without approval, the same log is what you apply with the second time. Production access rejected after 12 testers covers what to change before a second attempt, and what counts as a closed tester explains why the count in Play Console can be lower than the number of people you invited, which is the other thing worth checking before you reapply.

Frequently asked questions

Does Google require a specific bug report format for closed testing?

No. Google's closed-testing requirement is 12 testers opted in continuously for at least 14 days, and its documentation does not specify how feedback must be recorded. What Google does tell developers is to "Provide beta testers with clear instructions on how to test your app and report bugs. Specify the type of feedback you want to collect." A template is one way to do that, not a Play Console rule.

How many fields should a bug report have?

Enough to reproduce it and no more. Ten fields cover a full record; six are the practical minimum a tester can be asked for without a drop in response rate. Build, device, steps, expected, actual and evidence do most of the work, and the remaining four can be completed during triage.

Do bug reports affect whether production access is approved?

Not directly, and no report format guarantees approval. Google's documented test is 12 opted-in testers plus engagement during the period, and review of the application is separate. Reports matter because two of the eight application questions ask you to summarise the feedback you received and the changes you made because of it.

What is a build fingerprint and how does a tester get it?

It is the identifier for the exact software build installed on a device, not just the model. Google's security reporting guidance asks for it with adb shell getprop ro.build.fingerprint. For most closed tests the versionCode plus the device model is enough, so ask for the fingerprint only from testers who can run adb.

Should testers send logcat with every report?

No. A screen recording is worth more for a layout or flow problem, and a stack trace is worth more for a crash. Attaching logcat to everything buries the one useful line, and most paid testers cannot capture it without instructions you would have to write and support.

How long should a tester wait for a response?

Our rule on campaigns is a state change within 48 hours, not a fix. The tester should learn that their report was reproduced, needs one more detail, or could not be reproduced, and that answer should come from one named person. Silence is what turns a tester into a row of zero activity on day 12.

What if a reported bug will not reproduce?

Record it as cannot reproduce, with what you tried and on which device, and ask the reporter for a screen recording. Do not close it silently and do not count it as fixed. A cannot-reproduce entry is honest evidence that you investigated, which is worth more in a feedback summary than a tidy list of resolved tickets.

Can the same template be used for a second test cycle?

Yes, and it should be, with the build field reset. The log from the first window is the starting point for the second, and the reports that were closed as by design in the first cycle are the ones most likely to reappear with a different tester.

Sources

• App testing requirements for new personal developer accounts - Play Console Help. The primary source for the twelve-tester and fourteen-day requirement, the instruction to give testers clear reporting instructions, the wording of the application questions quoted above, and the two documented reasons an application is sent back for more testing. Accessed 2 November 2026.
• Report a bug - Android Studio, Android Developers. Google's own bug-report structure: steps to reproduce, expected and observed outcome, a descriptive title, and the statement that incomplete reports are closed. Guidance for Google's issue tracker, not a Play Console requirement. Accessed 2 November 2026.
• Report and track bugs - Android Open Source Project. The AOSP position that a comment only stating something is not working will require further information, and what makes a report adequate for triage. Accessed 2 November 2026.
• How to submit a complete bug report applicable to Android platform - Google Bug Hunters. Source for the build fingerprint command and what Google treats as a complete report. Accessed 2 November 2026.
• View logs with Logcat - Android Developers. What a log entry contains and how crashes surface in a stack trace, which is why logcat is worth asking for only on crashes. Accessed 2 November 2026.
• Set up an open, closed, or internal test - Play Console Help. How a closed test and its tester list are configured, which is where the build and device fields in a completed report come from. Accessed 2 November 2026.