Testing, Validation & Quality Assurance

Defect Management

18 min Lesson 7 of 10

Defect Management

No system of meaningful size reaches production without defects. The question is never whether defects will appear, but whether the team has a disciplined process for finding them, recording them precisely, routing them to the right person, tracking their resolution, and verifying the fix before closing the loop. That process is defect management — and the business analyst sits at its centre, bridging the tester who found the issue, the developer who must fix it, and the stakeholder who decides whether the fix is good enough.

In this lesson you will learn how to log a defect so it can actually be reproduced and fixed, how triage works, and how a defect moves through its full lifecycle — from discovery to closure. A well-run defect management process protects release dates, provides objective quality evidence for go/no-go decisions, and gives the project team an early warning system for systemic problems in the requirements or design.

What Is a Defect?

A defect (also called a bug, fault, or issue) is any deviation between the system's actual behaviour and its expected behaviour as defined by an approved requirement, acceptance criterion, or agreed standard. The definition matters: a defect is not simply something the tester dislikes — it must be traceable to a documented expectation. This is why requirements traceability (covered in Lesson 6) is so tightly coupled to defect management.

Defects should be distinguished from two related concepts. An enhancement request is a new capability that was never specified — it belongs in the change-control process, not the defect tracker. A known limitation is a behaviour that was consciously accepted and recorded in the SRS as out of scope for this release. Understanding these distinctions prevents scope creep masquerading as quality work.

Defect vs Enhancement — a real-world line: If the logistics portal specification states that shipment weights must be entered in kilograms, and the system accepts pounds without warning, that is a defect. If a tester requests that the portal also show the weight in pounds for international customers, that is an enhancement — even if it sounds like "fixing" something.

The Defect Lifecycle

Every organisation runs its defect tracker slightly differently, but the underlying lifecycle is consistent. Understanding each state — and what triggers the transition between states — is essential for anyone participating in quality assurance.

The defect lifecycle: states and the transitions that move a defect from discovery to closure (or rejection/deferral).

Walking through the key states:

New — A tester, analyst, or end-user logs the defect. No judgement yet about validity or priority.
Open — A triage meeting (or a designated triage owner) confirms the defect is genuine, sets its severity and priority, and assigns it to a developer. Defects that are duplicates, irreproducible, or working-as-designed are moved to Rejected instead. Defects that are valid but not planned for this release are moved to Deferred.
In Progress — The developer is actively investigating and coding a fix.
Fixed — The developer deploys the fix to the test environment and marks the defect Fixed. The original reporter (or a designated verifier) must now re-test.
Closed — Re-testing confirms the fix works and no regression was introduced. The defect is closed.
Reopened — Re-testing reveals the fix is incomplete or introduced a new problem. The defect goes back to the developer.

Track your reopen rate. A high Reopened count is a leading indicator of poor root-cause analysis: developers are patching symptoms instead of fixing underlying causes. If you see more than 15–20% of defects being reopened, raise it in your status report as a quality risk.

Logging a Defect Well

A defect report that cannot be reproduced wastes everyone's time. The analyst's responsibility — whether logging defects personally or coaching testers — is to ensure every report contains enough information for a developer who was not in the room to reproduce the exact problem. The standard fields are:

Title — A precise, one-line description: "Online store: checkout total shows $0 when applying a 100% promo code" — not "Total wrong."
Environment — Browser/OS/device, build/version number, test environment name (Staging v2.3.1, Chrome 124, Windows 11).
Preconditions — What must be true before you start: "User is logged in, cart contains 2 items, promo code SUMMER100 is active."
Steps to reproduce — A numbered sequence that reliably triggers the defect. If the bug is intermittent, document frequency.
Actual result — Exactly what the system did.
Expected result — What the approved requirement or acceptance criterion says should happen, with a reference (e.g., REQ-142).
Severity — The technical impact: Critical / High / Medium / Low (see below).
Priority — The business urgency: how soon must this be fixed?
Attachments — Screenshots, screen recordings, log extracts, network traces.

Severity is not Priority. A broken "Export to PDF" button on the admin reports page may be High Severity (a named feature is completely unavailable) but Medium Priority (finance runs reports once a month, release is in two weeks). Conversely, a spelling error on the login page may be Low Severity but High Priority because the CEO will see it during tomorrow's demo. The BA often mediates between testers (who set severity) and the product owner (who sets priority).

Severity Classifications

Most organisations use a four-level severity scale:

Critical (S1) — System crash, data loss, security breach, or a core workflow completely blocked with no workaround. Example: the clinic booking system crashes when a receptionist attempts to cancel an appointment.
High (S2) — Major functionality broken, but the system still runs. A workaround may exist but is impractical for daily use. Example: the logistics portal cannot generate shipment manifests — staff must create them manually.
Medium (S3) — A feature works but not correctly in certain conditions. A workaround is available. Example: the online store shows the wrong currency symbol for users in the EU.
Low (S4) — Cosmetic or minor issues: wrong label, slight alignment issue, a tooltip with a typo. System functionality is unaffected.

Triage: The Decision Meeting

