Defect Management

The defect lifecycle

Writing good bug reports

A good bug report lets a developer reproduce the issue without asking you anything. It contains:

• Title — one sentence: what breaks, where, and under what condition. Not "Login broken" — "Login fails with HTTP 500 when password contains special characters".
• Steps to reproduce — numbered, specific, reproducible steps from a known starting state.
• Expected result — what should happen.
• Actual result — what actually happens. Include error messages verbatim.
• Environment — browser, OS, version, test environment.
• Severity and priority — (see below).
• Evidence — screenshot, video, log snippet.

Severity vs priority

These are different dimensions. Both must be set, and they often conflict.

Priority is a business decision: how urgently does this need to be fixed, relative to everything else? A low-severity cosmetic bug on the homepage might be high priority if a CEO demo is tomorrow. A high-severity crash in a rarely used report might be deferred.

Testers set severity; product/business sets priority. This distinction matters — don’t conflate them.

Root cause analysis

For high-severity or recurring defects, root cause analysis (RCA) asks not just "what broke" but "why." Common RCA techniques: 5 Whys, fishbone diagram, fault tree analysis. The goal: prevent the same class of bug recurring. RCA findings feed into process improvements and updated testing checklists.

Defect metrics

• Defect density — defects per unit of code or per feature area. Identifies unstable modules.
• Defect removal efficiency (DRE) — percentage of defects found before release vs total defects found (pre + post release). Target: > 90%.
• Mean time to detect (MTTD) — average time from defect introduction to detection.
• Defect escape rate — how many defects reach production. The key quality signal for leads.

ISTQB mapping