Bug Reporting & the Defect Life Cycle

Why bug reports matter#

A bug that can't be reproduced doesn't get fixed. The quality of your bug reports decides how quickly issues are resolved — and how much developers trust you. A great report lets a developer reproduce the problem in under five minutes without asking you a single question.

Anatomy of a good bug report#

ID:           BUG-202
Title:        Order is charged the discounted price but saved without the discount code
Environment:  Staging, build 4.2.0-rc3, Chrome 130 on Windows 11
Severity:     High        Priority: P1
Component:    Checkout

Preconditions:
  Logged in as ayesha@example.com; cart contains 1 × "Laptop Stand" ($80).

Steps to reproduce:
  1. Open /checkout in tab A and apply code SAVE10 — total shows $72.00.
  2. Open /checkout in tab B and click "Remove code".
  3. Return to tab A and click "Pay now".

Expected result:
  Either the payment uses the current cart state ($80, no code) or tab A
  refreshes and asks the user to confirm the new total.

Actual result:
  Card is charged $72.00, but the saved order shows no discount code and
  a total of $80.00. Finance reports will not match payments.

Frequency:    3/3 attempts
Attachments:  checkout-tabs.mp4, network-log.har, order-#5531.png

What makes it good#

• Title = what's wrong + where. "Checkout broken" is useless; the title above could be understood in a sprint board list.
• Exact environment and build. Bugs often depend on browser or version.
• Numbered, minimal steps. Remove anything not needed to reproduce.
• Expected vs actual. Shows why it's a bug, not just what happened.
• Evidence. Screenshots, a short video, console errors, network logs (HAR) or server log lines.
• One bug per report. Two problems → two tickets.
• Neutral tone. Describe behaviour, never blame a person.

Severity vs priority#

Severity — how badly the defect affects the system (set by QA). Priority — how soon it should be fixed (set by the product owner).

They don't always match:

• High severity, low priority: a crash in an admin export used once a year.
• Low severity, high priority: the company's name is misspelled on the homepage before a product launch.

The defect life cycle#

A defect moves through states from discovery to closure. Most tools (Jira, Azure DevOps) follow a version of this:

 New ──► Assigned ──► Open / In progress ──► Fixed ──► Ready for retest ──► Retest
  │          │                                                              │
  │          ├──► Rejected (not a bug / works as designed)                  ├──► Verified ──► Closed
  │          ├──► Duplicate                                                 │
  │          └──► Deferred (fix in a later release)                         └──► Reopened ──► Assigned
  └──► Cannot reproduce (needs more information)

Retesting vs regression#

After a fix:

1. Retest the exact steps in the bug report — does the bug still happen?
2. Run regression tests around it — did the fix break anything nearby? (See Regression, Smoke & Sanity Testing.)

Handling "cannot reproduce" and "works as designed"#

• Cannot reproduce: check environment differences (data, user role, browser, build), record a video, and look at logs together with the developer.
• Works as designed: if the design itself hurts users, raise it with the product owner as an improvement rather than arguing about the bug label.

A tester's goal isn't to win arguments — it's to make sure the team makes an informed decision about every problem.