TabQA logoTabQA

Report template

An Android bug report an engineer can investigate directly

A report is not a pile of attachments. It connects the shortest repro, expected and actual behavior, environment, and evidence from one time window.

Direct answer

An Android bug report should include a specific title, environment and versions, the shortest repro steps, expected behavior, actual behavior, occurrence time, and screenshots or video, relevant logs, and requests from the same reproduction window. Remove or redact sensitive data before sharing.

Android bug report with screenshot and log attachments exported by TabQA
Structured fields explain the issue and attachments prove what happened; both are required.

Copy-ready template

# [Area] Short description of the actual problem

- Time: YYYY-MM-DD HH:mm:ss + timezone
- Device: brand / model / Android version
- App: name / version / package / environment

## Reproduction steps
1. …
2. …
3. …

## Expected result
…

## Actual result
…

## Evidence
- Video and key screenshots
- Logcat from the same time window
- Related request or sanitized HAR

Pre-submit checklist

  • The title describes the actual difference, not only 'feature broken.'
  • Steps begin from a repeatable state and omit irrelevant actions.
  • Video, screenshots, logs, and requests refer to one occurrence time.
  • The report states reproducibility, frequency, and attempted diagnosis.
  • Account data, tokens, device identifiers, and production data have been reviewed.

How TabQA creates a draft

TabQA keeps device and target-app context, the final screenshot, video, filtered logs, and captured requests. After the tester adds a title, steps, expected result, and actual result, it exports report.md with selected attachments. The submitter still reviews the package and adds business context.

Sources and basis