5.6 Defect Management

Purpose of Defect Management

One major objective of testing is to find defects, but finding an anomaly is only the start. The team needs an agreed process for logging, analyzing, classifying, deciding what to do, tracking progress, confirming fixes, and closing reports. Without that process, defects get lost, duplicated, argued about, or fixed without evidence.

The word "defect" is used broadly in test work, but a reported anomaly may later be classified differently: a true defect, a false positive, a duplicate, a documentation issue, an environment problem, a test-data problem, a user misunderstanding, or a change request. The defect-management workflow resolves that classification rather than assuming every anomaly is a code defect.

Typical Defect Lifecycle

A simple lifecycle may include states such as new, open, analyzed, assigned, fixed, ready for retest, retested, closed, reopened, deferred, duplicate, rejected, or awaiting information. Organizations use different names, but each report always has a visible status and a controlled path from discovery to closure.

A typical flow is:

1. Log the anomaly with evidence.
2. Triage and classify it.
3. Decide whether to fix, defer, reject, accept, or convert it.
4. Assign ownership if work is needed.
5. Fix and build the change.
6. Confirm the fix through retesting (confirmation testing) and regression testing as needed.
7. Close the report, or reopen it if the issue remains.

The process should be followed by all relevant stakeholders: developers, testers, product owners, support staff, analysts, and managers may all interact with defect reports. It should also define classification rules so severity, priority, duplicates, rejected reports, and deferred defects are handled consistently.

Defect Report Objectives and Fields

A good defect report helps the people responsible for resolution understand the issue, and it supports quality tracking and process improvement. If many high-severity defects cluster around one module, supplier, requirement type, or test level, the team can improve its development and test process.

A poor report says "Checkout broken." A useful report states what was tested, what version was used, what steps were taken, what data was entered, what was expected, what happened instead, how often it happens, what evidence exists, and why it matters. The report should reduce investigation time, not transfer confusion.

Severity vs Priority

Severity and priority are different and independent. Severity is the impact of the defect on stakeholders or requirements. Priority is how soon the team should address it, driven by business need, timing, and workarounds.

• High severity, low priority: a crash in an obsolete admin screen that is disabled and scheduled for replacement.
• Low severity, high priority: a typo on a legal-disclosure page that must be correct before tomorrow's launch.
• High severity and high priority: a payment miscalculation in the live checkout path.

The four combinations show why the two fields are not the same value under different names; the exam tests this directly.

Reproduction and Evidence

Reproduction steps should be specific enough that another person can follow them: include preconditions, input data, user role, environment, configuration, and any timing requirements. For intermittent failures, include frequency, timestamps, logs, screenshots, recordings, or monitoring data, since "happens sometimes" is not actionable.

Expected and actual results should be concrete. "Should work" is too vague. "The invoice total should be $108.25 after tax" is actionable, and "The page displays $18.25" is actionable. The difference between the expected and actual results is precisely the failure being reported.

Static Testing Findings

Findings from reviews and static analysis can be handled through the same kind of disciplined process. A review comment about an ambiguous requirement or a static-analyzer warning may not need every field of a dynamic test failure, but it should still be logged, classified, assigned, and closed when the process requires evidence. Because static testing finds defects earlier and more cheaply than dynamic testing, disciplined handling of review findings is a strong shift-left contribution.

Using Defect Data for Improvement

Defect reports are not only resolution tickets; aggregated, they are a quality signal. Defect density (defects per size unit, such as per thousand lines of code or per module) highlights weak areas. Defect detection percentage, comparing defects found before release to those found after, measures how effective testing was. Trends in find rate and fix rate show whether discovery is slowing because quality is improving or because testing is blocked.

Classifying defects by root cause, phase introduced, and phase detected supports process improvement: if most defects originate in requirements but are caught only in system testing, the team should invest in earlier reviews.

This is why consistent classification fields matter so much. If severity, priority, component, and root cause are recorded uniformly, the data supports decisions; if they are entered ad hoc, the reports help one fix but yield no learning. The exam favors answers that treat defect management as both an operational workflow and a feedback loop into planning, risk analysis, and reviews, rather than as mere bug logging.

Exam Traps

• Severity (impact) and priority (urgency) are independent; any of the four high/low combinations can occur.
• Not every reported anomaly is a code defect; triage may resolve it as a duplicate, false positive, environment/data issue, or change request.
• Not every anomaly must be fixed immediately; triage may fix, defer, reject, mark duplicate, accept the risk, improve the test, or raise a change request, and the decision must be visible and controlled.
• A defect report's purpose is to enable reproduction, analysis, and improvement, not to express an opinion that the product is bad.