Guide · report triage

How to triage a website QA report before you file bugs

First published November 10, 2026 · Facts checked November 10, 2026

Short answer

Sort the report into failed, blocked, not-run, and passed. Merge duplicates. File a bug only for a failed claim you can restate with steps. Leave blocked and not-run rows open with the reason.

On this page

Context and limits

Triage is the pass you make before anyone files a bug. You sort the rows, merge duplicates, and decide which failures are worth a record. Blocked and not-run rows stay open. They are not bugs and they are not passes. A report you have not triaged is a pile, not a decision.

Have a site ready to check? Test my site free. Add your URL and review a test plan before starting a run. See a sample report first.

Sort the rows before you interpret them

Failed. The claim was checked and did not hold. These are the only rows that might become bugs.
Blocked. Something stopped the check. A login wall, a missing fixture, or a crashed step. Keep the reason. Do not file them as product bugs unless you have shown the product itself failed.
Not run. The check was not attempted. Scope, time, or a decision to stop. They are still open.
Passed. The written claim held on that attempt. Leave them in the record so the next run has something to compare.

The report example shows those labels. Blocked is not passed is the rule for open rows. This page is the order of work: sort, then file.

Merge duplicates and separate leads

The same overflow at two widths is one observation until you show two causes. File it once and name both widths. A screenshot that “looks wrong” without a written claim is a lead. The false-positive worksheet is for a lead that might not hold. A failed visual check is a mismatch, not yet a cause.

Drop nothing in silence. If you will not file a row, write why: duplicate, intentional change, or not a claim you agreed to check. The next reader should not have to guess which rows you ignored.

File only what someone else can repeat

For each failure you keep, write the URL, the steps, the expected sentence, and the actual outcome. How to file a QA result is that record. If you cannot write the steps, the row is not ready to file. Put it back under blocked or under a lead.

Do not turn the report into a pass rate. One failed row is one claim. Count the open rows out loud: how many failed, how many blocked, how many not run. That tally is the triage. A single summary word is not.

Common questions

What is the first step in triaging a QA report?

Sort every row into passed, failed, blocked, or not run. Do that before you decide which failures become bugs.

Should a blocked check be filed as a bug?

Not by default. File the access problem if that is the claim. Do not describe the unchecked feature as failed.

How many bugs should a report produce?

As many as you can restate with steps, and no more. A report is not required to become a pile of tickets.

Sources

Try Sybqa on your site

Explore bugs, UI consistency and user journeys from a reviewed plan. Inspect browser evidence and visual review leads in the report. The free plan gives 10 runs a month without AI review after you sign up. See pricing.

Add your site link here and it will be waiting in the console after you create an account. Then describe one journey to check and review the test plan before any run starts.