Stop 10 · Testing & User AcceptanceTopics · 5/8

Defect Tracking & Triage

In short

Testing a big release can produce a hundred defects. Not all of them matter equally. Triage decides what gets fixed before launch, what waits, and what isn't really a bug at all.

Logging issues found during testing clearly enough for engineers to reproduce and fix, and prioritizing them by severity and business impact — a shared skill with QA, but a BA's business context adds real value here.

The purple blob wears a doctor's coat and stethoscope, sorting red, yellow and green tags on a desk.

Think of it like this

The hospital emergency room

In emergency, patients aren't seen in the order they arrive. A nurse checks each one quickly: chest pain goes first, a sprained ankle waits. Defect triage works the same way: sort by how badly it hurts the business, not by who shouted first.

Watch it happen

Triage meeting: sorting five new defects

Typo

Pay fails

Slow report

Wrong GST

Logo blur

1/5Five defects came in from UAT yesterday, in random order.

The big ideas

What you need to know

Reproducible reports

Steps, expected result, actual result, data used, environment and a screenshot. Without these, developers guess.

Severity vs priority

Severity is how bad the impact is. Priority is how soon to fix. A typo on the homepage can be low severity, high priority.

Regular triage

During testing, the BA, QA lead, developer and PO review new defects daily and agree on each.

Not every bug is a bug

Some are misunderstood requirements or new requests. The BA helps label them correctly.

See it in code

Walk through the code

text

1Title:    GST shows 12% instead of 18% on electronics2Env:      UAT, Chrome, build 2.3.13Steps:    1. Add a phone (₹10,000) to cart4          2. Go to checkout5Expected: GST ₹1,800 (18%)6Actual:   GST ₹1,200 (12%)7Severity: High   Priority: Must fix before go-live8Req:      REQ-31 Tax by product category

1/3A specific title and exact environment. 'Tax wrong' alone would waste everyone's time.

A defect a developer can reproduce in two minutes. Note it links to the requirement, which helps confirm it's truly a bug.

Save yourself the pain

Common mistakes

Oops

Logging 'checkout doesn't work' with no steps.

Do this instead

Write steps, data, expected, actual and environment. Attach a screenshot or screen recording.

Oops

Marking everything as critical to get it fixed faster.

Do this instead

Use severity honestly. If everything is critical, nothing is, and real blockers get lost.

Your mission

Report three real bugs

~25 min

Quick check

The company name is misspelt on the login page. Payments work fine. How would you usually classify it?

Go deeper

1Write a clear defect report: steps to reproduce, expected vs actual result, and severity.
2Learn to prioritize defects by business impact, not just technical severity.
3Practice deciding whether a defect blocks go-live or can be a known issue at launch.