Defect Triage

The term "Triage" comes from the French verb trier, meaning to separate, sort, sift or select. Triage" is a medical term describing the process of determining the priority of patient’s treatment based on the severity of their condition. It refers to dividing wounded or sick people into three categories: those who will die no matter what you do, those who will recover even if unaided, and those who will recover only if aided. In a situation where there's too much to do, you must concentrate on the third group (Ex: Watch Pearl Harbor scene, showing situation in hospital after Japanese have bombed the harbor).

This term has been introduced to software quality assurance to describe the function of assigning a priority and severity to new defects, usually by addressing several new defects at once every few days or as necessary.

If your project is very small, or isolated from other business units, triage may not be very useful at all. Similar to an emergency room that receives one patient per hour. This is usually not the case with large business.

Triage in software development requires three parties be present. Project manager, development lead, and test lead must be present at this discussion. Test lead facilitates a bug triage with a bug tracking system. Test lead reads the description of the bug to everyone, product generally asks some clarifying questions, and testing and development go back and forth discussion the importance and impact of their point of view. All three parties come to agreement and understanding on the severity and priority, or “actionable priority”, of the bug or defect, and the defect is marked as Triaged. Consistent triage meetings are important to ensuring a clear product backlog and reducing the need for meetings to talk about priorities.

Triaging a bug involves making sure the bug has enough information for the developers and makes sense, bug is filed in the correct place, bug has sensible "Severity" and "Priority" fields.
Priority is Business; Severity is Technical. In Triages, team will give the Priority of the fix based on the business perspective. They will check “How important is it to the business that we fix the bug?” In most of the times high Severity bug is becomes high Priority bug, but it is not always. There are some cases where high Severity bugs will be low Priority (Ex: bug in module having least usage frequency or due to low reproducibility / not a real life scenario) and low Severity bugs will be high Priority (Ex: Incorrect version number).

Priority and Severity gives the excellent metrics to identify overall health of the Project. Severity is customer-focused while priority is business-focused. Assigning Severity for a bug is straightforward. Using some general guidelines about the project, testers will assign Severity but while assigning a priority is much more juggling act. Severity of the bug is one of the factors for assigning priority for a bug. Other considerations are might be how much time left for schedule, possibly ‘who is available for fix’, how important is it to the business to fix the bug, what is the impact of the bug, what are the probability of occurrence and degree of side effects are to be considered.