Process · Bug Reporting
Write bug reports developers act on.Ten steps, in order, every time.
A bug report is a sales document aimed at a developer. This is the ten-step sequence we use on every engagement to write reports that get fixed instead of dismissed.
- Steps
- 10
- Time per report
- 10–20 min
- Compatible with
- Any tracker
A bug report is a sales document aimed at a developer. Write one they can act on, and you get a fix. Write one they cannot, and you get silence.
Key takeaways
Four things to remember.
01
Structured first, expressive second
Before you write a single line, you have to reproduce, isolate, and generalize. Most rejected bug reports skip these three.
02
Every word is on trial
Condense, disambiguate, and neutralize. Three passes. Anything that does not help a developer reproduce or prioritize comes out.
03
Peer review before submit
The single highest-leverage step. A five-minute review by another tester catches the ambiguities you cannot see anymore.
04
One format, one tracker, zero exceptions
Teams lose days to reports filed in email, Slack, and three different tools. The process ends in your tracker, always.
Why this exists
The problem this process fixes.
Most rejected bug reports are not rejected because the bug is not real. They are rejected because the report makes the developer do all the work, reproduce it, figure out what is and is not in scope, guess at severity, infer the user impact. Developers have a backlog. The path of least resistance is to close the ticket.
This ten-step process exists to eliminate that path. Each step is small. In sequence, they produce a report that a developer can pick up, reproduce in minutes, and fix with confidence.
The checklist
10 steps, in order.
- 1
Run each test using structured, careful testing techniques.
- 2
Reproduce any deviations from expected behavior.
- 3
Isolate the bug by checking the effect of key variations, looking for workarounds as well.
- 4
Look for the general case, especially one more severe or objectionable.
- 5
Compare the abnormal behavior observed with the behavior of the system under similar conditions on this or previous test releases.
- 6
Summarize the failure, including the effect on customers or users.
- 7
Condense the report, removing unnecessary information.
- 8
Disambiguate, removing confusing, misleading, or imprecise words.
- 9
Neutralize the bug report, expressing ideas impartially and fairly.
- 10
Submit the bug report to a peer review, resolve any problems found, then enter the bug report into the bug tracking system.
One more thing
The ten steps are not optional. Skip one and the report costs the developer more time than it saves the test team. Skip three and it gets closed as "cannot reproduce." The discipline is the deliverable.
Take it with you
Download the piece you just read.
The library is free. Tell us who you are so we can send you updated versions. One form; this browser remembers you after that.
In the library
Pair this with.
Process · The Master Framework
Four phases, applied in order, every project.
The top-level testing process used on every engagement. Four phases contain twelve sub-processes, each of which is documented in its own checklist in this library.
Read →Process · Test Execution
Run the tests, capture the data, adjust daily.
Test execution is where the risk register becomes results. These eight steps cover selection, assignment, the per-test inner loop, blocking-issue resolution, and the daily replanning that keeps a cycle on the rails.
Read →Process · Change Management
Triage every change. Integrate only the approved ones.
Undisciplined change is the largest single risk to test completion. This process defines the Change Control Board loop (from intake through final approval) so nothing slips into a release untested or unscored.
Read →
Keep reading
Related reading
- Primer
Careers in Software Quality: Roles, Skills, and First Steps
What testers, test automation engineers, quality engineers, and test managers actually do, the skills each role uses, and practical first steps for students and career changers, including the ISTQB Foundation certification.
Read → - Primer
Errors, Defects, and Failures: What a Bug Really Is
Everyone says 'bug', but testers use three precise words: error, defect, and failure. Learn the difference, why it matters, and how severity and priority decide which problems get fixed first.
Read → - Primer
How Software Gets Attacked: Common Vulnerabilities in Plain English
The most common ways attackers break into software, explained without jargon: trusting input, broken access control, weak sign-in, misconfiguration, and outdated components. Each one comes with the defense that stops it.
Read → - Primer
How to Report a Bug So It Actually Gets Fixed
Finding a bug is half the job. Learn how to write a bug report a developer can act on: a clear summary, exact steps to reproduce, expected versus actual results, and the habits professional testers use to make every report count.
Read → - Primer
Security Testing Basics: Finding Weaknesses Before Attackers Do
An introduction to security testing for new testers and developers: thinking in threats, designing abuse cases, testing access control, the role of automated scanners and penetration tests, and the rules that keep security testing legal and ethical.
Read → - Primer
Staying Safe Online: Passwords, Sign-In, Phishing, and Updates
The everyday security habits that stop most attacks: strong unique passwords, multi-factor sign-in, spotting phishing, keeping devices updated, and sharing carefully. Written for students, families, and anyone starting out.
Read →
Practices
Where this leads
- QA & testingSoftware testing
Software quality consulting since 1994: we test the releases that matter, coach your team on the method, and measure how its testing matures.
Book a call →