The Purpose of Defect Triage

Posted by Michael Massiah on 12/03/2019

The purpose of a defect triage meeting is to review and prioritise open defects and provide stakeholders with the opportunity to track progress, review and take action based on the information available.

Defect Triage Meeting

An effective defect management and triage process must do a few things:
  • Provide a definitive process for the reporting, fixing and retesting of defects.
  • Provide the opportunity to assess and gain consensus that the right defects are being resolved in the correct order for a release or product.
  • Ensure the right bug is assigned to the correct owner.
  • Deliver a re-usable and scalable format for any size of project.
Preparation
The preparation for the triage meeting is equally as important as the triage itself. Before testing starts you will have communicated with your stakeholders on the frequency of the triage meeting, and what is required by them to fulfil their respective roles during the triage meeting. The more effort that can be put in to the preparation, the greater likelihood for a meeting where everyone is in agreement of the outcomes and way forward.
  • As part of the test strategy, communicate the difference between priority and severity. Priority being the importance to the project/delivery and order to resolve, over the Severity that defines the extent the defect impacts the application or system.
  • All bugs should have been assessed for correctness before the meeting, there's nothing worse than reading a defect with incomplete information. Defects like these should be corrected in advance of the meeting.
  • If you're using a defect management tool, then make sure that your meeting attendees have access to the list, if they don’t then provide a list of bugs to be evaluated, reviewed and prioritised.
  • Whenever possible confirm the correct owner of defects outside of the meeting.
  • If there is ambiguity on the severity of a defect, speak to the product owner, business analyst in advance of the meeting and get an agreed view.
The Meeting
The triage meeting is generally run by the test manager, or someone with the role of defect manager within the project and the defect report should be made available before the meeting, then during the meeting:
  • The new defects are reviewed, agreeing that the correct priority and severity has been assigned, if not corrections are made as needed.
  • New defects are checked that they've been assigned to the correct owner or rejected as defects for closure with no further action.
  • Be prepared to demonstrate the defect again, so that it can discussed in context of the priorities.
  • A review on the progress of defects still open since the last triage is carried out. Is there new information available regarding risks and dependencies that would change the original priority assessment.
  • Steer the meeting away from going into issue resolution.

Outcomes
The output of triage meetings should provide answers to, “we agree it's a defect”, “all the defects reviewed are in the correct priority order”, “the defect sitting with right owner” and “we haven’t got any defects are not sitting unowned and unaddressed.”

The defect triage does not have to be complex and by adopting the principles above you can put in place a process that increases your projects effectiveness with an overall aim of releasing better software.

A How-To Guide For Test Planning

Topics: Software Testing, Test Planning, Defect Triage

nFocus Blog

Welcome to the nFocus software testing blog. As thought leaders and technical innovators, we created this blog to distil our thoughts, ideas and musings on improving software quality.

Fill out the form below to receive future communications from nFocus including our latest:

  • Blog articles
  • White Papers
  • and plenty more!

Follow us

Follow us on LinkedIn to see our latest content!

Subscribe Here!

Recent Posts

Posts by Topic

see all