QA Q and A - Bug Triage

QA

Q&A

Question:  What is a Bug Triage?

Answer:  A meeting or discussion focused on an item-by-item review of every active bug reported against the system under test.  During this review, fix dates can be assigned, insignificant bugs can be deferred, and project management can assess the progress of the development process.  [R. Black]

In medicine, Triage is the process of prioritizing patients based on the severity of their condition, rationing patient treatment efficiently when there are insufficient resources for everyone to be treated immediately. 

The term dates back to World War I where French doctors treated battlefield wounded at stations near the front.  At its basic, triage aims to divide the wounded into three categories:

• Those who are likely to live, no matter what care they receive
• Those who are likely to die, no matter what care they receive
• Those for whom immediate care might make a positive difference in outcome

In software, Bug Triage is a way to allocate your scarce debugging, development, and testing resources among all open bugs so that your time is spent in ways that can most positively benefit the project.

During a Bug Triage Meeting, representatives from Project Management, Development, Testing, Support, and other areas gather and discuss the remaining open bugs.  Usually, the team attempts to:

• Note which bugs do not need to be fixed at all, perhaps because there will be no end-user impact
• Note which bugs can be fixed in at a later release (deferred)
• Note which bugs must be fixed immediately, perhaps because they are blocking further testing or demos
• Note which bugs must be fixed for this release, but not immediately

One of the key questions I like to ask about a bug during triage is "Would you be willing to delay the release until this bug is fixed?" copyrightjoestrazzere

To make a Bug Triage Meeting run effectively, the team should either come to the discussion with an understanding of the bugs which will be discussed, or a discussion about the bugs, their context, and associated risks should occur duing the meeting itself.

Often Bug Triage Meetings will only commence during that latter stages of a release, when all features have been delivered, and only bugs remain.  Depending on the nature of the release, the schedule, and the people involved, these meetings might take place weekly, or even daily.

Usually, the only topics open for discussion during a Bug Triage are:

• Should this bug be fixed at all?
• Should this bug be fixed now, or can it wait until later?
• If later, must the bug be fixed during this release, or can it wait until some future release?
• What is the relative priority of this bug versus other bugs?

Topics that should not be open for discussion during Bug Triage usually include:

• Blame for how the bug occurred, or why it wasn't discovered sooner
• Discussion of the overall architecture
• Debugging or redesigning
• Rescheduling of the release

Some teams consider it necessary to estimate in the Bug Triage Meeting how long it will take to fix a particular bug.  But some teams don't consider this estimate a valid discussion topic during the meeting itself.  I personally favor leaving this estimation out of the meeting.

Many teams will update the bug reports themselves either during the Bug Triage meeting, or immediately afterwards - adding the outcome of the Bug Triage decisions into the bug report, and chaning the bug's Status and Priority accordingly.

For other QA and Testing Terms, see: http://strazzere.blogspot.com/2010/04/glossary-of-testing-terms.html

---