A report is a work instruction, not an archive entry
Every bug report has one reader with one immediate task: reproduce the fault on their machine in the next few minutes. Almost every returned bug comes from that task failing, and it fails for a short list of reasons. The reader could not get the system into the starting state, the steps skipped something the author did without noticing, the build under test was not identified, the data was described as "a customer" rather than named, or nothing in the report said why the observed behaviour is wrong. Write to remove those five failures and the return rate collapses.
That means the environment line is specific: build or commit, browser and version, operating system, tenant or account, role, and region or timezone if either could matter. "Latest QA build" ages into meaninglessness within a day, and a developer who has to guess which build you were on will guess the one on their laptop.
Isolate before you file
The most valuable work happens between finding the fault and writing it up. Try the shortest path to the same failure, remove steps that turn out to be irrelevant, then check whether it happens on a second browser, a second account, and a second data set. Each answer narrows the search for whoever picks it up.
Three sentences of that work change a triage decision. "Reproduces on Chrome and Firefox, on two tenants, only when the account has more than fifty saved addresses" is a diagnosis in everything but name. "Address book is broken" is a ticket someone has to redo from scratch. Say how often it happens, too, and out of how many attempts, because five in five and one in twenty are different bugs with different investigations.
What the report looks like
Title: Saved-address list shows only 50 entries; entry 51 onwards
silently dropped at checkout
Build: web 4.18.2 (commit a91c4f2), API 2.31.0
Env: Chrome 141 / Windows 11 · tenant acme-uat · role: customer
Account: qa.addr51@example.com (seeded with 60 addresses)
Preconditions
Account has 60 saved addresses, none marked default.
Steps
1. Sign in and open Checkout > Delivery address.
2. Scroll the address list to the end.
3. Note the count shown in the list header.
Expected All 60 addresses listed; header reads "60 addresses".
Source: ACME-1182 acceptance criterion 3, no documented cap.
Actual 50 listed, header reads "50 addresses". Addresses 51-60
are absent and no truncation notice appears.
Frequency 5/5 attempts. Also on Firefox 142. Does not occur on an
account with 49 addresses; does occur at 51.
Evidence screen recording, HAR, API response for GET /v2/addresses
Impact A customer who cannot see an address re-enters it, creating
duplicates; observed in 3 UAT accounts.
The title is doing real work there. It names the object, the symptom and the consequence, so it is legible in a list of two hundred tickets, and "silently" tells a reader there is no error handling to look at. Notice also that the expected behaviour cites a requirement. Attribution is what stops the ticket becoming an argument about taste, and if you cannot find a source for your expectation you have probably found a specification gap, which is worth filing as itself.
Severity and priority pull in different directions on purpose
Severity is how badly the system misbehaves when the fault occurs: data loss, crash, wrong result, cosmetic. It follows from the defect and is yours to judge, because you are the person who saw it. Priority is when it gets fixed relative to everything else in the backlog, which depends on the release date, the customers on the call this week, the cost of the fix, and what else the team has committed to.
The pairs that come apart are the ones to have ready.
| Case | Severity | Priority | Why they diverge |
|---|
| Crash in an export used by two internal users, workaround exists | High | Low | Real data loss, tiny blast radius, cheap to avoid for a fortnight |
| Company name misspelled on the pricing page | Low | High | Nothing breaks, but every prospect sees it and the fix is minutes |
| Wrong tax on one state's invoices | High | High | Financial correctness with a regulatory deadline |
| Button misaligned by three pixels on a rarely used settings tab | Low | Low | Genuinely can wait |
The part candidates get half right
Almost everyone can recite that severity is technical and priority is business. Far fewer say the consequence, which is that you do not set priority. Triage does, and it is usually the product owner with the engineering lead, because only they can see the full queue and the commitments around it.
Your job is to make their decision cheap: state severity with the evidence behind it, then hand over the facts that drive scheduling — how many users are affected, how often it fires, whether a workaround exists and how unpleasant it is, whether data is corrupted permanently or transiently, and whether it is a regression from a build that worked. A tester who quietly marks their own finds as critical loses the ability to signal anything, because within a month every open bug is critical and triage starts ignoring the field.
A tester who supplies the impact evidence and lets triage rank it gets escalated to when the field is genuinely on fire.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).