Writing Effective Bug Reports

Finding a bug is half the job. The other half is communicating it so a developer can reproduce and fix it fast. A sloppy bug report costs days of back-and-forth.

Bad vs. Good Bug Report

Bad Report

Title: 'Checkout is broken'
'I tried to buy something and it did not work'
No steps to reproduce
No environment info
No error message captured
No severity or priority
Developer has no idea where to start

Good Report

Title: 'Checkout fails with Payment error on expired card'
Exact steps with test card: 4111 1111 1111 1111, exp 01/2020
Expected vs actual clearly stated
Environment: Chrome 120, macOS 14.2, v2.3.1
Exact error text captured
Severity: Minor | Priority: Medium
Developer can reproduce and fix without asking

VerdictThe good report tells the developer exactly what happened, how to make it happen again, and what should have happened.

Quick check

Question 1 of 10 correct

Which of these titles is the most useful?

Structure of a Bug Report

Field	Purpose
Title	One-line summary of the defect
Description	Detailed explanation of the issue
Steps to Reproduce	Exact actions to trigger the bug
Expected Result	What should happen
Actual Result	What actually happens
Environment	Browser, OS, device, app version
Severity	How badly the defect impacts the system
Priority	How urgently it should be fixed
Attachments	Screenshots, logs, videos

Bug Report

8 fields

Title:"Short, specific summary"

Severity:"Critical / Major / Minor / Trivial"

Priority:"Urgent / High / Medium / Low"

Environment:"Browser, OS, URL"

Steps to Reproduce:"1. Go to... 2. Click... 3. ..."

Expected Result:"What SHOULD happen"

Actual Result:"What actually happens"

Screenshot/Logs:"Visual evidence"

A great bug report has all these pieces.

Severity vs. Priority

Severity

Technical impact on the system
'How badly does it break things?'
Determined by the tester
Levels: Critical, Major, Minor, Trivial
Example: app crash = Critical

Priority

Business urgency of fixing it
'How soon must it be fixed?'
Determined by product/manager
Levels: Urgent, High, Medium, Low
Example: CEO typo = Urgent

VerdictSame bug can be Trivial severity but Urgent priority — or Major severity but Low priority. Keep them separate.

Severity Levels

Level	Meaning	Example
Critical	System unusable, data loss, or security breach	Users can’t log in; personal data exposed
Major	Core feature broken, no workaround	Cart totals wrong; search returns nothing
Minor	Feature imperfect, workaround exists	Sort order wrong, but user can scroll
Trivial	Cosmetic issue, no functional impact	Typo on a button label

Priority Levels

Level	Meaning	Example
Urgent	Fix immediately, hotfix if needed	Production down; active security breach
High	Fix this sprint or release	Core workflow broken for many users
Medium	Fix in next planned release	Non-critical feature has a defect
Low	Fix when time allows	Cosmetic issue on a rarely visited page

Severity vs Priority

Severity

High

High Severity, Low Priority

Edge case crash that affects 0.1% users

High Severity, High Priority

App crashes for everyone on login

Low Severity, Low Priority

Typo in the footer that says 2023

Low Severity, High Priority

CEO name typo on landing page

Low

LowHigh

Priority

Severity = how bad. Priority = how urgent. These are different!

Tips for Reproducible Bug Reports

Practice: Match Severity Levels

Drag each scenario to its correct severity level.

Practice: Spot the Problems in This Bug Report

You are reviewing a teammate's bug report before it goes to the development team. Identify all the problems that would make this report difficult for a developer to act on.

Title: Search is broken

Description: When I searched for something the results were wrong. I think it might be a backend issue. It happened on my computer.

Steps to Reproduce:
1. Go to the search page
2. Search for something
3. See wrong results

Expected Result: Correct results should show up.

Actual Result: Wrong results.

Severity: Critical
Priority: Urgent

Found 0 of 5 bugs

Quiz

Question 1 of 20 correct

A production database vulnerability allows unauthorized users to read other customers' personal information. No data has been lost yet, but the exposure is active. What severity and priority combination is most appropriate?