Defect Triage

Purpose and participants

Triage sits between New and Open in the defect lifecycle. Its purpose is not to fix anything but to make four decisions quickly and record them: is the report valid, how severe is it, how urgent is it, and who does what next. Each decision has an owner, and mixing the owners up is the most common cause of slow or political triage.

• Test lead or QA representative — presents the defect and its evidence, confirms reproducibility, proposes severity from the agreed scale.
• Product owner — owns priority and the business decisions: defer, won't fix, accept a risk for this release.
• Development lead or on-call engineer — owns assignment and gives a first technical view of cause and effort.
• As needed — support or operations for production defects, a security owner for security-relevant defects, a designer for "is this by design?" questions.
• Rule of thumb — QA proposes severity, the product owner sets priority, the development lead assigns; a disagreement is escalated once, and the decision and its reason go into the record.

Cadence and meeting format

Cadence follows the arrival rate and the release phase. During system testing and release hardening a short daily session is normal; in a steady sprint two or three sessions a week are usually enough. Blocker and Critical defects, and anything affecting production, are not held for the meeting: they are triaged immediately and asynchronously by whoever is on duty, and the meeting only confirms the decision.

Much of the work can be done before the meeting. The QA lead pre-screens new reports for completeness and duplicates and sends incomplete ones back to Needs info, so the session spends its time on decisions rather than on reading.

• Record decisions in the tracker during the session, not in meeting notes or chat.
• Keep the group small: people who can decide, not everyone who is interested.
• Measure the process: untriaged count, age of the oldest untriaged defect, time from New to a decision.

Defect triage - 20 minutes, daily during release hardening

00-02  Queue check: number of New, oldest untriaged, any Blocker/Critical since last session
02-15  New defects, highest proposed severity first, 1-2 minutes each
       Presenter: reporter or QA lead. On screen: the defect record, not a slide.
15-18  Aged or disputed items: Needs info > 3 days, Deferred due for review, reopen disputes
18-20  Read back decisions; each owner confirms

Rule: anything that needs more than 2 minutes leaves with an owner and a written question.

The triage checklist

Run every new defect through the same questions in the same order. The first two are gates: if the defect cannot be reproduced or evidenced, or the report is incomplete, it goes to Needs info with a specific question and does not stay in New.

[ ] Reproducible?   Steps run by someone other than the reporter, or evidence strong enough for an
                    intermittent failure (logs, request id, timestamps, recording)
[ ] Complete?       Build, environment, account/role, data, expected vs actual
[ ] Duplicate?      Searched by error text, endpoint or screen, component; linked if found
[ ] Valid?          Expected result traced to a requirement, design or clear convention
[ ] Severity        Impact on user/system on the agreed scale (Blocker ... Trivial)
[ ] Priority        Business urgency (Highest ... Low): release date, users affected, visibility
[ ] Owner           A named person, or a team queue with a named lead - not "dev team"
[ ] Target release  Version or sprint; or Deferred with reason; or Won't fix with reason
[ ] Workaround      Exists? Written down for support and the release notes
[ ] Info needed     The exact missing item and who must provide it
[ ] Links           Story/requirement, test case, related defects, incident (if production)

Try it: AI Bug Severity Suggestion Try it: AI Bug Priority Suggestion

Severity × priority: a decision matrix

The bug report guide defines both scales: severity Blocker, Critical, Major, Minor, Trivial; priority Highest, High, Medium, Low. Severity is impact and priority is urgency, so any combination is possible. The matrix below gives typical decisions with examples; it is a starting point for the discussion, not a formula — the product owner may move priority, but the reason is recorded.

• A Blocker or Critical defect with Low priority needs a written reason: the feature is switched off, the date is far away, or no user can reach it.
• Trivial or Minor with High or Highest priority is usually about visibility: legal text, the brand, a demo, a screen a regulator or a key customer will see.
• Priority is not lowered to meet an exit criterion; severity is not changed without new evidence.
• The AI Bug Priority Suggestion tool expresses its suggestion on a P0–P3 scale, from P0 (fix immediately) to P3 (backlog). Keep a written mapping to your tracker — for example P0 → Highest, P1 → High, P2 → Medium, P3 → Low.

