tldr: Defect triage is the recurring meeting where new bugs get a severity, a priority, an owner, and a target release. Severity measures impact on the system. Priority measures urgency to fix. Triage keeps the team fixing the bugs that matter, not the ones filed loudest.
What is defect triage?
The name comes from emergency medicine: sort by urgency when resources are limited. In software, new defects arrive continuously: from testers, from support tickets, from monitoring, from the team itself. Triage is the filter between "reported" and "scheduled." For each new defect, the group decides four things:
- Is it real, reproducible, and not a duplicate?
- How bad is it? That is severity.
- How soon must it be fixed? That is priority.
- Who owns it, and for which release?
Anything that fails the first question gets closed or sent back for a better reproduction, which is why report quality dominates triage speed. A defect with exact steps and environment takes a minute to route. A vague one burns the whole room's time or gets misjudged.
Two tickets from the same morning show the flow. Support files "checkout is broken"; it reproduces, but it is a duplicate of BUG-4412, so it gets linked and closed in thirty seconds. A tester files "coupon total wrong after currency switch" with exact steps: real, new, a classic calculation bug. High severity because money is miscalculated, priority P1, owner assigned, this release. Two tickets, three minutes.
Severity versus priority
The two axes are independent, and conflating them is the classic triage mistake.
| High priority | Low priority | |
|---|---|---|
| High severity | Checkout crashes for all users | App crashes on a legacy browser with 0.2% share |
| Low severity | CEO's name misspelled on the homepage | Slight misalignment on an internal admin page |
Severity is a property of the defect. Priority is a business decision about sequencing. A typo is cosmetically trivial and still jumps the queue when it embarrasses the company; a crash can wait when it affects almost nobody. Teams that let severity dictate priority automatically end up polishing rare crashes while visible customer pain ships.
Who attends, and how often
The working trio is a QA lead, an engineering lead, and a product owner: one to vouch for the defect, one to estimate cost, one to weigh business impact. Rhythm scales with inflow. During an active release, daily fifteen-minute sessions keep the queue near zero. In quieter stretches, twice a week is plenty. The queue size tells you when to change cadence.
Rules that keep triage fast
- Every defect leaves the meeting with an owner and a release, or gets explicitly closed. No third state.
- Timebox discussion per defect; two minutes is enough to route almost anything.
- Duplicates get linked in the defect tracker, not debated.
- A standing "will not fix" verdict is allowed and recorded, which is healthier than a backlog of bugs everyone privately knows will never be fixed.
Triage outcomes also feed measurement. Severity distributions over time, reopen rates, aging (time-in-queue by severity, the early sign that triage is slipping), and escaped defects reaching production are the signals that tell you whether upstream quality is improving, all covered under defect management and defect analysis.
One practical upstream fix: defects that arrive verified skip half the triage cost. Bug0 reports failures only after its forward-deployed engineer has confirmed the reproduction, precisely so triage time goes to deciding rather than to re-investigating.
FAQs
What is a defect triage meeting?
A short recurring meeting where new defects are validated, rated for severity and priority, assigned an owner, and scheduled into a release or explicitly closed.
What is the difference between severity and priority?
Severity is technical impact: how badly the defect damages functionality, data, or users. Priority is scheduling urgency: how soon the business needs it fixed. Each is set independently.
What is a typical severity scale?
S1 to S4, or Critical, Major, Minor, Cosmetic. Pick one, define each level with an example, and resist inventing a fifth. Scales fail by growing, not by being wrong.
Who sets severity and who sets priority?
QA or the reporter proposes severity, since it describes observed impact. Product owns priority, since it is a sequencing decision. Engineering weighs in on cost, which can move priority but not severity.
