15 real bug reports, graded: good, bad, and unfixable

The fastest way to learn bug reporting is to read other people's reports and judge them.

Below are fifteen bug reports. They are based on real ones, with names and details changed. Each gets a grade and a short explanation of what works and what does not.

Read the report first. Decide your own grade. Then read mine.

How the grading works

Grade	Meaning
A	A developer can start fixing immediately
B	Fixable, but someone has to ask one question first
C	Needs a conversation before any work can start
F	Unfixable as written. Will be closed or forgotten

Report 1

Title: Login broken Description: Cannot log in. Please fix urgently.

Grade: F

There is nothing here. Which account? Which environment? What happens — an error, a blank page, an endless spinner? Does it affect one user or everyone?

"Urgently" adds pressure without adding information, which is the worst combination.

This report will generate three messages in chat before any work begins. Those three messages are the actual bug report; this ticket is just an announcement.

Report 2

Title: Login fails with "Invalid credentials" for correct password on staging Steps:

Open https://staging.example.com/login

Enter [email protected] / correct password from 1Password entry "QA Staging"

Click Sign in

Expected: User is logged in and lands on the dashboard. Actual: Red error "Invalid credentials" appears above the form. Console shows POST /api/auth/login 401. The same password works on production. Frequency: 5 of 5 attempts. Environment: Chrome 141 · macOS 15 · staging build 4.7.2

Grade: A

Everything needed is here. The comparison with production is the strongest line in the report — it immediately suggests an environment configuration problem rather than a code problem. That single sentence probably saves an hour.

Report 3

Title: The dashboard is really slow Description: The dashboard takes forever to load. It is very frustrating for users.

Grade: F

"Forever" is not a measurement. Slow for whom, with how much data, on what connection?

Performance bugs need numbers. Without them, a developer cannot tell whether they have fixed it.

Report 4

Title: Dashboard takes 14s to load for accounts with 500+ projects Description: Measured with DevTools Network panel, cache disabled, no throttling.

Account Projects Load time
[email protected] 12 1.2s
[email protected] 140 3.8s
[email protected] 612 14.1s

The request GET /api/projects?include=stats takes 12.6s of that time and returns 4.2 MB. Expected: Under 3s, per the performance budget in the team wiki.

Grade: A

This is excellent. It shows the pattern, not just one data point. It identifies the specific slow request. It cites an agreed target, so nobody has to argue about whether 14 seconds is acceptable.

The three-row table took the tester five extra minutes and turns a vague complaint into a clear scaling problem.

Report 5

Title: Fix the null check in OrderService.calculateTotal() Description: The total is null because the discount object is not initialised. Add a null check on line 84.

Grade: C

The tester may well be right. But this is a proposed solution, not a bug report.

Two problems. First, if the guess is wrong, the developer looks in the wrong place. Second, there is no way to verify the fix, because nobody wrote down what the user actually sees.

Report the symptom. Put the theory in a clearly-labelled note at the bottom.

Report 6

Title: Order total shows $0.00 when a discount code is applied Steps:

Log in as [email protected]

Add "Blue T-Shirt" ($62.49) to the cart

Go to Cart

Enter discount code SUMMER20

Click Apply

Expected: Total updates to $49.99. Actual: Subtotal shows $62.49 and the discount line shows -$12.50, but the total shows $0.00. Frequency: 5 of 5. Console: TypeError: Cannot read properties of undefined (reading 'amount') at cart.js:1:24501 Note (guess, not confirmed): the discount object may be missing an amount field in the API response.

Grade: A

Same underlying bug as Report 5, reported properly. The symptom is precise, the numbers are all there, the console error is included, and the theory is present but clearly marked as a guess.

Note the detail: subtotal and discount line are correct, only the total is wrong. That narrows the problem enormously.

Report 7

Title: App crashes sometimes Description: The app crashed while I was using it yesterday. I could not repeat it.

Grade: F

Not because it is intermittent — intermittent bugs are worth reporting — but because nothing was captured. No time, no screen, no device, no crash log.

Compare with Report 8.

Report 8

Title: App crashes on Photo Gallery when scrolling fast — 1 of 30 attempts Frequency: 1 of ~30 attempts. When: 09 Aug 2026, 16:04:22 UTC+5 Device: iPhone 14, iOS 18.2, app build 3.9.1 (TestFlight) What I was doing: Opened Photo Gallery with ~800 photos and scrolled quickly to the bottom. Crash log: Attached from Settings → Privacy → Analytics. Top frame: PhotoGridCell.imageDidLoad. What I tried after: 30 more attempts on the same device, and 20 on an iPhone 12 — no crash. Note: Only account I have seen this on has 800+ photos. Smaller accounts scroll fine.

Grade: A

An intermittent bug reported well. The crash log alone makes this fixable, and the observation about photo count gives the developer a way to reproduce it deliberately.

The lesson: what makes an intermittent bug report good is not reproducibility, it is evidence.

Report 9

Title: UI issue on settings page Description: Something looks wrong. See screenshot. (screenshot attached)

Grade: C

