Testing guides / By Gigsdo · Reviewed 24 September 2026
Android bug report template: make issues reproducible
A useful bug report lets someone else reproduce the problem without a long exchange of messages. Start with one specific issue and enough context to repeat it.
Download a blank issue template
Download the bug-report template
Copy it into your issue tracker or a shared document. Give each issue its own record. Use a separate link for supporting screenshots or recordings, with personal information removed.
Include the details that change the result
- Title: the action and failure, rather than “app broken”.
- Environment: app build, Android version and device model.
- Preconditions: account state, permissions, connection and relevant saved data.
- Steps: a short numbered sequence another person can follow.
- Expected and actual: explain the difference clearly.
- Frequency: every attempt, occasional, or not yet reproduced.
- Impact: which user task is blocked and whether a workaround exists.
Attach logs only when relevant and reviewed for private data. A report should not contain passwords, payment details or customer records.
Compare a vague report with a useful one
Illustrative example, not a customer result.
Vague: “Saving is broken.”
Specific: “Editing a draft title is lost after reopening the draft.”
Steps: Open an existing draft, change its title, tap Save, leave the screen and reopen the draft.
Expected: The new title appears. Actual: The previous title appears, despite a success message.
Add the tested build and environment before handing it over. Do not label the cause as a database or API failure unless investigation has established that.
Agree priority and verify the fix
Describe impact separately from urgency. A crash in a core journey may block release; a visual defect may be lower priority unless it hides an important control. Agree priorities with the developer rather than assigning every issue the same severity.
When a fix arrives, repeat the original steps on the new build. Record pass, fail or blocked and check connected journeys within scope. Keep the original report so the team can see what changed.
Use the Android QA checklist to plan coverage. For broader quality considerations, consult Android’s app-quality guidance.
Need help finding and documenting issues?
Our Android QA service covers agreed journeys and actionable findings. Device coverage, supporting evidence and retests are confirmed in your scope.
Plan a QA review