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.

Finding Defects; Hard to Find

All testing focuses on discovering and eliminating defects or variances from what is expected. All testers need to identify these two types of defects:
1)  Variance from Specifications – A defect from the perspective of the builder of the product.
2)  Variance from what is Desired – A defect from a user (or customer) perspective.

Finding defects in a system is not easy. Some are easy to spot, others are more subtle. There are at least two reasons defects go undetected:
1)  Not Looking
Tests often are not performed because a particular test condition was unknown. Also, some parts of a system go untested because developers assume software changes don’t affect them.
2)  Looking, But Not Seeing
This is like losing your car keys, only to discover they were in plain sight the entire time. Sometimes  developers become so familiar with their system that they overlook details, which is why independent verification and validation is used to provide a fresh view point.

Impact of low severity bugs

It is a common practice of a developer to ignore bugs that have low severity. Such practice if followed only adds to problems by piling up the work to be done. Often in the end, defect triage is performed in which developers are directed to fix certain defects.

Question is that why low severity bugs manage to get high priority.

Well, to understand the answer, we have to consider different factors.

Negative perception of software: It is something that we all like to avoid all costs. A bunch of minor bugs builds up the negative perception of the software even if it is not affecting the core functionality.

Target Industry: Another factor that I would like to add is of product target industry. If the software for air crafts, medical or any such critical industry then even low severity bugs will have high priority.