Skip to content

9. Defect Management

← Previous: Testing Workflow | Back to QA Strategy | Next: Test Automation →

9.1 Overview

Defect management defines the process used to identify, document, prioritize, track, and resolve issues discovered during testing activities.

The objective of defect management is to ensure that issues affecting product functionality, stability, or user experience are properly documented, evaluated, and resolved before release.

A structured defect management process provides transparency into product quality and supports informed release decisions.

9.2 Defect Reporting

Defects may be identified by QA engineers at any stage of the testing process and at any testing level. Issues may be discovered during documentation review, design analysis, feature testing, system testing, regression testing, or exploratory testing.

A defect is defined as any deviation between the expected system behavior and the actual observed behavior. Defects may originate from different sources, including:

  • incorrect or incomplete implementation of functionality
  • inconsistencies between requirements, documentation, and system behavior
  • design or usability issues affecting user experience
  • unexpected system behavior or application errors
  • issues in integrations with external services or system components

Defects must be reported according to the Bug Reporting & Defect Management Guide, which defines:

  • severity and priority definitions
  • bug reporting standards
  • classification rules
  • triage and resolution guidelines

When such issues are identified, they must be documented in the project's issue tracking system to ensure visibility and proper resolution.

All identified defects are recorded in the project defect tracking system (e.g., Jira) and tracked throughout their lifecycle until resolution.

9.3 Defect Classification

Defects are categorized to help prioritize resolution and improve visibility into product quality. Issues may be classified based on several attributes, including:

  • severity – the impact of the defect on system functionality or user experience
  • priority – the urgency with which the defect should be resolved
  • affected component or application area – the part of the system where the issue occurs
  • defect type – the nature of the issue (e.g., functional, UI, usability, integration)

9.4 Defect Lifecycle

Defects move through a defined lifecycle from identification to resolution.

stateDiagram
  direction TB
  [*] --> BugFound
  BugFound --> CheckReported
  CheckReported --> AlreadyReported:Yes
  CheckReported --> ReportBug:No
  AlreadyReported --> NotReportedAgain
  NotReportedAgain --> [*]
  ReportBug --> ToDo
  ToDo --> Assigned
  Assigned --> InProgress:Developer starts work
  Assigned --> Blocked:Blocked
  Assigned --> CannotReproduce:Cannot reproduce
  Assigned --> TriageDecision:Requires decision (Not a bug / Duplicate)
  Blocked --> QAUnblockTask:Returned to QA
  QAUnblockTask --> UnblockTaskDone:Unblock task Done
  UnblockTaskDone --> InProgress
  InProgress --> ReadyForQA:Fix completed
  ReadyForQA --> Verified:QA validates fix
  Verified --> Done
  ReadyForQA --> Reopened:Issue persists
  Reopened --> InProgress
  CannotReproduce --> ReproCheck:QA retries reproduction
  ReproCheck --> Assigned:Reproduced
  ReproCheck --> Closed:Not reproduced
  TriageDecision --> NotABug:Not a bug confirmed
  TriageDecision --> Duplicate:Duplicate confirmed
  NotABug --> Closed
  Duplicate --> Closed
  BugFound:Bug found
  CheckReported:Check if already reported
  AlreadyReported:Already reported
  ReportBug:Report defect
  NotReportedAgain:Do not report again
  ToDo:To Do
  InProgress:In Progress
  CannotReproduce:Can't Reproduce
  TriageDecision:Team decision
  QAUnblockTask:QA creates unblock task
  UnblockTaskDone:Unblock task completed
  ReadyForQA:QA Review
  Reopened:QA Failed
  ReproCheck:QA retries reproduction
  Closed:Closed (Not fixed)
  NotABug:Not a bug
  style BugFound fill:#D50000,color:#000000,stroke:#000000
  style CheckReported fill:#FFE082,color:#000000
  style AlreadyReported fill:#BDBDBD,color:#000000
  style ReportBug fill:#90CAF9,color:#000000
  style NotReportedAgain fill:#E0E0E0,stroke:#000000,color:#000000
  style ToDo fill:#757575,color:#FFFFFF
  style Assigned,CannotReproduce fill:#BBDEFB,color:#000000
  style InProgress fill:#2962FF,color:#FFFFFF
  style Blocked fill:#FFCC80,color:#000000
  style TriageDecision fill:#B2DFDB,color:#000000
  style QAUnblockTask fill:#CE93D8,color:#000000
  style UnblockTaskDone fill:#B39DDB,color:#000000
  style ReadyForQA fill:#FFF9C4,color:#000000
  style Verified fill:#C8E6C9
  style Done,Closed fill:#00C853,color:#000000
  style Reopened fill:#FFCDD2,color:#000000
  style ReproCheck fill:#FFF59D,color:#000000
  style NotABug,Duplicate fill:#CFD8DC,color:#000000

Typical defect lifecycle stages include:

Open → Assigned → In Progress → QA Review → Verified → Done

Additional states may include:

  • QA Failed – Issue persists after attempted fix
  • Duplicate – Issue is a duplicate of another defect
  • Won't Fix – Issue will not be addressed
  • Cannot Reproduce – Issue cannot be replicated

The lifecycle ensures that defects are tracked consistently and their resolution status is clearly visible to the team.

9.5 Defect Triage

Defect triage is a collaborative process used to review reported defects and determine their priority, impact, and resolution approach.

Triage meetings may involve:

  • QA engineers
  • developers
  • product managers
  • project stakeholders when necessary

During defect triage, the team may:

  • review newly reported defects
  • confirm defect severity and priority
  • determine whether the issue must be fixed before release
  • assign responsibility for defect resolution

Defect triage helps ensure that development efforts focus on the most critical issues affecting product quality.

9.6 Defect Resolution Verification

Once a defect has been fixed by the development team, QA performs validation to confirm that the issue has been resolved correctly.

This verification typically includes:

  • retesting the specific issue
  • validating that the fix behaves as expected
  • ensuring the fix did not introduce new issues in related functionality

If the issue is resolved successfully, the defect is marked as Verified and then Done.

If the issue persists, the defect may be Reopened for further investigation.

9.7 Defect Tracking and Visibility

All defects are tracked in the project's issue tracking system to ensure full visibility for the development and product teams.

Defect tracking enables the team to monitor:

  • number of open defects
  • defect severity distribution
  • defect resolution progress
  • trends in defect discovery and resolution

9.8 Supporting Guides & Templates

Bug Reporting & Defect Management Guide - Describes how defects are reported, classified, tracked, and resolved, including defect lifecycle, triage process, and validation rules.

← Previous: Testing Workflow | Back to QA Strategy | Next: Test Automation →