Stop 02 · Manual Testing FundamentalsTopics · 11/11

Writing Effective Bug Reports

Part of the QA Testing Roadmap

In short

A bug report is a message to a busy developer. Write it well and the bug gets fixed today. Write it badly and it bounces back as 'can't reproduce'.

A clear bug report includes steps to reproduce, expected vs actual result, environment details, and severity — the difference between a report that gets fixed quickly and one that gets bounced back for clarification.

The purple blob points down a street while explaining directions to an auto-rickshaw driver.

Think of it like this

Giving directions to an auto driver

'Near the big temple' gets you lost. 'Second left after the petrol pump, blue gate opposite the school' gets you home. A good bug report gives exact directions to the problem, so anyone can reach it.

Watch it happen

Two reports, two outcomes

QA
Developer

'Cart is broken'

1/5A vague report: no steps, no environment, no expected result.

The big ideas

What you need to know

A title that says it all

Say what, where and when: 'Cart total ignores coupon after changing quantity'.

Exact steps

Numbered steps from a known starting point, with the data you used.

Severity vs priority

Severity is how bad the impact is. Priority is how soon to fix it. A typo on the homepage is low severity, high priority.

Evidence

Screenshots, a screen recording, console errors or API responses make it impossible to argue with.

See it in code

Walk through the code

text
1Title:     Cart total ignores coupon after quantity change2Env:       Staging build 2.3.1, Chrome on Android 143Account:   qa.user3@test.com4Steps:     1. Add 1 x T-shirt (Rs 500) to cart5           2. Apply coupon SAVE10, total shows Rs 4506           3. Change quantity to 27Expected:  Total Rs 900 (10% off Rs 1000)8Actual:    Total Rs 1000, coupon still shown as applied9Severity:  Major    Priority: High10Evidence:  cart-coupon.mp4, console log attached

1/4The title alone tells the developer what's wrong.

Everything a developer needs in one place: where, how, what should happen and what did.

Save yourself the pain

Common mistakes

Oops

Putting three different bugs in one report.

Do this instead

One bug per report, so each can be assigned, fixed and closed on its own.

Oops

Writing emotional reports like 'this is totally broken!!'.

Do this instead

Stay factual and calm. Facts get bugs fixed, frustration gets ignored.

Your mission

Report a real bug

~25 min

Quick check

The company logo on the homepage is misspelled. Nothing else is affected. How would you usually classify it?

Go deeper

  1. 1Write a bug report for a real bug you've encountered, including all key fields.
  2. 2Learn why 'it doesn't work' is the single most common and least useful bug report pattern.
  3. 3Practice attaching evidence (screenshots, logs) to make a report self-explanatory.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge