Writing a Good Bug Report
A bug you can't reproduce, that a developer can't understand, is a bug that gets silently deprioritized or bounced back to you with "cannot reproduce, please provide more info" — wasting a full day of back-and-forth. A well-written bug report is the single most visible sign of a competent tester, because it's the one artifact developers, leads, and managers all read directly. This lesson covers the standard fields every good bug report needs, and then writes out one complete, real example for RecipeBox from scratch.
The Standard Bug Report Fields
| Field | What goes here |
|---|---|
| Bug ID | A unique identifier, usually auto-assigned by the bug-tracking tool (Jira, Azure DevOps, Bugzilla, etc.) |
| Title / Summary | One specific line describing exactly what went wrong and where — specific enough to be understood without opening the report |
| Environment | App version/build number, OS and device (or browser and OS for web), and any other relevant config |
| Steps to Reproduce | A numbered, exact sequence of actions anyone can follow to trigger the bug themselves |
| Expected Result | What should have happened, based on the requirement or reasonable behavior |
| Actual Result | What actually happened instead |
| Severity | Technical impact — crash, major, minor, cosmetic (see the previous lesson) |
| Priority | Business urgency — how soon it needs fixing (see the previous lesson) |
| Attachments / Screenshots | Screenshot, screen recording, or log file that shows the problem directly, removing any ambiguity about what happened |
Bad vs Good Bug Titles
| Title | Problem | |
|---|---|---|
| Bad | "App is broken" | Tells the developer nothing: which screen, which action, which build? They'd have to open the report and possibly still not know where to start. |
| Bad | "Prep Time bug" | Slightly better, but still doesn't say what's actually wrong with Prep Time — is it a crash, wrong value, missing label? |
| Good | "Prep Time field accepts negative numbers without validation error, on Add Recipe screen" | Identifies the exact field, the exact screen, and the exact wrong behavior — a developer can picture the fix before even opening the full report. |
Rule of thumb: a good title should let a developer guess roughly what code area to look at, before reading a single other field.
Full Worked Example: A Complete RecipeBox Bug Report
| Bug ID | RB-0142 |
| Title | Prep Time field accepts negative numbers without validation error, on Add Recipe screen |
| Environment | RecipeBox v2.4.0-rc4, Android 13, Pixel 6 emulator |
| Steps to Reproduce |
1. Launch RecipeBox and log in with a valid account. 2. From the Recipe List screen, tap "Add Recipe." 3. Enter a title (e.g. "Test Soup") and at least one ingredient. 4. In the "Prep Time (minutes)" field, enter -5.5. Tap "Save." |
| Expected Result | The form should reject the negative value and show a validation error such as "Prep time must be a positive number," blocking the save. |
| Actual Result | The recipe saves successfully with a Prep Time of -5 minutes, which then displays as "-5 min" on both the Recipe List and Recipe Detail screens. |
| Severity | Low — no crash or data loss, but incorrect data is silently accepted and displayed to users. |
| Priority | Medium — not urgent enough to block a release by itself, but should be fixed before the next major version since it affects data quality. |
| Attachments | Screenshot of Recipe Detail screen showing "Prep Time: -5 min" |
Notice how every field in that report answers a question a developer would otherwise have to ask you directly: what build, what exact steps, what should happen, what actually happens. A report this complete can usually be picked up and fixed without a single follow-up question.
Tips for Reports Developers Will Actually Act On
- One bug per report. Don't bundle "Prep Time accepts negatives AND the Save button is misaligned" into one ticket — they need separate fixes, separate verification, and possibly separate developers.
- Make steps exact and minimal. Remove any step that isn't required to reproduce the bug, so nothing distracts from the actual cause.
- Always attach evidence when the bug is visual or intermittent. A screenshot removes any "well it looks fine to me" back-and-forth.
- State the expected result even when it feels obvious. What's obvious to you as the tester may not be obvious to a developer who's never seen the requirement.
- Stay factual, not accusatory. "The field accepts negative numbers" reads professionally; "whoever built this didn't test it" does not, and it damages the working relationship you'll need for the next 50 bug reports.
Next up: Individual bug reports are how you communicate results — but before testing even starts, a whole project needs a documented plan. That's covered in Test Plan & Test Strategy.