Which bugs to report first: ordering a list of findings
An hour on a checkout form can produce twelve findings. The developer who reads the report fixes some of them first, and which ones depends partly on the order they appear in. Below is an order for the findings of a web form, with the reasoning for each step, so it can be bent where the product is different.
Severity and priority
Severity says how bad a bug is when it happens; priority says how soon it gets fixed. The tester sets the first, having seen the bug, and the team sets the second, knowing release dates and customer promises the tester may not. The order of a report is the tester's proposal for the second, built from severity and from how many people are going to hit the bug. It stays a proposal: an item near the top can still wait, and a cosmetic one can jump the queue before a launch.
The order
| # | Kind of finding | Why it goes here |
|---|---|---|
| 1 | Wrong money or wrong data, with nothing on screen to show it | A service fee charged per ticket where the rule says per order makes three tickets at ₪49.95 come to ₪164.85 instead of ₪154.85: ₪10 too much on every order of three, and the customer has no reason to recheck. Two hundred such orders are ₪2,000. A server that charges whatever total the browser sends is the same kind with the sign reversed: whoever edits the request pays ₪0.01. |
| 2 | Someone else's data, or data where it should not be | One user reading or deleting another's booking. A password in the page address or in the console. Once the data is out it stays out, which is why this ranks above a blocked purchase even when no one has complained. |
| 3 | The main flow blocked, no way around | Orders fail for every address with a capital letter in it. Within this group, a failure with no message goes before one with a message, because a user who sees an error can at least try again. |
| 4 | A wrong result that is visible | A wrong total on screen, a date in the past accepted, a discount that shows but is not charged. Some of these cost the shop and some cost the customer; the report should say which. |
| 5 | Gaps at the edges of validation | 11 tickets where 10 is the maximum, a username one character too short. What it costs depends on what happens downstream, and often nothing does. Say in the item whether you followed the value past the field. |
| 6 | Cosmetic and wording | An error that stays after the fix, a missing second decimal, a misaligned label. Cheap to fix and worth listing, at the end. |
What moves an item up or down
An item moves up when many people hit it: a bug on the path everyone takes outranks a worse one on a path few reach, so an address bug outranks a bug that needs the Enter key in one particular field. It also moves up when the user cannot tell, since a silent failure just runs. What moves it down is a workaround a user would find on their own, or a location behind a feature few people use.
Before any ordering, merge items with one cause and drop the ones that turned out to be the requirements. Twelve findings with two duplicates and one "not a bug" are nine.
An example
Say a session on a ticket form found these, in this order:
| Found | Finding | Report position |
|---|---|---|
| 1st | The error message stays after the field is corrected | 6 |
| 2nd | The total shows 204.8 instead of 204.80 | 5 |
| 3rd | 11 tickets accepted, the maximum is 10 | 4 |
| 4th | The fee is charged per ticket instead of per order | 1 |
| 5th | The order response, email included, is written to the console | 2 |
| 6th | An email with capital letters fails with no message | 3 |
The first three findings were the easiest to see, which is why they came first. The last three took the developer tools and go to the top: by finding number the report runs 4, 5, 6, 3, 2, 1, and its first item carries the arithmetic, ₪164.85 charged and ₪154.85 expected on three tickets.
The first line
Put the top of the list above first, with steps and numbers, however early or late it was found and however short its description. In a chat message, one line per finding, in that order, is enough; the details can follow when asked. Severity written by an AI agent follows the same rule as everything else in its report: set it again after checking the item, as the guide on reviewing agent reports describes.
Open the practice form
More guides: silent failures and stale screens · how to review an AI bug report · all guides