“It crashed” is a starting point, not a complete report. A small reporting template saves time because the developer can reconstruct what happened without a long exchange of messages.

Use this private report template

Build or version tested.
Device model and Android version.
Preconditions, such as signed-in state or an existing sample record.
Numbered actions leading to the issue.
Expected result and actual result.
Frequency, including whether a second attempt reproduces it.
Screenshot or short recording with personal information removed.

This is a suggested working template, not a Google approval form.

Make the report concrete

Instead of “saving is broken,” write: “In build 8, create a sample item, turn off connectivity, tap Save, restore connectivity and reopen the list. The item is missing and no error was shown.” The example describes a hypothetical defect; adapt it only to behavior actually observed.

Prioritize by consequence

Separate blocked sign-in, data loss and payment failures from visual spacing issues. Keep one issue per report so each fix can be assigned and verified independently.

After a fix, repeat the original steps on the new build and also test the normal successful path. Record the retest result rather than closing the issue because a developer says it is fixed.

Useful testing produces evidence and product improvements. Do not ask participants to manufacture positive feedback, public ratings or activity claims. A truthful unresolved issue is more useful than a polished but inaccurate report.