A screenshot is genuinely useful, so this is not an F. But a screenshot without words is a puzzle. Which part is wrong? What should it look like instead? At what screen width?

If you attach a screenshot, annotate it. Draw an arrow. Then still write one sentence.

Report 10

Title: Footer text overlaps the logo on screens under 400px wide Steps:

Open https://example.com on a phone, or set Chrome DevTools device toolbar to 375px wide

Scroll to the bottom

Expected: Footer links sit below the logo with 16px spacing, as in the Figma file (link). Actual: The "Privacy policy" link sits on top of the logo and both are unreadable. Screenshot: attached, with the overlap circled in red. Also affects: All pages, since the footer is shared.

Grade: A

The width is specific and testable. The design source is linked, so "expected" is not an opinion. The final line — that it affects every page — quietly raises the priority for the person triaging.

Report 11

Title: Export not working Description: Export doesn't work for me but works for Sarah. Maybe a permissions thing?

Grade: C

There is a real clue buried here — it works for one person and not another. That is a strong signal, usually pointing at roles, plans, or data.

But the tester did not follow the clue. What role does Sarah have? What role do you have? What is different about the two accounts?

One extra question, asked before filing, would have turned this into an A.

Report 12

Title: Export to CSV downloads an empty file for Viewer role (works for Editor) Steps:

Log in as [email protected] (role: Viewer)

Open the project "Website Redesign"

Click Export → CSV → Download

Expected: CSV contains the 14 tasks visible on screen. Actual: CSV downloads with only the header row. No error is shown. Works correctly with [email protected] (role: Editor), same project, same steps. Network: GET /api/projects/882/export returns 200 with an empty rows array for Viewer, and 14 rows for Editor.

Grade: A

The same suspicion as Report 11, but investigated. Testing with two roles took three minutes and located the bug in the permissions layer of the export endpoint.

The developer now knows the file to open before they even start.

Report 13

Title: Cannot upload file Steps:

Go to Documents

Upload a file

Error

Expected: File uploads. Actual: Error.

Grade: F

It has the right structure but no content. "Upload a file" — which file? What type, what size, what name? "Error" — what did it say?

Structure without substance still fails. This is a common trap for testers who have learned the template but not the purpose behind it.

Report 14

Title: Upload fails silently for files over 5 MB — no error shown to user Steps:

Log in as [email protected]

Go to Documents → Upload

Select test-6mb.pdf (6.2 MB, attached)

Click Upload

Expected: Either the file uploads, or a clear message explains the size limit. Actual: The progress bar reaches 100%, then disappears. The file does not appear in the list. No message is shown anywhere in the interface. Network: POST /api/upload returns 413 Payload Too Large. The front end does not handle 413. Also tested: 4.8 MB uploads fine. 5.1 MB fails the same way. Note: The help page says the limit is 10 MB, so either the limit or the documentation is wrong.

Grade: A

This report finds three problems in one: the silent failure, the undisplayed 413, and the incorrect documentation. The boundary testing (4.8 MB versus 5.1 MB) pinpoints the real limit.

The last line is the kind of thing that separates a competent tester from a great one.

Report 15

Title: I think there might be a problem with dates? Description: Some dates look wrong in the report. Not sure. Maybe timezone? Can someone check?

Grade: F

Every part of this is a question rather than a finding. Which report? Which date? Wrong by how much — a day, an hour, five hours?

If you genuinely are not sure, that is fine — but investigate for ten minutes first. Compare two dates. Note the difference. "Dates are 5 hours earlier than they should be for users in UTC+5" is a completely different ticket.

What the A-grade reports have in common

Look back at reports 2, 4, 6, 8, 10, 12, and 14. Every one of them includes:

A title that names the failure and the condition
A starting point — a URL and an account
Exact data — real file names, real amounts, real codes
Expected and actual, separately
A number — a time, a size, a count, or a frequency
Technical evidence — a console error, a network response, or a crash log
One comparison — works here but not there, works for this role but not that one

That seventh item is the one most testers skip, and it is often the most valuable. Testing one variation before you file turns a report from "here is a problem" into "here is where the problem is".

Items 6 and 7 are also the ones that take the most manual effort. Capturing the console log and the network requests by hand, every time, is why they get dropped under deadline pressure — and why teams increasingly capture them automatically with tools like Crosscheck instead of relying on discipline.

Frequently asked questions

Is it better to file a weak report or no report? A weak report, almost always. An unreported bug reaches customers. But spend ten more minutes and file a good one.

How long should a good bug report take to write? Five to fifteen minutes for most bugs, once you have the habit. Longer for complex ones. Much of that time goes into testing one variation, which is time well spent.

My team does not use templates. Should I still follow this structure? Yes. You can write it as plain paragraphs with bold labels. The structure is what matters, not the tooling.

What if the developer still asks questions? Some questions are normal and healthy. The goal is not zero questions — it is that work can start before the questions are answered.

Should I grade my own reports? It is a genuinely useful exercise. Look back at ten of your own tickets from last month and grade them honestly. Most people find a clear pattern in what they habitually leave out.