Your First Bug Report
Finding a bug is half the job. The other half is communicating it so clearly that someone who has never seen the issue can reproduce it, understand its impact, and fix it. A great bug report saves hours of back-and-forth. A bad one wastes everyone's time.
What Makes a Good Bug Report
Think about it from the developer's perspective. They're working on a different feature, they get a bug ticket, and they need to:
1. Understand what's wrong
2. Reproduce the problem on their machine
3. Find the root cause
4. Fix it without breaking anything else
Every field in a bug report serves one of those goals.
The Template
Title: [Short, specific summary]
Severity: Critical / Major / Minor / Cosmetic
Steps to Reproduce:
1. Go to...
2. Click...
3. Enter...
Expected Result: [What should happen]
Actual Result: [What actually happens]
Environment: [Browser, OS, version]
Evidence: [Screenshot, video, logs]
Field-by-Field Breakdown
Title: Be specific. "Login broken" is useless. "Login form accepts empty password and shows blank page" tells the developer exactly what to expect.
Severity: Be honest. Not every bug is critical. A typo on the About page is cosmetic. A payment processing error that charges users twice is critical. Crying wolf with severity burns your credibility.
Steps to Reproduce: The most important field. Write steps that a stranger could follow. Include specific data you used. "Enter a username" is vague. "Enter 'testuser@email.com' in the email field" is reproducible.
Expected vs. Actual: Side by side, these two fields instantly communicate the problem. "Expected: Error message appears. Actual: Page crashes with a 500 error."
Environment: Bugs are often browser- or OS-specific. Always include this.
Evidence: A screenshot is worth a thousand words. A screen recording is worth a thousand screenshots. Attach logs if you have them.
Exercise
You're testing a login page. You discover three issues:
- The password field shows text in plain text (not masked with dots)
- Submitting the form with all fields empty shows no error message — just a page refresh
- The "Forgot Password" link goes to a 404 error page
Write a bug report for each issue. Use the template above. Think carefully about the severity of each one — which is most critical and why?
The key takeaway: A bug report that can't be reproduced is a bug report that won't be fixed. Write for the reader, not for yourself.
Put these bug report fields in the most logical order for helping a developer reproduce and fix a bug.
You find that the "Forgot Password" link goes to a 404 page. What severity should this be?
A broken password recovery link blocks a key user workflow. It's not cosmetic (it prevents functionality) and not critical (login itself still works), but it's major because affected users are completely stuck.
What is the single most important field in a bug report?
Click to reveal answer
Steps to Reproduce. Without clear, specific reproduction steps, a developer cannot reliably recreate the issue, and a bug that can't be reproduced is a bug that won't be fixed.
Click to flip back