Defect Triage Meeting
Defect Triage, also known as Bug Triage, is basically used in software testing. It is required to explain the severity and priority of the defects. Severity is defined as degree of impact defect has on development or operation of component application that is being tested. Priority is defined as order in which defect is needed to be fixed or solved. Defect triage is basically process that simply tries to do re-balancing of the process where the test team usually faces problem or issue of less availability of resources that are required. In defect triage, defect is generally prioritized simply on the basis of its severity, reoccurrence, risk, etc.
Triage is French word whose meaning is “Sorting”. Testers usually identify defect or bug and then assign degree of risk, reoccurrence and severity on it. When the number of defects is more and number of testers to verify defects are less or limited, defect triage to used to help to solved and fix as many defects simply on the basis of defect parameters i.e., severity and priority.
Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the CS Theory Course at a student-friendly price and become industry ready.
What is Defect Triage Meeting?
In this meeting, discussion is done on each of every defect or bug. Severity and priority of defects and bugs are decided in this meeting. Main goal or target of this meeting is to evaluate or identify, prioritize, and assign or give solution of defects or bugs. Several questions also arise during the meeting as given below :
- Bug is valid or not?
- Defect is reproducible or not?
- Defect is worth fixing or not?
- When to fix defect or bug?
Defect Triage Meetings, as the name suggests, are project meetings in which defects or bugs are sorted or characterized into different categories. These categories are given below :
- Defects to fix now : All Defects that are needed to fix or resolved at present or immediately and cause greater damage comes under this category. There are several resources available to fix and resolve defects that come under this category.
- Defects to fix later : All Defects that are not needed to fix or resolved at present and cause less damage comes under this category. These defects can be resolved later.
- Defects we’ll never fix : All Defects that are does not cause any damage to system and are not required to fixed or resolved comes under this category.
Frequency of defect meetings usually depends upon project situation. Frequency of Defect Triage Meeting is decided on the basis of several factors as given below :
- Project Schedule
- Total number of defects in the system
- Impact on schedule of team members and their availability
- Project Health
What all points should be included while triggering the defect or bug?
- To check if information that is provided by tester is enough in defect so that developers can understand defects without any problem or issue.
- To check if defect is logged under correct or right project and module.
- To check if both Severity and Priority fields are provided for each and every bug or defect. This is because triage process is considered good only if it assigns and modifies both defect severity and priority.
- To check if bugs of defects are divided into categories.