Severity x Priority   Example defect                                          Typical decision
--------------------  ------------------------------------------------------  ------------------------------
Blocker  x Highest    Login returns 500 for every user in production          Hotfix now, incident open
Critical x Highest    Checkout charges the wrong VAT amount, release in 7 d   Fix before release; blocks sign-off
Critical x Low        Quarterly admin export drops rows; next run: 10 weeks   Schedule; set a review date
Major    x High       Orders list ignores date filter; workaround: sort       Fix in this release
Major    x Medium     Bulk import over 5 MB fails with no message; rare       Next sprint
Minor    x High       Arabic error text shows an English placeholder on the   Fix before a launch campaign
                      national ID field of the sign-up form
Minor    x Low        Tooltip clipped at 320 px width in the Arabic layout    Backlog
Trivial  x High       Company name misspelled on the login page               Quick fix; high visibility
Trivial  x Low        Extra space in the footer copyright line                Backlog; batch with copy fixes

Try it: AI Bug Severity Suggestion Try it: AI Bug Priority Suggestion

Assignment and investigation

Assign by ownership, not by who happens to be in the room: the component or service owner, or a team queue with a named lead who distributes within a day. A defect assigned to "the team" has no owner. When the cause could sit in several layers — app, API, data — assign it to the layer where the failure is observed and let that owner hand it on with evidence, rather than holding it in triage until someone guesses right.

Investigation is the owner's work after triage, and it should be time-boxed. If a defect cannot be reproduced within the agreed time, it returns to Needs info with the list of what was tried, or is resolved as cannot reproduce with the evidence kept.

• Reproduce with the reporter's data in the reporter's environment first, then locally.
• Find the last good build and narrow the change range; with git, bisect the commits in between.
• Compare a working and a failing case — web against Android, one account against another — at the request level: capture both requests and diff the responses.
• Read the stack trace from the first frame in your own code; check configuration, feature flags and data before changing code.
• Write findings into the defect record, not only into chat, so the next person does not start again.

Try it: AI Error Message Analyzer Try it: HTTP Request Inspector Try it: cURL Generator Try it: API Response Analyzer

Root cause analysis: 5 whys, fishbone and origin

The fix removes one defect; root cause analysis asks why the error was made and why it was not caught earlier, so that the same class of defect is prevented. The ISTQB Foundation syllabus separates the root cause from the defect and from the failure it causes. Run a root cause analysis for Blocker and Critical defects, production escapes and recurring patterns — not for every typo.

The 5 whys technique asks "why?" repeatedly, starting from the failure, until the answer is a process cause the team can change. Five is a heuristic, not a rule; stop when the answer is actionable, and branch when one answer has several causes. A fishbone (Ishikawa) diagram lays the candidate causes out by category so that the discussion does not fix on the first plausible one. For software, useful categories are the same as the origin classes below, plus people and process.

Classify each defect by where it originated. IEEE 1044 defines a far richer set of attributes for classifying anomalies; the six origins below are a simple starting point that most teams can apply consistently in triage.

• Requirements — missing, ambiguous, wrong, or changed without the change reaching every consumer.
• Design — an architecture or interface decision that is wrong or inconsistent.
• Code — an implementation error: logic, boundaries, null handling, concurrency, duplicated logic.
• Environment — configuration, infrastructure, versions, a third-party service, deployment.
• Data — unexpected, malformed or badly migrated data; wrong reference data.
• Test — the defect was in the test itself (a false positive), or a test gap let it escape; record test gaps as contributing causes.

Worked example: root cause of a VAT defect

A fictional example, continuing the defect followed in the defect lifecycle guide: an Android checkout charged 190.00 SAR instead of 184.00 when a fixed-amount coupon was applied, because VAT was calculated before the discount.

