A complete guide to Defect Triage Process and Effective ways to handle Defect Triage Meeting:
In today’s article, we will learn about Defect Triage meeting and how to handle a triage meeting in an easier and effective way.
Before proceeding further with this article, I wish that everyone knows what is meant by a Defect, Defect Life Cycle, and how to set Priority & Severity for each defect. And it is necessary to understand these basic concepts related to a defect or bug.
What You Will Learn:
The word “Triage” is basically used in the medical field. Actually, it used to decide the order in which the patients should be treated. Usually, in big hospitals, where there are thousands of patient’s approaches for consultation or actual treatment on a daily basis. But not all the patients are admitted or treated immediately.
The severity of the illness or the injury is the main criteria for consultation and based on this all the patients are categorized accordingly. If the injury or health of any patient is very critical then the doctors usually treat such patients as a priority and get admitted if required.
Normal diseases or non-critical injuries are considered at a lower priority and such patients are treated later.
Similarly, the term Triage is introduced in software testing for defects in the application or a project. Usually, the Defect Triage process is implemented in large projects and in many cases, it is not applicable for small-scale projects. There are chances to identify a huge number of defects in bigger projects than medium or small projects.
Also in bigger projects, the frequency of defect identification is quite higher.
Take a look at the below image which shows the outcome of Defect triage meeting and gives answers to specific questions like:
Defect Triage Meeting
The main objective of a triage meeting is to track all the defects and ensure the correct resolution in a timely manner.
During the test execution phase, the testers start reporting defects in the Defect Management tool like HP ALM, QC etc. Then Defect Triage Meeting is held in which the developers and testers are required to be present as these people will discuss all the defects and take the necessary further course of action.
Mainly the presence of the below participants is required mandatorily:
- Project Manager
- Test Lead
- Development Lead or Developer
- Test Manager
- Business Analyst
- Environment Manager
Although I have given an exhaustive list of all the participants in the meeting, it is not necessary to involve all of them like Business Analyst, Environment Manager, Test Manager, etc in the daily meeting. Whenever necessary the Test Lead or Project Manager invite them and they can share their valuable feedback and opinion regarding a specific defect.
And the entire team is known as a Triage Team. Now, I'm going to explain the exact process of triage meeting and how this meeting is set-up.
Consider one hypothetical Example: We have one project related to the Banking application, size is very large and the frequency of identifying and reporting the defect is high. Hence the Test Lead decides to set-up a Defect Triage Meeting with the required participants.
For setting up a meeting the Test Lead sends a meeting invite via email to everyone and sets a particular timing for Triage Meeting. The below given hypothetical image shows the meeting invite sent by a Test Lead via outlook to all the participants.
Here everything is imaginary in the below image like – the participant names, meeting room, conference call details, date, time etc.
(Note: Click on any image for an enlarged view)
Every day before the start of the triage meeting, the Test Lead sends a list of all the “Open” defects is a spreadsheet format to all the participants so that they can go through all the defects before the meeting and understand what exactly the defect is and what kind of fix is required for it.
Before the start of every triage meeting, ensure that each defect:
- Has enough information to understand the defect for all the participants in the meeting.
- Has reported under correct project and category.
- Has mentioned the priority and severity of the defects.
- All the detailed information provided in the defect to understand it correctly to all the participants.
Recommended Read => A Complete Guide to Defect Management Process
Defect Triage Template
Before the kickstart of every Defect Triage Meeting, the Test Lead shares the defect report to all the participants in a specific format and the report pulled out from the Defect Management Tool like HP ALM, HP QC etc. I am showing one sample format in the below image which will give a high-level idea of which fields are mentioned in the Defect Report Template.
Usually, the fields included in the defect report are:
- Defect ID
- Detected Date
- Detected By
The list is not exhaustive but as per the project need, the other fields in the defect report template can be included.
Usually, the spreadsheet format is used as a template for defect reporting, hence I have given the hypothetical defect details in the spreadsheet format. Please note that all the information provided in the above defect report is only imaginary and not related to any project or actual application.
Defect Triage Process
A commonly heard and experienced situation in test teams is limited availability of resources. Defect triage is a process which tries to do some re-balancing as a result of this phenomenon. So when there are many defects and limited Developers/testers to fix/verify them, defect triage helps to get as many defects resolved as possible by balancing the technical personnel based on defect parameters like priority and severity.
Typically, a defect triage session is attended by the Product Manager, a development lead, a test lead and sometimes business analysts. In some cases, certain other members may also be invited to give their opinions and perspectives regarding certain defects. These are collectively called a triage team.
Most systems use priority as the main criteria to assess the defect, however, a good triage process considers the severity as well.
Let's take a closer look at the triage process with two examples that we've talked about in the previous section. In both the examples above, it would actually be the first defect that would be given a very high priority. Despite it being only a cosmetic defect, the impact of not fixing would be huge.
The second one, on the other hand, is a surely functionality defect, however, its occurrence is in only certain conditions which are seldom practiced customer scenarios. Fixing it may need more time and people, which could be better utilized for other defects. Hence it would deem lower priority than that of the first and maybe deferral candidate to another release.
Thus the triage process involves triage team sitting down together, reviewing all the defects including rejected defects. They draw an initial assessment of the defects based on its content, their respective priority, and severity settings; with each person in the triage team presenting their perspective on how to prioritize the defects.
The product manager then sets the priority based on all the inputs and assigns the defect to the correct release I.e. in the current release or any future release. He also redirects the defect to the correct owner/team for further action. Rejected defects also are put through a similar analysis. Based on the reason for rejection, the futuristic action of whether it needs to be deferred or canceled is determined.
In the triage meeting, each and every defect should be discussed including the defects which are categorized as a lower priority one. The triage team review evaluates all the defects and takes necessary action on each defect. If a defect is running short of information then the developer assigns back such defects to the testers and requests for necessary information.
The triage meeting can be held in the meeting room if all the participants are at the same location. But in many organizations, the work is carried out from a different location and all the teams are spread across various locations so that the meeting is also held using teleconference or business Skype.
Step by step process of the defect triage meeting:
- Test Lead kicks off the meeting with the defect report which was sent earlier on the day.
- The discussion starts with the actions pending from the previous triage meeting. The necessary updates or action that was taken on any defect is discussed initially.
- If there are new defects in the defect report then these defects are reviewed and evaluated. It also verifies if the priority and severity are assigned properly, if not, then these are corrected in the meeting.
- All the defects are discussed in the meeting and the development team also discusses the complexity of fixing the defect. The risk associated with the defect is also discussed by the triage team.
- Triage team comes to a conclusion on, which defect should require immediate attention & fix and which defect needs to wait for some time and if required those defects can be postponed to future releases.
- All the defects are assigned to the respective team in QC or ALM simultaneously during the meeting. Appropriate comments are also added in the QC/ALM.
- All the essential updates and action items are noted down and the Test Lead calls out for the end of the meeting.
- After triage meeting completion, Test Lead sends out minutes of meeting to all the participants.
Roles and Responsibilities
Roles and responsibilities based on each category are explained below:
- Test Lead schedules a defect triage meeting and sends out a formal meeting invite to the required team.
- Sends the defect report before every triage meeting.
- Kicks off the meeting with the pending action items from the previous triage meeting.
- Discuss each defect and impact on the schedule if any functionalities are blocked due to the defect.
- Helps in assigning priority and severity of each defect if it was not assigned correctly earlier.
- Update the QC/ALM with appropriate comments.
- Note down all the updates, action items, risk related to a defect, etc.
- Sends minutes of meeting to all the participants.
- Share updates on the action items pending from the last triage meeting.
- Discuss all the defects from a technical perspective.
- Identify how much time it will require for fixing based on the complexity of the defect and functionality.
- Discuss the complexity of the defect and risk associated with the defect if any.
- Development Lead assigns defect to the appropriate developer after validating all the available detailed information.
- Updates the defect with the expected resolution date.
- Assists in identifying the root cause of the defect.
- Ensure that if all the representative from every area is available for the meeting.
- If necessary, project manager invites Business Analyst in the meeting for their opinion on a specific defect.
- If the defects are not moving or if there is any major blocker then escalates with the escalation process.
- If required, acts as a mediator if any dispute or conflict happens between the teams and takes the necessary decision.
- Take the confirmation from the development team for the next release date for fixed defects.
- Make aware of the updated schedule and release date of the project to all the teams.
At times, it is also a good idea to involve the other team members in the triage call so that they can also understand and contribute to the meeting and if required they can also provide their feedback.
Every defect logged should be discussed at the triage meeting.
Even if a defect is rejected, the testing team should know the reason for rejection. Also if any of the defects is not reproducible then during the triage meeting the developer can ask the testers for real-time details and they can try to reproduce the defect.
Defect Triage is important as everyone will know when the defect will get fixed and be available for re-test. If any of the defects is non-critical and in order to fix the defect, it requires huge efforts from the development team and the decision will be taken by the project manager.
The project manager will decide the priority of such defect and if required the defects can be postponed to the next release.
Hope you would have got a clear idea of Defect Triage, Defect Triage Process and ways to effectively handle Defect Triage Meetings!