Educational guide, not a Google Play requirement, and no guarantee of any review outcome. Where Google publishes guidance, this article says so explicitly.
"The app is not working." A developer reading that knows something went wrong and almost nothing else: which screen, which build, which device, whether anything happened. Answering those costs a round trip, often several, and by then the tester has moved on.
A written Android app bug report prevents those round trips. Done well it is the difference between "we think there might be a problem" and "open the app on a Pixel 7 running build 240, tap these four things, and the sign-in spinner never stops".
This guide covers the fields that earn their place, writing steps someone else can follow, severity versus priority, and how developers can turn scattered messages into a process.
What Is an Android App Bug Report?
A bug report is a described observation: what you did, what you expected, what happened, and enough context for someone else to see it themselves. It succeeds on one test — can another person reproduce the problem without asking you anything?
That excludes the other thing Android also calls a "bug report". A system bug report is a diagnostic archive — device logs, stack traces, and system state, captured from Developer options or with adb bugreport and unpacked into a zip whose main file holds dumpsys, dumpstate, and logcat output. It is a developer troubleshooting tool, and Google notes that end users cannot easily share these, which is why real crash data normally arrives through Play Console instead.
Ordinary app problems do not need one. A developer may request a system bug report for a specific issue — "capture one right after the crash on build 240" — never as a blanket instruction.
Not everything a tester dislikes is a bug. A bug contradicts the app's intent; a usability issue works but misleads or slows people down; a feature request asks for behaviour the app never promised; an expected limitation is documented or deliberate, such as a region restriction.
Keep observations apart from assumptions. "The button does nothing" is an observation; "the call fails because the token expired" is a hypothesis. A cause guess is fine as a marked note, never as a replacement for what you saw.
Why Good Bug Reports Matter
The value of a report is not its length but how much of the developer's search it removes.
- Reproduction gets faster. Build, device, and exact steps turn a hunt into a two-minute check.
- Debugging gets cheaper. Android's testing guidance notes a bug caught by a fast unit test is fixed in minutes, while one found by a slow end-to-end test can take days. Tester reports sit at the slow end.
- Feedback becomes usable. Google asks developers for clear instructions and to specify the feedback they want; a shared format does both.
On policy, to be precise: Google Play publishes no required bug-report format. Google's guidance is a clear feedback channel and clear instructions to testers, not mandatory fields. Everything beyond that here is TestersHQ's practical recommendation.
What Should a Good Bug Report Include?
The table is a field reference, not a checklist every report must satisfy. A cosmetic typo needs three fields; an intermittent crash may need all of them.
| Field | What to include | Example |
|---|---|---|
| Bug title | The specific problem in one line | Sign-in spinner never resolves after valid credentials |
| App version | Exact build, version and version code | 1.4.2 (versionCode 240) |
| Device | Model, not just the brand | Pixel 7 |
| Android version | OS version | Android 15 |
| Preconditions | State before step one | User is signed out |
| Steps to reproduce | Numbered actions, one per step | Open app, enter credentials, tap Sign in |
| Expected result | What should have happened | User reaches the dashboard |
| Actual result | What happened instead | Loading spinner continues indefinitely |
| Frequency | How often, out of how many tries | 3 out of 5 attempts |
| Severity | Observed impact on the user | High |
| Evidence | What supports the claim | Screen recording attached |
The title is what a developer scans in a list, so name the behaviour rather than your diagnosis. Version and device narrow the search fastest: if a build passes on one device and fails on another, that difference is the clue. The real device testing guide covers choosing devices.
How to Write Steps to Reproduce a Bug
Reproduction is the whole point. If a developer cannot trigger the problem from your steps, the rest of the report describes something they cannot see.
Weak:
Opened the app, logged in normally and tried to use it, then it broke.Improved:
- Install build 1.4.2 (240) from the closed testing track.
- Sign out from Profile → Sign out.
- Open Profile → Sign in.
- Enter
[email protected]and a valid test password. - Tap Sign in.
- Wait 30 seconds without touching the screen.
Why it works: one action per step, exact inputs, stated preconditions and timing, and a named build. Never paste a real password.
Intermittent problems need a different shape: do not describe one attempt as if it were deterministic. Say how many attempts failed, what changed between them, and whether a pattern held. "Failed 3 of 5 attempts, both after a device rotation on the upload screen" gives a developer something to test; "sometimes it fails" does not.
Expected Result vs. Actual Result
Mixing these two is the most common reason a report gets misread. Keep them on separate lines.
| Scenario | Expected result | Actual result |
|---|---|---|
| Login failure | The dashboard opens and the session is saved | The spinner keeps turning and the form stays on screen |
| Image upload failure | The progress bar completes and the photo appears in the post | Progress stays at 0% and the post saves without an image |
| Crash after tapping a button | The confirmation dialog appears and the screen stays usable | The app closes with no message; reopening loses the draft |
"Expected" only works when it rests on something the app promises. "Expected: a smoother animation" is a wish; "expected: Home, as on Android 14" is a comparison. If the expectation comes from documentation or an earlier build, say which.
Bug Severity and Priority Explained
Severity is the impact on users and the product. Priority is when the team chooses to fix it, and a tester rarely knows the release timing and business risk behind that decision. So a crash on one rare tablet can be severe but low priority, while a missing label on the most-viewed screen can be trivial but urgent.
| Severity | Impact on users | Example |
|---|---|---|
| Critical | App unusable, crashes on launch, or loses user data | Crash on launch for every user who installs the build |
| High | A major feature fails and there is no workaround | Checkout fails for every card payment |
| Medium | A feature fails, but a workaround exists | Search ignores filters until the screen is reloaded |
| Low | Cosmetic or edge-case defect with minor impact | Footer text overlaps slightly on one tablet model |
Severity definitions vary by team and product. And marking everything Critical destroys the signal: once a team distrusts the field, the real critical report queues behind cosmetic noise.
When Should Testers Attach Screenshots, Videos, or Logs?
Evidence should answer a question the text cannot: a screenshot of a layout defect settles an argument, one of a correct screen adds nothing.
Screenshot the whole screen so the app header stays visible and the developer can tell which build and screen was open. For navigation problems, ten to twenty seconds of recording is enough, starting before the first tap. Note the clock time of any crash — that timestamp is what makes log matching possible.
Privacy and security warning
- Never expose passwords, one-time codes, card numbers, payment details, private messages, or another person's account data.
- Redact names, email addresses, phone numbers, and order IDs before sharing a screenshot, recording, or log, and send diagnostic files through a private channel the tester agreed to.
Copy-and-Paste Android Bug Report Template
Copy the block below into an email, a tracker, or a chat message. Delete fields that genuinely do not apply instead of writing "N/A".
Bug Title:
App Name:
App Version / Build:
Device Model:
Android Version:
Preconditions:
Steps to Reproduce:
1.
2.
3.
Expected Result:
Actual Result:
Frequency:
Severity:
Evidence:
Additional Notes:If you are short on time, fill in the version and the steps anyway; without them the report cannot be reproduced.
Complete Android Bug Report Examples
These three reports are illustrative examples written for this guide, not records from real customers or actual TestersHQ projects.
Example 1: Login button does not respond
Title: Sign-in spinner never resolves after valid credentials
Environment: 1.4.2 (240), Pixel 7, Android 15
Steps: 1) Sign out 2) Open Profile → Sign in
3) Enter [email protected] and a valid password
4) Tap Sign in 5) Wait 30 seconds
Expected: Dashboard opens and the session persists
Actual: Spinner turns indefinitely; the form never changes
Frequency: 3 of 5 attempts, no pattern
Severity: High — the account is unusable on this build
Evidence: Recording; the final 10 seconds show the spinnerExample 2: App crashes when uploading an image
Title: App closes when uploading a 4 MB JPEG from the Gallery
Environment: 1.4.2 (240), Galaxy A54, Android 14
Steps: 1) Create → New post 2) Add photo → Gallery
3) Select a 4096×3072 JPEG, about 4 MB 4) Tap Upload
Expected: The photo uploads and progress completes
Actual: The app closes with no message; the draft is not saved
Frequency: 5 of 5 with that image; a 300 KB PNG uploads fine
Severity: Critical — a core action fails and unsaved work is lost
Evidence: Recording; crash at 14:32 device time on build 240Example 3: Incorrect information after returning from another screen
Title: Checkout total keeps the old amount after returning from Details
Environment: 1.4.2 (240), Pixel 6a, Android 15
Steps: 1) Add item A ($4.99) 2) Open Checkout 3) Tap Details
4) Go back unchanged 5) Add item B ($2.50) 6) Reopen Checkout
Expected: The total shows $7.49
Actual: The total still shows $4.99 and the order is charged that amount
Frequency: 4 of 4 using back navigation; not reproduced from the menu
Severity: Critical — the amount charged is wrong
Evidence: Two screenshots and a short recording; no personal data visibleCommon Bug Reporting Mistakes
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| 1. Vague title | Cannot be triaged | Name the screen and the failing behaviour |
| 2. Omitting reproduction steps | Cannot be triggered | Number every action, one per step |
| 3. Mixing expected and actual | Defect looks like a wish | Two separate lines |
| 4. Several bugs in one report | One fix hides the rest | One report per behaviour |
| 5. Guessing the cause | Misdirects the fix | Observation first, guess as a note |
| 6. No device or version | May already be fixed | Model, Android version, build |
| 7. Screenshot without explanation | Shows a screen, not the problem | One line on what it proves |
| 8. Sharing private information | Exposes accounts | Redact, then private channel |
| 9. Marking everything Critical | Severity stops meaning anything | Describe impact; team prioritises |
| 10. Not retrying the steps | Glitches look like defects | Try three times; report the rate |
Number 10 is the cheapest fix and the most often skipped.
How Developers Can Manage Tester Feedback
A good report still needs somewhere to land:
- Receive and log it with one owner and an identifier.
- Check for duplicates and group them rather than closing them silently.
- Confirm environment and steps, asking one consolidated question if something is missing.
- Reproduce it on the stated build and device before theorising about causes.
- Assign severity and priority — impact for one, release context for the other.
- Fix it and record which build carries the fix.
- Retest the affected functionality, not only the reported path.
- Update the tester, because closing the loop is what makes the next report detailed.
Inside Google Play. Play Console has a Testing feedback page under Monitor and improve → Ratings and reviews → Testing feedback, filterable by date, language, reply state, app version, and device type. Google also lets developers set a feedback URL or email shown on the tester opt-in page, and states that test feedback does not affect the app's public rating.
For a starting process rather than a blank inbox: publish the template, name one person to triage, and review open reports weekly. The closed testing checklist covers the surrounding steps, and the pre-launch report guide explains what automated crash data already covers.
How Better Bug Reports Improve Closed Testing
Closed testing is where many apps get their only structured feedback before launch. Google requires personal developer accounts created after November 13, 2023 to run a closed test with at least 12 testers opted in continuously for 14 days before applying for production access, and the application asks developers to summarise the feedback received.
That summary is only as good as the reports behind it. "Testers said it was fine" and "we fixed 14 issues across login, upload, and checkout" describe very different processes.
Useful reports also say something about the test: which screens testers never reached, which device they used, whether the instructions were clear. The 12-tester and 14-day requirement and the tester engagement guide cover the logistics, and the production access questionnaire guide covers what the application asks. None of this guarantees production access, which Google decides on more than feedback quality.
Frequently Asked Questions
What is the best format for an Android bug report?
No official standard exists; the fields in this guide work in any inbox or tracker.
What should I include in a mobile app bug report?
The build, device and Android version, numbered steps, expected and actual results, and frequency.
Do I need a screenshot for every bug?
No. Screenshots suit visual defects; crashes need steps and a timestamp; wrong values need numbers.
What are steps to reproduce?
The ordered actions that trigger the problem, from a stated precondition, one action per step.
What is the difference between severity and priority?
Severity is impact on users; priority is when the team fixes it. Testers describe severity.
Should testers report suggestions as bugs?
Label them as suggestions; mixing wishes into defects makes the list untrustworthy.
Can testers report bugs through Google Play?
Yes. Testers can submit private feedback through Play, and developers can publish a feedback URL or email on the opt-in page.
What should I do if I cannot reproduce a bug?
Report it anyway with your attempts, build, device, and time. Three testers reporting it is a signal.
Conclusion
A bug report is a small piece of writing with one job: let someone else see what you saw. The fields, template, and severity scale serve that, not the other way round.
Three habits do most of the work: name the behaviour instead of the cause, number the steps one action at a time, and keep expected and actual on separate lines.
Testers who write like that become the people developers ask for first. TestersHQ works with developers and testers who care about that difference; if you are preparing an app for closed testing and want actionable feedback, that is what we help with.