• The analysis ends in process changes with owners and dates, not in a person to blame.
• The primary origin is where the defect was introduced; the contributing causes explain why it survived.
• The test action turns the failure into a permanent check, which is the cheapest part of the prevention.

DEF-2417  Android checkout charges 190.00 SAR instead of 184.00 with a fixed-amount coupon

5 whys
1  Why was the amount wrong?       API v2 pricing applied the coupon after calculating 15% VAT.
2  Why did v2 do that?             v2 has its own copy of the pricing function, forked from v1.
3  Why was the copy not updated?   The rule "VAT on the discounted price" (release 5.1) was written
                                   as a story for web checkout only; no one listed the other
                                   consumers of pricing.
4  Why did tests not catch it?     v2 API tests had no coupon cases; the test data had no coupons.
5  Why was there no coupon case?   v2 tests were copied from v1 happy-path cases and never reviewed
                                   against the pricing decision table.

Fishbone (contributing causes)
  Requirements  rule change scoped to one client
  Design        pricing logic duplicated per API version
  Code          order of operations in v2 price() and summary()
  Test          no coupon x VAT combinations at API level; test data without coupons
  Environment   none (reproduced on staging and locally)
  Data          none

Classification  origin: requirements (primary); code, test (contributing)
Actions (owner, due)
  - One pricing service used by v1, v2 and web              (omar.k, release 5.4)
  - Decision-table API tests: coupon type x VAT x rounding  (layla.h, 2026-09-25)
  - Story template asks "Which clients or APIs use this rule?" (product owner, next refinement)

Triage anti-patterns

• Triage as a status meeting — reading every open defect instead of deciding the new ones.
• Priority inflation — when everything is High, High means nothing. Watch the distribution.
• Severity bargaining — lowering severity to pass an exit criterion. Severity changes need new evidence.
• Assigning to "the team" — nobody owns the defect, so nobody fixes it.
• Rejecting without a reference — "works as designed" with no requirement or design quoted.
• Cannot reproduce as a bin — closing intermittent defects without recording what was tried or keeping the evidence.
• Permanent deferral — deferred with no review date becomes a hidden backlog.
• Debugging in the meeting — investigation belongs to the owner after triage.
• Blame — a root cause analysis that ends in "developer X was careless" has not found the root cause.
• Decisions in chat — if it is not in the tracker, it did not happen.

What triage produces

A triage session is finished when every defect it touched has left New with a recorded decision. AI assistance can speed up the clerical part — a clearer title, a structured description, a suggested severity and priority with a justification — but the decisions stay with the people who own them.

• For each defect: new state, severity, priority, owner, target release, links, and the reason for any non-fix resolution.
• Needs-info requests addressed to a named person with the exact question.
• An updated known-issues and risk list for the release decision.
• Escalations: Blocker and Critical defects flagged to the release manager the same day.
• Root cause analysis tasks for qualifying defects, with owners and dates.
• Triage metrics: untriaged count and age, time to decision, rejected and duplicate rates.

Try it: AI Bug Title Generator Try it: AI Bug Description Generator

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024ISTQB's advanced syllabus on managing testing: test planning and estimation, risk-based testing, monitoring, metrics and reporting.
• IEEE 1044-2009 — IEEE Standard Classification for Software AnomaliesIEEE Standards Association · 2009A standard vocabulary and attributes for classifying software anomalies — defects, failures and their impact (listed by IEEE as inactive-reserved).
• Editing a Bug (section "Life Cycle of a Bug") — Bugzilla DocumentationBugzilla Project (Mozilla)A widely used tracker's default bug workflow — statuses, resolutions (fixed, invalid, won't fix, duplicate, works for me) and transitions — as a concrete lifecycle example.
• Lessons Learned in Software Testing: A Context-Driven Approach (Cem Kaner, James Bach, Bret Pettichord)Wiley · 2001Practical lessons on bug reporting, test design, automation and managing testing — the context-driven school.