QA Process
Defect Triage Guide.
Defect triage is the regular meeting where the team reviews open bugs and decides what to do with each one. This guide covers who attends, what to prepare, the decisions you can make, and a checklist for reviewing any defect.
When to use it
Use this to set up or tighten a triage meeting — during a release crunch, when the defect backlog is growing faster than it's shrinking, or when bugs sit untouched because no one owns the decision.
Who uses it
QA leads who run triage, QA engineers who present defects, and the product owners and engineers who decide fix-or-defer in the room.
On this page11 sections
WHAT IS DEFECT TRIAGE
Defect triage is a recurring review where the team looks at open defects and decides, for each one, what happens next: fix it now, fix it later, reject it, or get more information. The word borrows from medicine — sort by urgency, act on what matters most.
It is a decision meeting, not a debugging session. The goal is to leave with every reviewed defect having an owner, a severity, a priority, and a decision — not to solve the bugs in the room.
WHY TRIAGE MATTERS
Without triage, defects pile up unsorted: critical issues hide behind cosmetic ones, duplicates multiply, and "who decides this?" stalls everything. A regular triage keeps the backlog honest and gives everyone a shared view of release risk.
It also protects focus. Engineers get a clear, agreed list instead of a noisy tracker, and QA gets fast answers instead of bugs that sit untouched for weeks.
WHO ATTENDS TRIAGE
Keep it small and decision-capable. The core trio is a QA lead (runs the meeting and presents defects), a product owner (sets priority and accepts risk), and an engineering lead (judges effort and feasibility).
Pull in specialists only when needed — a security owner for a vulnerability, a designer for a UX call. A triage of ten people is a status meeting in disguise; a triage of three with authority moves fast.
WHAT TO PREPARE BEFORE TRIAGE
Triage is only as fast as its inputs. Before the meeting, make sure every defect up for review is reproducible, has clear steps, states its environment, and carries evidence — so the room reviews decisions, not missing details.
Sort the list by severity before you start, flag anything that blocks the release, and close obvious duplicates in advance. Five minutes of prep saves the whole room twenty.
HOW TO REVIEW A DEFECT
For each defect, walk a consistent path so nothing is decided on vibes: confirm it's reproducible, state the user and business impact, check severity matches that impact, then ask the product owner for priority.
Only then choose a decision type (below) and assign an owner and a target — this release, the backlog, or back to the reporter for more information. Capture the decision in the tracker before moving on; an undocumented decision gets re-litigated next week.
SEVERITY VS PRIORITY
Triage runs on two separate fields. Severity is how badly the defect breaks the product (a technical impact judgement, usually QA's); priority is how soon it should be fixed relative to other work (a business call, usually the product owner's).
Don't collapse them. A low-severity typo can be top priority before a launch, and a high-severity admin crash can wait if almost no one hits it. The full breakdown — levels, worked examples, and who decides — is in the Bug Severity vs Priority guide linked under Related.
TRIAGE DECISION TYPES
| Decision | When to use it |
|---|---|
| Fix now | Blocks testing or a release-critical path — it can't wait. |
| Fix before release | A real defect that must ship fixed, but isn't blocking work today. |
| Fix later | Valid but low impact — goes to the backlog with a priority. |
| Needs more information | Can't decide until repro steps, environment, or evidence are added. |
| Duplicate | Already reported — link to the original and close this one. |
| Cannot reproduce | No one can reproduce it — request detail or hold pending info. |
| Won't fix | A real issue, but a deliberate decision not to fix it (cost vs benefit). |
| Expected behaviour | Works as designed — the report is a misunderstanding. |
| Rejected | Not a valid defect — out of scope, test error, or invalid environment. |
TRIAGE MEETING AGENDA
A predictable agenda keeps triage to its timebox. A workable order:
1. Review new Critical/High defects first — these set release risk.
2. Confirm or adjust severity and priority for each.
3. Assign a decision type and an owner to every defect reviewed.
4. Re-check anything previously marked "needs more information".
5. Sweep duplicates and "cannot reproduce" items.
6. Summarise: what's blocking the release, and what changed since last time.
TRIAGE CHECKLIST
- Is the defect reproducible from the steps given?
- Is the user and business impact clear?
- Is the environment (build, OS, browser/device) stated?
- Are the steps to reproduce clear and complete?
- Is evidence attached (screenshot, video, logs)?
- Is the severity set correctly for the impact?
- Is the priority set correctly for the urgency?
- Is there a known workaround?
- Does it block the release?
EXAMPLE TRIAGE NOTES
What good triage output looks like — short, decided, owned:
BUG-412 — Checkout fails on Safari 17 with a saved card. Reproducible, evidence attached. Severity: Critical (payment path). Priority: P1. Decision: Fix now — owner: Payments team, target: this release.
BUG-418 — Order-confirmation email missing the VAT line. Reproducible. Severity: Medium. Priority: P2. Decision: Fix before release — owner: Comms team.
BUG-421 — Dashboard chart colours look slightly off on Firefox. Cosmetic. Severity: Low. Priority: P3. Decision: Fix later — backlogged.
BUG-423 — "App crashes sometimes." No steps, no environment, no evidence. Decision: Needs more information — returned to reporter.
BUG-426 — Same as BUG-412. Decision: Duplicate — linked and closed.