Section 8.3. Defect Tracking and Triage


8.3. 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 evaluation and repair. There are many defect tracking systems available, including commercial systems 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 useful 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, individual 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 generally not the sole responsibility of the tester to make such decisions. One of the most effective ways to determine release-readiness is to have the entire project team reach a consensus on which defects are important to fix and which can be released in the product.

While it is one of the most straightforward concepts in quality assurance, triage is also one of the most important and time-consuming. Every single defect must be reviewed and prioritized. This can mean daily meetings for project stakeholders, and it is often difficult to delegate this responsibility because only the stakeholders really know whether a defect will prevent the users from doing their jobs.

In other words, there is an important division of responsibility. The testers are only responsible for reporting what they see when they use the software. They are not in a position where they can judge whether the defects they find will impact the organization. That's not their focus, and they do not have the expertise to make those judgements. Only a person who has a real stake in the software can use that information to judge its health. A software crash that is caused using certain steps or data may seem very important to a tester; someone with a lot of knowledge of the way the users will use the software might see an obvious workaround that will make perfect sense to them, or see that the users would not encounter that crash at all. That does not mean the software should be released if it crashes, but it does affect the priority of that bug being fixed.



Applied Software Project Management
Applied Software Project Management
ISBN: 0596009488
EAN: 2147483647
Year: 2003
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net