How to Write a Bug Report: 9 Proven Tips + Template
A practical guide for testers on writing clear, reproducible bug reports — with a copy-ready template, severity vs priority table, good vs bad examples and 9 proven tips.
Finding a bug is only half the job. If the developer cannot understand or reproduce it, the bug bounces back as “Cannot reproduce”, the fix gets delayed and your credibility takes a hit. Knowing how to write a bug report that is clear, complete and easy to act on is one of the most valuable — and most underrated — skills a tester can have.
Interviewers know this too. Many QA interviews in India include a task like “Find bugs on this page and report them”, and hiring managers judge your report as much as the bugs you find. This guide gives you the anatomy of a strong bug report, a copy-ready template, real examples and nine tips used by experienced testers.
Key takeaways
- A good bug report is reproducible, specific and neutral in tone.
- The title alone should tell a developer what is broken and where.
- Always include numbered steps, expected vs actual result, environment and evidence.
- Severity is the impact on the system; priority is the urgency to fix.
What is a bug report?
A bug report (also called a defect report or issue) is a document that describes a deviation between the expected and the actual behaviour of software. The ISTQB glossary defines a defect report as documentation of the occurrence, nature and status of a defect. In most Indian companies, bugs are logged in Jira, Azure DevOps, Bugzilla or a similar tracker, and the report moves through statuses such as New, Open, In Progress, Fixed, Retest, Reopened and Closed.
The goal of the report is simple: give the developer everything needed to reproduce, understand and fix the problem without coming back to you with questions.
Anatomy of a good bug report
| Field | What to write | Example |
|---|---|---|
| Title / Summary | What is broken + where + under what condition | Checkout: “Place Order” button stays disabled after applying a valid coupon |
| Environment | Build, URL/env, OS, browser/device, app version | QA env, build 4.12.0, Chrome 129, Windows 11 |
| Preconditions | Data or state needed before the steps | Logged in as a user with 2 items in cart |
| Steps to reproduce | Numbered, one action per step | 1. Open cart 2. Enter coupon SAVE10 3. Click Apply |
| Expected result | What should happen, per requirement | Discount applied, button enabled |
| Actual result | What actually happens | Discount applied, button stays disabled |
| Severity / Priority | Impact and urgency | Critical / P1 |
| Attachments | Screenshot, screen recording, console/network logs | video.mp4, console.txt |
| Reproducibility | Always, intermittent (x out of y) | 5/5 attempts |
How to write a bug report: 9 proven tips
1. Reproduce it before you report it
Try the scenario at least two or three times. Note whether it happens every time or intermittently, and on which browsers or devices. A bug you can reproduce reliably gets fixed far faster.
2. Search for duplicates first
Check the tracker for existing reports using key words from the screen or error message. If a duplicate exists, add your new information as a comment instead of creating a new ticket.
3. Write a title that stands on its own
Use the pattern [Module] — what fails — when. “Login not working” is weak. “Login: OTP screen shows blank page when mobile number has a +91 prefix” tells the developer exactly where to look.
4. Keep steps short, numbered and complete
One action per step, starting from a known state. Include the exact test data you used — usernames, amounts, coupon codes, file names. Do not skip “obvious” steps; what is obvious to you may not be obvious to someone else.
5. Separate expected and actual results
Expected result should come from the requirement, user story or acceptance criteria — mention the story ID if you have it. Actual result should describe only what you observed, including any exact error message text.
6. Attach evidence
A screenshot with the problem area highlighted, a short screen recording for flows, and browser console or network logs (from DevTools) for web apps. For APIs, include the request, response body and status code. For mobile, add device logs where possible.
7. Set severity and priority honestly
Do not mark everything as Critical. Inflated severity reduces trust and buries truly important issues. See the table below.
8. One bug per report
If you find three problems on one screen, log three tickets and link them. Combined reports are hard to track — one part gets fixed, the rest gets forgotten.
9. Stay neutral and factual
Describe the software, not the developer. Avoid words like “terrible” or “obviously”. A respectful, factual report builds a good working relationship with the development team.
Severity vs priority
| Combination | Example |
|---|---|
| High severity, high priority | Payment fails for all UPI users |
| High severity, low priority | App crashes on a rarely used legacy report page that few users open |
| Low severity, high priority | Company name misspelled on the home page banner |
| Low severity, low priority | Minor alignment issue in the footer on one browser |
Testers usually set severity; priority is often finalised by the Product Owner or lead, based on business needs.
Copy-ready bug report template
Title: [Module] - [What fails] - [Condition]
Environment: [Env/URL], Build [x.y.z], [OS], [Browser/Device + version]
Preconditions: [User role, data, settings]
Steps to reproduce:
1.
2.
3.
Expected result: [As per story/requirement ID]
Actual result: [What happened, exact error text]
Reproducibility: [Always / 3 of 5 attempts]
Severity: [Critical / Major / Minor / Trivial]
Priority: [P1 / P2 / P3 / P4]
Attachments: [Screenshot, video, console log, API response]
Notes: [Workaround, first seen in build, related tickets]Bad vs good: a real-style example
Bad: “Search is broken. Please fix ASAP.”
Good: “Job search: results page shows ‘No jobs found’ when the keyword contains a trailing space.” Environment: staging, Chrome 129 on Windows 11. Steps: 1. Open the home page. 2. Type “QA engineer ” (with a trailing space) in search. 3. Press Enter. Expected: matching jobs listed, same as “QA engineer”. Actual: “No jobs found” message; the network tab shows the API called with the untrimmed keyword. Reproducibility: 5/5. Severity: Major. Attachment: screen recording plus API request and response.
The good version tells the developer the exact input, the likely cause and how to verify the fix — that is a report developers love.
Common mistakes to avoid
- Vague titles such as “Issue in page” or “Not working”.
- Missing build number or environment, so the developer tests the wrong version.
- Reporting your assumption of the cause as fact — share it as a note instead.
- Logging feature requests as bugs; raise them as improvements.
- Never retesting: always verify the fix and run nearby regression before closing.
Bug reports and test cases go hand in hand — see our guide on how to write test cases, and learn the tracker workflow in Jira for testers.
🚀 Put your bug-reporting skills to work
QA Jobs India shares 100+ fresh QA & software testing openings every morning — manual, automation, API and remote roles.
See today’s QA jobs →FAQs
How to write a bug report in an interview task?
Use the template above, keep titles specific, number your steps and add severity. Quality beats quantity — five clear bugs impress more than twenty vague ones.
What is the difference between a bug and a defect?
In daily practice they are used interchangeably. Formally, a defect is a flaw in the work product; a failure is what you observe when it executes.
What should I do if a bug is not reproducible?
Report it with the frequency observed, timestamps, logs and recordings, and mark it intermittent. Logs often reveal the cause.
Who decides bug priority?
Testers suggest it, but the Product Owner or project lead usually confirms priority based on business impact.
Which tools are used for bug tracking in India?
Jira is the most common, followed by Azure DevOps, Bugzilla, MantisBT and Redmine.
Conclusion
Once you know how to write a bug report that is reproducible, specific and neutral, developers start trusting your tickets — and that trust is what turns a tester into a respected team member. Save the template, practise on any website you use daily, and then put the skill to work: check today’s QA openings and apply with confidence.
💎 Get every QA opening, every day
Join QA Jobs India Premium for 100+ verified QA jobs daily with HR contact details.
