Defect Triage Process Steps

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.

• 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. 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.