A bug report is the primary communication between testers and developers. A well-written bug report gets fixed fast. A vague one gets ignored or bounced back.
Anatomy of a Bug Report
| Field | Description |
|---|---|
| Title | One-line summary of the problem |
| Severity | How bad is it? (Critical / Major / Minor / Trivial) |
| Priority | How urgently should it be fixed? (P1 / P2 / P3 / P4) |
| Environment | OS, browser, app version, device |
| Steps to Reproduce | Exact steps to trigger the bug |
| Expected Result | What should happen |
| Actual Result | What actually happens |
| Attachments | Screenshots, videos, logs |
Severity vs Priority
These are often confused but serve different purposes:
Severity measures the technical impact:
- Critical: System crash, data loss, security breach
- Major: Core feature broken, no workaround
- Minor: Feature works but with issues, workaround exists
- Trivial: Cosmetic issue, typo, misaligned element
Priority measures the business urgency:
- P1: Fix immediately (blocking release)
- P2: Fix before next release
- P3: Fix when possible
- P4: Nice to have
A typo on the homepage might be low severity (trivial) but high priority (P1) because it's visible to every user. A crash in an admin tool used once a year might be high severity (critical) but low priority (P3).
Example Bug Report
Title: Login button unresponsive after failed login attempt
Severity: Major
Priority: P1
Environment: Chrome 124, Windows 11, v2.3.1
Steps to Reproduce:
1. Navigate to /login
2. Enter "test@example.com" as email
3. Enter "wrongpassword" as password
4. Click "Sign In"
5. See error message "Invalid credentials"
6. Correct the password to "ValidPass123!"
7. Click "Sign In" again
Expected Result: User is logged in successfully
Actual Result: Button does not respond to click. No network
request is made. Console shows: "TypeError: Cannot read
property 'disabled' of null"
Attachments: screenshot.png, console-log.txtWhat Makes a Good Bug Report
Be Specific
Bad: "Login doesn't work" Good: "Login button unresponsive after entering incorrect password and then correcting it"
Minimal Reproduction Steps
Include only the steps needed to trigger the bug. Don't include "Open a browser" or "Go to the website" unless the browser choice matters.
One Bug Per Report
Don't file "Login is broken and also the footer link is wrong." Those are two separate issues.
Include Evidence
- Screenshots with annotations showing the problem
- Screen recordings for interaction bugs
- Console logs for JavaScript errors
- Network logs for API failures
- Device info for mobile or cross-browser bugs
Bug Life Cycle
A bug moves through these states:
[New] → [Assigned] → [In Progress] → [Fixed] → [Verified] → [Closed]
↓ ↓
[Rejected] [Reopened]- New: Bug is reported
- Assigned: Assigned to a developer
- In Progress: Developer is working on it
- Fixed: Developer has pushed a fix
- Verified: Tester confirms the fix works
- Closed: Bug is resolved
- Rejected: Not a bug, duplicate, or can't reproduce
- Reopened: Fix didn't work or bug reappeared
Common Mistakes
- "It doesn't work" — What doesn't work? What did you expect?
- Missing environment — A bug might only happen on Safari or on mobile.
- Assuming the cause — Report what you observed, not what you think the code is doing wrong.
- Not verifying — Always retest after a fix. Don't just close the ticket.