Defect Management
Cross-Functional Defect Management
Although one of our Test Managers typically owns the overall defect management process and the defect management tool, a cross-functional team is generally responsible for managing the reported defects for a given project.
In addition to the Test Manager, participants in the defect management committee typically include development, project management, product management, and other stakeholders interested in the software under development.
As anomalies are discovered and entered into the defect management tool, the defect management committee should meet to determine whether each defect report represents a valid defect and whether it should be fixed or deferred. This decision requires the defect management committee to consider the benefits, risks, and costs associated with fixing or not fixing the defect.
If the defect is to be fixed, the team should establish the priority of fixing the defect relative to other project tasks. The Test Manager and test team may be consulted regarding the relative importance of a defect and should provide available objective information.
A defect tracking tool should not be used as a substitute for good communication, nor should defect management committee meetings be used as a substitute for the effective use of a good defect tracking tool. Communication, adequate tool support, a well-defined defect lifecycle, and an engaged defect management committee are necessary for effective and efficient defect management.
Defects may be introduced at any point in the software development lifecycle and in any software-related work product. Therefore, each software development lifecycle should include activities to detect and remove potential defects.
We generally use JIRA or DevOps Azure for defect management reports through the defect lifecycle. A defect report typically progresses through a workflow and moves through a sequence of states as it continues through the defect lifecycle.
In most of these states, a single defect lifecycle participant owns the report and is responsible for carrying out a task that, when completed, will cause the defect report to be moved to the next state.
Sometimes, an anomaly occurs not as the symptom of a defect but rather due to a problem with the test environment, the test data, some other element of the testware, or the tester’s misunderstanding. If the tester opens a defect report that subsequently is found not to relate to a defect in the work product under test, that is a false-positive result.
Such reports are typically cancelled or closed as invalid defect reports. In addition, in some cases, a defect can exhibit different symptoms, which may appear to the tester(s) as being entirely unrelated. If two or more defect reports are filed that subsequently are found to relate to the same root cause, one of the defect reports is typically retained while the others are closed as duplicate defect reports.
While invalid and duplicate defect reports represent a certain level of inefficiency, some of such reports are inevitable and should be accepted by the Test Manager.
When managers attempt to eliminate all invalid and duplicate defect reports, false negatives typically increase since testers are discouraged from filing defect reports. This decreases the testing organization’s defect detection effectiveness, which is related to a critical testing organization objective in most cases.