Manual Testing
Intermediate 12 min read Manual Testing

Defect Lifecycle & Reporting

A defect is a request for information as much as a report of failure. Master the defect lifecycle — from detection through triage, fix, verification and closure — and learn to write reports that developers can act on without a single follow-up question.

defectbuglifecycleseveritypriorityreproduction
Prerequisites: Testing Fundamentals Test Execution & Tracking
Introduction

What is this?

A defect is a deviation between actual and expected behavior, tracked through a lifecycle: new, triaged, assigned, in-progress, fixed, verified, closed (or reopened). The lifecycle makes sure every problem has an owner, a status and evidence. Good reporting separates severity (how bad is it) from priority (how urgent to fix) and gives developers everything they need to reproduce — steps, environment, data, expected vs actual and evidence.

Motivation

Why do you need it?

  • A reproducible report with exact steps turns a bug report into a small development task.
  • Severity and priority triage focuses the team on the defects that actually threaten the release.
  • A tracked lifecycle stops defects from being silently lost between detection and closure.
  • History of reopen and rejection reveals quality problems in both code and bug reports.
  • Clean defect data feeds the metrics — open counts, aging, escape rate — that owners rely on.
Think about it

Mental model

Imagine

A doctor's patient chart

Think of

A defect record

You would not treat a patient based on 'feels bad'. You record symptoms, tests, diagnosis, treatment and outcome. A defect record does the same for software: symptoms (steps, expected vs actual), diagnosis (root cause), treatment (fix) and outcome (verification and closure).

Mechanics

How it works

  • A tester detects a deviation and writes a report with title, environment, steps to reproduce, expected vs actual and severity.
  • The report enters triage: the team confirms it is a valid defect, assigns severity and priority, and routes it to an owner.
  • The developer reproduces, diagnoses, fixes and notes the root cause; the report moves to 'fixed' with the version.
  • The tester verifies the fix in the reported environment, checks for side effects, and closes it or reopens it with new evidence.
  • The closed record stays as audit history and feeds quality metrics.

The defect lifecycle from detection to closure.

New
Triage
Assigned
In progress
Fixed
Verified
Closed / Reopened
Reference

Key commands

gh issue create --label bug --assignee dev-pay --title 'DF-102' --body-file defect.md

Create the tracked defect record with the full report body.

gh issue list --label bug --state open

Review the open defect backlog for triage.

DF-102  Checkout tax off by 0.01  bug
curl -sf https://staging.example.com/api/health | jq '.services.pdf'

Confirm whether a defect's environment dependency is healthy before assigning.

gh issue close DF-102 --reason completed

Close the defect once the fix is verified.

gh issue list --label bug --search 'is:open sort:created-asc'

Age the backlog oldest-first to prioritize long-open defects.

Hands-on

Examples

A defect report that needs no follow-up

A defect report that needs no follow-up
# DEFECT DF-102 — Tax total off by 0.01 on checkout
Severity  : P2 (high, money accuracy)   Priority: High
Product   : Checkout v2.0-RC2   Module: Payment
Reporter  : tester   Assigned: dev-pay
 
Steps to reproduce:
1. Add item priced 124.99 to cart
2. Enter shipping ZIP 94016
3. Proceed to checkout
4. Read the total in the order summary
 
Expected : 134.99 (tax 10.00)
Actual   : 134.98 (tax 9.99)
Environment: Chrome 120 / macOS / staging DB 'qa-eu'
Evidence : screenshot checkout-total.png + HAR checkout-total.har

Every field exists to eliminate a round trip: exact steps, exact expected-vs-actual numbers, environment, and attached evidence. The developer can reproduce without asking a question.

Real world

In production

  • Triage boards (triaged by severity and priority) run every morning before any new feature work starts.
  • Defect escape rate (defects found in production vs in testing) calibrates test effectiveness.
  • Reopen rate flags shallow fixes and weak verification.
  • Aging open defects in the critical path become the visible go/no-go blocker for release.
Guidelines

Best practices

  • Write the title as the symptom, not the guess — 'tax off by 0.01', not 'rounding bug'.
  • Always include steps, expected vs actual, environment and evidence.
  • Report severity (impact) and priority (urgency) separately and let triage set priority.
  • Reproduce at least once before reporting to avoid environment-driven noise.
  • Verify the fix in the same conditions it was reported in, then check for side effects.
Watch out

Common mistakes

  • Reporting defects without steps, forcing a 'please reproduce' round trip.
  • Merging severity and priority, or letting the reporter set priority for everyone.
  • Closing a defect without verification because the fix 'looks right'.
  • Duplicating defects because the search for similar reports was skipped.
Root cause analysis

Common issues

Error
Developers reject a defect as 'works on my machine'
Root cause

Environment or data differences not captured in the report

Fix

Add environment, database and data details to the report; reproduce in the reported conditions.

Error
The same defect keeps getting reported
Root cause

No search before reporting or no linking of duplicates

Fix

Search open defects first and link duplicates to the primary report.

Error
A fix passes verification but the issue resurfaces in production
Root cause

Root cause was not addressed, only the symptom

Fix

Insist on root-cause notes in the fix and add a regression test covering the scenario.

When things break

Debugging tips

  • If a defect can't be reproduced, capture network logs and console errors to narrow the conditions.
  • Attach timing and user data (account, locale, currency) — defects often depend on exact state.
  • When several defects share a root cause, keep them linked and close the duplicates against the primary.
  • A reopened defect usually means the fix addressed the symptom, not the cause — dig deeper.
Interviews

Interview checkpoint

Practice

Hands-on lab

Triage a Defect Backlog
35 min · intermediate
In progress
Objectives
  • Write a defect report a developer can act on without follow-up
  • Triage severity and priority separately
  • Track a defect through the lifecycle states
  • Link duplicate reports to a primary defect

Triage a Defect Backlog

35 min · intermediate

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which field is most important for helping a developer reproduce a defect?

2

Severity and priority are the same thing.

3

A fix is merged and you verify it passes in your environment. What else should you do before closing?

Quick reference

Cheat sheet

Writing a defensible defect report
TitleSymptom, not diagnosis
StepsNumbered and exact
Expected vs actualPrecise values
EnvironmentBuild, browser, OS, DB
EvidenceScreenshot, HAR, logs
Go deeper

Official documentation

Atlassian — Bug Tracking Basics
docs
GitHub — Issues Quickstart
docs
ISTQB Glossary — Defect
docs