Defect Triage
Defect triage is the recurring meeting where new defects are reviewed, given a severity and a priority, assigned an owner, and accepted or rejected. Severity describes the impact on the business; priority describes the order of fixing. Triage exists so that the fix queue reflects a decision rather than the order things were raised.
What it contains
A triage process needs three things: a defect record with enough detail to assess, an agreed severity scale, and a group with the authority to decide. The defect record typically carries a description, steps to reproduce, the environment, the scenario it was found in, the raiser, screenshots or logs, and an initial severity proposed by the tester.
Severity scales are usually four levels running from complete blockage of a critical process down to cosmetic. What matters is that each level has a written definition, because severity determines both the fix queue and, later, whether the defect can be carried into go-live. Priority is set separately: a low-severity defect blocking a hundred testers can be a high priority; a high-severity defect in a process not used until quarter end can wait.
The output of triage is a status per defect — accepted, rejected as working as designed, duplicate, deferred, or converted to a change request — plus an owner and a target. That structure is what a defect log alongside the test cases is for.
How it is used
During a test phase, triage runs daily. It is short and it is decisions only: no debugging in the meeting. Attendance is usually a test lead, a business representative who can judge impact, a technical lead who can judge effort, and someone who can commit resource to the fix.
Between triage meetings, the numbers drive reporting. Open defects by severity, arrival rate against closure rate, and the age of the oldest open severity 1 or 2 tell you whether the phase will land. A backlog where arrivals exceed closures for two consecutive weeks will not converge without intervention, and that is the signal weekly reporting should carry rather than a total defect count.
Triage also runs after go-live, where it becomes the intake of the hypercare process, with production incidents joining the queue alongside residual defects.
Where it goes wrong
The most frequent failure is severity inflation. Every defect is raised as severity 1 because that is how testers get attention. Once a third of the log is severity 1, the scale carries no information and triage becomes a re-triage of everything.
The second is triage without authority in the room. Defects are discussed, no one can commit a developer or accept a business impact, and the meeting produces a list of things to check rather than a set of decisions.
The third is confusing defects with change requests. A system behaving as specified but not as the user hoped is a change, not a defect, and routing it through the change process with a cost and schedule impact is what keeps the defect log honest. Programmes that absorb these silently deliver scope they never priced.
The fourth is a deferral list with no owner after go-live. Defects marked "fix in hypercare" accumulate, hypercare ends on its scheduled date, and the list transfers to support as a surprise.
Related terms
Severity measures business impact; priority determines fix order. Defect log is the register triage operates on. Regression is a defect introduced by a fix. Deferral is a defect accepted into live running with a workaround. Change request is the correct route for behaviour that works as specified but is not wanted.
Questions
What is the difference between severity and priority?
Severity describes the impact if the defect occurs. Priority describes how urgently it should be fixed, which also accounts for how many people are blocked and when the affected process runs.
How often should triage meet?
Daily during an active test phase, and daily during early hypercare. Weekly triage lets a backlog build faster than decisions can clear it.
Who should attend defect triage?
Someone who can judge business impact, someone who can judge technical effort, and someone who can commit resource. Without the third, triage produces opinions rather than decisions.
When is a defect actually a change request?
When the system behaves as specified and the objection is to the specification. That route carries a cost and schedule impact, which is the point of separating them.