Page 188 -

Note that these criteria assume that there will be defects that will not be fixed. The goal of
test execution is not to remove every defect from the software; rather, it is to make the peo-
ple in the organization aware of the individual issues encountered during testing. This way,
everyone is aware of the risks (if any) involved in releasing the software, so an informed
decision can be made about whether or not to fix the defects and retest the software.

Defect Tracking and Triage

All defects that are found by the testers must be replicated, repaired, and verified. This
means that many people must be able to see and reproduce the behavior that causes each
defect. To do this, a defect report must be created for every defect found that includes:

• A name and a unique number.
• A priority (determined by the tester, but that may be modified later in defect triage).
• A description of the defect. The description must include the steps required to replicate
the defect, the actual behavior observed when the steps were followed, and the
expected results of the steps.

When a tester discovers a defect, it should be entered into a defect tracking system, a database
used for storing information about defects and routing them through a workflow of evalua-
tion and repair. There are many defect tracking systems available, including commercial sys-
tems and ones that are free and open source. Many of the metrics used to measure the
health of the product are gathered from the defect tracking system (see below). It is also use-
ful when planning regression tests: testers use it to keep track of defects that were repaired,
in order to verify that they were fixed before getting into the rest of the functional tests.
Once a defect is entered, the defect tracking system routes it between testers, developers,
the project manager, and other people, following a workflow designed to ensure that the
defect is verified and repaired. The specific workflow used to enter, evaluate, and repair
defects can vary from organization to organization. Minimally, the defect workflow should
track the interaction between the testers who find the defect and the programmers who
fix it, and it should ensure that every defect can be properly prioritized and reviewed by all
of the stakeholders to determine whether or not it should be repaired. This process of
review and prioritization is referred to as triage. This somewhat dramatic name comes from
the triage of patients in an emergency room: the patients with the most severe injuries
must get medical attention first. It is the same way with software defects, where the most
severe defects are given the highest priority.

Triage should be done by project stakeholders, or at least one person who is trusted by the
stakeholders to make those decisions for them. It is important to be sure that the person or
people who are responsible for the quality of the application are given control over the
defect triage process so that the high-priority bugs get fixed. In some organizations, one
senior-level manager reviews and makes decisions on contentious bugs. In others, individ-
ual team members are empowered to make release decisions on their own. One manager
in a room may decide all of the priorities on the defects, or the team may meet and review
each defect to determine which ones need to be fixed and which do not. However, it is

180 CHAPTER EIGHT