Triage is a brief, structured meeting (often daily during active testing) where the team reviews newly logged defects and assigns each one a status, severity, priority, and owner. Typical attendees: the QA lead, the BA, the development lead, and the product owner. The BA's contribution to triage is critical: you can speak to whether the actual behaviour contradicts a documented requirement (defect) or is simply undocumented territory (possible enhancement), and you can articulate business impact to support priority decisions.

During triage, every defect in New state must exit triage in one of four states: Open (valid, scheduled for this release), Rejected (not a defect), Deferred (valid but not this release), or back to New if more information is needed from the reporter.

The Defect Report — A Worked Example

Here is a well-formed defect record for the clinic booking system:

DEFECT REPORT
=============
ID:            DEF-0047
Title:         Booking confirmation email shows doctor name in Arabic
               regardless of patient account language preference
Environment:   Staging v1.4.2 | Chrome 124 | Windows 11
Severity:      High (S2)
Priority:      High — affects all EN-language patients; UAT in 3 days
Reporter:      Sara (QA), 2026-06-10
Assigned To:   —  (pending triage)
Status:        New

Preconditions:
  1. Patient account language is set to English.
  2. At least one appointment is booked (Doctor: Dr. Ahmed Al-Rashid).

Steps to Reproduce:
  1. Log in as patient (testuser_en@clinic.test).
  2. Book a new appointment with Dr. Ahmed Al-Rashid, 10:00 AM.
  3. Complete payment and submit.
  4. Open the confirmation email received at the test inbox.

Actual Result:
  The email subject and body display the doctor name as "د. أحمد الراشد"
  (Arabic script) instead of the English transliteration.

Expected Result:
  Per REQ-088: "All system-generated communications shall use the
  language set in the patient account profile."
  Expected: "Dr. Ahmed Al-Rashid" in the email body.

Attachments:
  confirmation_email_screenshot.png
  email_log_excerpt.txt

Always link the defect to the requirement it violates (here: REQ-088). This connection feeds the Requirements Traceability Matrix, allows the project manager to assess impact across related requirements, and makes it easy to re-test against the correct acceptance criterion once the fix is deployed.

Defect Metrics and Quality Reporting

Defect data is project intelligence. The BA and QA lead should track and report key metrics regularly:

Defect discovery rate — new defects per day/sprint. A rising rate late in the project is a danger signal.
Defect closure rate — defects closed per day/sprint. If the closure rate is consistently lower than the discovery rate, the backlog is growing.
Open defect count by severity — the number of S1 and S2 defects open is a direct input to release-readiness decisions (covered in Lesson 9).
Reopen rate — percentage of closed defects that were reopened. High reopen rate signals poor fix quality.
Age of open defects — defects that have been open for more than one sprint without movement often indicate either resourcing gaps or scope disputes that need escalation.

A typical defect burn-down chart: open defects peak mid-testing then decline as fixes are verified. The closure line should overtake the open line before the release gate.

Common Defect Management Anti-Patterns

Watch for these failure modes on real projects:

Verbal defects — Testers report issues in chat or email and never log them. Fixes happen but are untraceable and unverifiable. Mandate: if it is not in the tracker, it does not exist.
Severity inflation — Every defect is logged as Critical to get attention. This desensitises developers and distorts release-readiness data. Triage must enforce consistent standards.
Zombie defects — Defects that sit in In Progress or Fixed for weeks without re-testing. Assign a triage action item to any defect that has not moved in five business days.
Close without verify — The developer marks a defect Closed after applying a fix, without an independent re-test by the original reporter. This is a process violation; the person who found the bug should verify the fix.

Never pressure testers to close defects to hit a release date. If a project manager asks QA to close open defects "to clean up the tracker" before a milestone, that is falsifying quality data. The correct response is to defer non-critical defects explicitly (with stakeholder sign-off) so the tracker reflects reality — not to close issues that have not been fixed.

The Analyst's Role in Defect Management

Systems analysts are not passive observers of the defect process. Your concrete contributions are:

Requirements author — You wrote the baseline that defects are measured against. When a defect's expected result is unclear, the team comes to you to clarify the original intent.
Triage participant — You distinguish defects from enhancements and articulate business impact to inform priority.
Defect analyst — You spot patterns. If five defects all involve the patient scheduling module, that signals a systemic requirements or design issue in that area, not just five random bugs.
Re-test verifier — For acceptance-level defects, you may be the right person to re-test, because you understand the business scenario the defect violated.

Summary

A defect is a deviation from a documented requirement or acceptance criterion — not merely something a tester dislikes.
The defect lifecycle moves from New → Open → In Progress → Fixed → Closed, with branching paths for Rejected, Deferred, and Reopened states.
A well-formed defect report includes title, environment, preconditions, numbered reproduction steps, actual result, expected result (with requirement reference), severity, priority, and attachments.
Severity measures technical impact; priority measures business urgency — they are independent and must be set separately.
Triage is a structured decision meeting that confirms validity, sets severity and priority, and assigns ownership.
Defect metrics — discovery rate, closure rate, open count by severity, reopen rate — provide objective release-readiness evidence.
The analyst's role spans requirements authorship, triage participation, pattern analysis, and acceptance-level re-testing.