When to Use
When reporting bugs found during manual testing or QA validation.
Patterns
Bug Report Structure
markdown
## Bug: [Short descriptive title] **Severity:** Critical | High | Medium | Low **Priority:** P0 | P1 | P2 | P3 **Environment:** [browser, OS, device] **Version:** [app version, commit] ### Steps to Reproduce 1. [First step] 2. [Second step] 3. [Step where bug occurs] ### Expected Behavior [What should happen] ### Actual Behavior [What actually happens] ### Evidence - Screenshot: [link] - Video: [link] - Console logs: [paste] ### Additional Context [Any other relevant info]
Severity Levels
code
CRITICAL: System crash, data loss, security breach
→ Blocks release, fix immediately
HIGH: Major feature broken, no workaround
→ Must fix before release
MEDIUM: Feature broken but workaround exists
→ Should fix, can defer if needed
LOW: Minor issue, cosmetic, edge case
→ Fix when time permits
Good vs Bad Bug Titles
code
❌ "Button doesn't work" ✅ "Submit button unresponsive after form validation error on Safari" ❌ "Crash" ✅ "App crashes when uploading file >10MB on mobile" ❌ "Slow" ✅ "Dashboard load time >5s when user has >100 items"
Anti-Patterns
- •Missing reproduction steps
- •No expected vs actual
- •Vague titles ("doesn't work")
- •No environment info
- •Screenshots without context
Verification Checklist
- • Title is specific and searchable
- • Steps reproduce the bug reliably
- • Expected vs actual clearly stated
- • Severity/priority assigned
- • Evidence attached