The five components of a great bug report.
Clear, specific title
Not "Button broken" but "Submit button on checkout unresponsive after invalid card number."
Steps to reproduce
Exactly what a developer needs to do to see it themselves.
Expected behavior
What should happen.
Actual behavior
What actually happens.
Environment
Browser, OS, device, app version.
You already know this structure. What AI changes is how fast you turn a rough, informal description into a report that hits all five, every time.
You are a senior QA engineer helping me write a bug report.
I'll describe a bug informally. Turn it into a professional
report with five sections:
1. Title: clear, specific, scannable
2. Steps to Reproduce: numbered, exact, no assumptions
3. Expected Behavior 4. Actual Behavior
5. Environment: browser, OS, device, version
If anything is unclear, ASK before writing. Don't invent details.
Rough description: {your description here}
Environment: {Chrome 122 · macOS 14 · staging 1.4.2}
Notice the instruction to ask before writing. That's what keeps AI from politely inventing steps you never actually gave it.
Not every bug is a P0. Know the difference.
When a bug isn't clear-cut, ask AI to argue both sides: "Make the case this is a P1, then make the case it's a P2." Reading both arguments is often faster than deciding cold.
When you can't quite describe it yet.
Use AI as a rubber duck.
Sometimes you've found something strange and you're not sure how to describe it, let alone whether it's a bug. Explain what you're seeing to AI in whatever messy words come out first. The act of explaining, and the follow-up questions AI asks back, usually gets you to a clear description faster than staring at the screen would.
"Checkout is broken sometimes. Please fix."
"Checkout: submit button unresponsive after entering an invalid card number. Repro: enter 4000-0000-0000-0002, click Submit. Expected: inline error. Actual: button greys out, no error, no request sent. Chrome 122, macOS 14, staging 1.4.2."
Turn a complaint into a report.
Imagine a user files a ticket that says, in full: "The search sometimes shows old results." No screenshots, no steps, no version, nothing else. Run the Basic Bug Report prompt against it, let AI ask you the clarifying questions it needs, and produce a full five-component report. Then assign it a P0-P3 priority and write one sentence defending your call.
The five components, in brief:
- Title: one line naming the symptom and where it happens
- Repro steps: exact clicks and inputs, numbered, a stranger could follow
- Expected: what should have happened
- Actual: what happened instead
- Environment: browser, OS, and build version
Knowing that list isn't the hard part. The real failure mode is letting AI fill gaps in your description with plausible-sounding invented steps. That's why the prompt tells AI to ask before writing, never guess.
Severity: when a P1 versus P2 call feels close, make AI argue both sides before you file, not after. It forces the ambiguity into the open instead of letting you decide quietly in your head and move on.
Rubber-duck: you don't need a clear description before you start explaining something strange. Explaining it badly, out loud or in a chat window, is usually how you arrive at a clear description in the first place.
Check yourself: pull up a bug report you filed recently. Could a developer reproduce it without asking you a single follow-up question? If not, which of the five components was thin or missing, and would AI have caught that gap if you'd told it to ask before writing?
This module is the free preview.
Guide 2 (The Manual Tester's AI Toolkit) has 29 copy-paste prompts across bug reports, test cases, test data, test plans, exploratory testing, and more. No coding required, ever.
See the full AI Toolkit →The five-component bug report structure
A working bug report prompt, plus the P0-P3 severity scale
The rubber-duck technique for bugs you can't describe yet
Test Case Design & Test Data.
- Getting a comprehensive first draft of test cases in 15 minutes
- Pushing AI past the happy path for real edge cases
- Realistic test data vs. adversarial, boundary-breaking data
- Why "Test User 1" is hiding bugs from you