Free bug report template and generator
Write a bug report developers can fix, in about 2 minutes. Answer 5 quick questions and copy the finished report into Jira, GitHub, Linear, Notion or an email. Free, no signup.
- 1Answer 5 questions
- 2Check your report
- 3Copy and paste
Just need a blank template?All formats
What you paste into GitHub, Jira or an email:
Checkout: Pay button stays disabled after entering a valid Canadian postal code
Severity: S1 Critical · How often: Always
Environment
iPhone 15, iOS 27.0, Safari · shop.example.com/checkout
Steps to reproduce
- Open the checkout page.
- Select Canada as the country.
- Enter the address 100 King St W, Toronto, ON, M5V 3L9.
Expected result
The Pay button becomes active.
Actual result
It stays disabled. No error shows.
Download this example to see the full report.
Bug report generator
Answer five quick questions. The report builds itself on the right, ready to copy. Nothing you type leaves your browser.
How the bug report generator works
It turns a few plain answers into a report with the structure developers and QA teams use every day, so you do not need to know any QA jargon.
- 1
Answer five plain questions
What went wrong, what you did, what should have happened, where it happened, and how bad it is. Your device and browser are filled in for you.
- 2
Check the report as it builds
The report appears next to the form as you type, laid out the way developers expect. A short note tells you if anything important is still missing.
- 3
Copy it where your team works
Pick where you will paste it (GitHub, Linear, Notion, Jira or email) and press Copy. The formatting is done for you. You can also download it as a file.
PrivateRuns in your browser. Nothing you type is sent to us.
Saves your draftClose the tab and come back later; it is still there.
Works on phonesReport a bug right from the device where you found it.
Follows the standardUses the defect report fields from the ISTQB Foundation syllabus.
How to write a bug report, step by step
This is how QA engineers write bug reports that developers can fix on the first read. It takes a few minutes, and it saves hours of messages back and forth. The generator above walks you through the same steps.
- 1
Reproduce it once more
Before you write anything, make the bug happen again and count: did it happen 3 out of 3 times, or 1 out of 5? A bug you can repeat gets fixed much faster. If it only happened once, say so and keep any screenshot you took.
- 2
Check it has not been reported already
Search your tracker for a few words from the error or the feature name. If it is already there, add your details to that report instead of opening a duplicate.
- 3
Write a title that says what and where
Put the area first, then what goes wrong and when: "Checkout: Pay button stays disabled after entering a Canadian postal code". Avoid titles like "Checkout broken" or "Urgent bug", which force people to open the report to know what it is.
- 4
Say where it happened
Give the device, operating system, browser and their versions, the page URL or app screen, the app version or build, whether it was the live site or a test site, and the account or role you used. Many bugs only happen in one browser or for one type of user.
- 5
Write the steps from a clean start
Start from a state anyone can reach, such as logged out or an empty cart, and number each action: one click, one field, one step. Include the exact data you typed, like the email, the coupon code or the address. If someone can follow your steps without guessing, the bug is half fixed.
- 6
Describe what should happen and what happened
Write the expected result based on the requirement or plain common sense, then the actual result. Copy error messages word for word instead of describing them. "Nothing happens" is useful too, if that is what you saw.
- 7
Rate how bad it is
Pick a severity: blocks everything, serious, minor or cosmetic. Leave priority to the team unless you are asked; how soon to fix something is a business decision. See the severity vs priority section below for examples.
- 8
Add evidence, without personal data
A screenshot with the problem circled, or a 10 to 30 second screen recording, saves a lot of back and forth. For web bugs, add console errors; for apps, the build number and time it happened. Blur passwords, tokens, emails and card numbers before you attach anything.
- 9
Send one bug per report and stay reachable
If you found three problems, write three reports so each can be fixed and retested on its own. Then keep an eye on the report for questions, and retest when the fix is ready. If the bug is a security problem, report it privately to the team instead of a public tracker.
Download a blank bug report template
The same fields as the generator, ready for your own tools: Excel, Word, PDF, Markdown or a GitHub issue form. Free to download, no email needed.
ExcelBug log for Excel and Google SheetsOne row per bug, dropdowns for severity, priority and status, and a filled-in example. For Google Sheets: File, Import, Upload.DownloadWordBug report form for WordA one-page form to fill in and send, with the severity scale on the page.DownloadPDFPrintable bug report formPrint it for test sessions and user testing, or fill it in on a tablet.DownloadMarkdownBug report in MarkdownFor GitHub, GitLab, Linear, Notion or any tool that reads Markdown.DownloadGitHubGitHub issue formSave it as .github/ISSUE_TEMPLATE/bug_report.yml and every new bug gets the same fields.Download
QA testing by BugsQA
Launching soon? Let us find the bugs first
Templates help you report bugs. BugsQA finds them: our QA team tests your web or mobile app on real phones and browsers and sends reports like these, ready for your developers.
- Bug reports with steps, evidence and severity
- Real iPhones, Android phones and browsers
- Fixes retested before you release
- US and Canadian time zones
Talk to a QA lead, free
A 30-minute call. We look at your app and tell you what to test first, even if you test it yourself.
Get a free QA consultationSee pricingWebsite bug report template
Website bugs often depend on the browser and screen size, so a website bug report needs the page URL, the browser and version, the device or screen size, and a screenshot. Always check whether the bug also happens in a second browser: Safari on iPhone and Chrome on Android behave differently, and together they cover most mobile visitors in the US and Canada.
Use this template when clients, teammates or beta users report problems on your site, or fill in the generator and choose "Email or other".
Title: [What is broken] on [which page] Page URL: Browser and version: (for example Safari 27, Chrome 141) Device and screen size: (for example iPhone 15, or laptop 1440 x 900) Steps to reproduce: 1. 2. 3. Expected result: Actual result: Screenshot or screen recording: (attach it) How bad is it: Blocks everything / Serious / Minor / Cosmetic Happens on other browsers too? Yes / No / Not checked
Jira bug report template
In Jira, create an issue with the type Bug. Put the title in the Summary field, set Jira's Priority field, and paste the rest into Description. The fastest way: fill in the generator, choose Jira and press Copy; the headings and lists keep their formatting in Jira Cloud.
The blank template on the right uses Jira wiki markup (h3. for headings, # for numbered steps), the text format of Jira Server and Data Center. In Jira Cloud, use the generator's Jira option instead, which pastes as formatted text. For Trello, choose "GitHub, Linear or Notion" in the generator and paste the Markdown into the card description.
Summary (Jira field): [Area]: [what is wrong] when [action] Description: h3. Environment * Page or screen: * Device, OS and browser: * App version or build: * Account or role: h3. Steps to reproduce # # # h3. Expected result h3. Actual result h3. How often Always / Sometimes (x of y tries) / Once Severity: S1 Critical / S2 Major / S3 Minor / S4 Trivial Attachments: screenshot, screen recording, console log
Bug report form template
When bugs come from customers, clients or beta testers, a form gets you better reports than an open email. Use these questions in Google Forms, Microsoft Forms, Typeform or Jotform. They are written for people who are not testers, so they ask what happened in plain words instead of using QA terms.
For a software team on GitHub, the GitHub issue form turns the same fields into a form inside your repository.
1. What went wrong? (short answer, required) 2. Which page or screen were you on? (short answer) 3. What were you trying to do? (paragraph, required) 4. What did you expect to happen? (paragraph, required) 5. What happened instead? (paragraph, required) 6. Which device and browser? (short answer, or detect it automatically) 7. How bad is it for you? (multiple choice: I cannot continue / It is a big problem / It is annoying / It just looks wrong) 8. Screenshot or video (file upload) 9. Can we contact you about this? (email, optional)
Software bug report template
QA and development teams need more than the basics: the build or version, the environment, the account used, preconditions, logs, priority and status, so bugs can be triaged, fixed and retested. This full software bug report template has every field from the ISTQB defect report list.
To track many bugs in one place, use the Excel bug log: one row per bug, with dropdowns for severity, priority and status.
Bug ID: Title: Reported by and date: Severity: S1 Critical / S2 Major / S3 Minor / S4 Trivial Priority: P1 Urgent / P2 High / P3 Medium / P4 Low Status: New / Open / In progress / Fixed ready to retest / Reopened / Closed / Deferred / Duplicate / Rejected Environment - URL or app screen: - Environment: Production / Staging / Development - App version or build: - Device and model: - OS and version: - Browser and version: - Account or role used: Preconditions: Steps to reproduce: 1. 2. 3. Expected result: Actual result: How often: Always / Sometimes (x of y) / Once Logs and evidence: (console errors, network response, screenshots, video) Workaround: Related test case or story:
What a good bug report includes
A developer should be able to reproduce the bug from your report alone, without asking you a single question. These fields make that possible. They follow the defect report contents in the ISTQB Foundation Level syllabus (v4.0.1, section 5.5).
Titles that get bugs fixed
Good: Checkout: Pay button stays disabled after entering a valid Canadian postal code
Too vague: Checkout broken
Always include
- Title
- What is wrong, where. Short and specific.
- Environment
- Where you saw it. Include: url or app screen, environment (production or staging), app version or build, device and model, os and version, browser and version, screen size, account or role used, network.
- Steps to reproduce
- Numbered, one action per step, starting from a known place. Include the exact data you typed.
- Expected result
- What should happen, based on the requirement or common sense.
- Actual result
- What actually happened. Include exact error text.
- How often
- If sometimes, say how many times out of how many tries.
- Severity
- How bad the impact is.
Add when you can
- Summary
- One or two sentences on impact: who is affected and how.
- Preconditions
- What must be true before step 1 (logged in as a customer, cart has 2 items).
- Priority
- How soon to fix. Often set by the product owner during triage.
- Screenshots, video and logs
- A screenshot or short screen recording, console errors, network response. Hide passwords and personal data.
- Workaround
- Any way users can get around it for now.
- Related test case or story
- Test case ID, user story or requirement.
Severity vs priority
Severity is how bad the impact is. Priority is how soon it should be fixed. They are set separately. A typo in the company name on the homepage is trivial severity but urgent priority. A crash in a yearly admin export is critical severity but may be medium priority.
Severity: how bad is it?
S1Critical (blocks everything)
The app crashes, loses or exposes data, has a security hole, or a core flow (signup, login, checkout, payment) is blocked with no workaround.
For example: Checkout charges the card but no order is created. Any logged-in user can open another user's invoices by changing the ID in the URL. The app crashes on launch on iOS 27.
S2Major (serious)
An important feature is broken or gives wrong results, and the workaround is hard or not obvious.
For example: Password reset emails never arrive. Search ignores the category filter.
S3Minor (minor)
A feature works but with a problem that has an easy workaround or affects few users.
For example: The date picker opens behind the keyboard on small Android phones. An error message is shown in the wrong place.
S4Trivial (cosmetic)
Cosmetic issue that does not affect how the app works.
For example: A typo in the footer. An icon is 2 pixels off.
Priority: how soon to fix it?
P1Urgent
Fix now, before release or as a hotfix.
In Jira: Highest
P2High
Fix in this release or sprint.
In Jira: High
P3Medium
Fix in a coming release.
In Jira: Medium
P4Low
Backlog. Fix when there is time.
In Jira: Low
Bug report examples
Seven complete bug reports, from a serious payment bug to a small layout problem. Each one comes from a test case in the BugsQA QA library, so you can see what a failed test looks like when it is reported well. Load any of them into the generator to see it in your tool's format.
Checkout: Pay button stays disabled after entering a valid Canadian postal code
- Priority
- P1 Urgent
- How often
- Always (5 of 5 tries). Same on desktop Chrome. Works without the space (M5V3L9).
- Environment
- https://shop.example.com/checkout, production, web build 2.4.1, iPhone 15, iOS 27.0, Safari, 393x852, logged-in customer, wifi
- Before you start
- Logged in as a customer with 1 item in the cart.
Steps to reproduce
- 1.Open the checkout page.
- 2.Select Canada as the country.
- 3.Enter the address 100 King St W, Toronto, ON, M5V 3L9.
- 4.Fill in all other required fields.
- 5.Look at the Pay button.
Expected
The Pay button becomes active and the order total shows HST.
Actual
The Pay button stays disabled. No error message is shown. The console shows: 'Invalid ZIP code format'.
Evidence: checkout-canada.mp4, console-error.png
Workaround: Enter the postal code without the space.
Login: error message reveals whether an email has an account
- Priority
- P2 High
- How often
- Always (3 of 3 tries)
- Environment
- https://app.example.com/login, production, build 3.2.0, Windows 11, Chrome 141
- Before you start
- Logged out. An account exists for jane@example.com.
Steps to reproduce
- 1.Enter jane@example.com and a wrong password, then select Log in.
- 2.Note the message.
- 3.Enter nobody@example.com (no account) and any password, then select Log in.
Expected
Both attempts show the same generic message, such as "Email or password is incorrect".
Actual
The first shows "Wrong password". The second shows "No account found for this email". Anyone can check which emails are registered.
Evidence: login-messages.png (both messages side by side)
Workaround: None for users. Fix is a single message for both cases.
Checkout: double-clicking Pay charges the card twice
- Priority
- P1 Urgent
- How often
- Sometimes (4 of 5 tries with a fast double-click)
- Environment
- https://shop.example.com/checkout, staging (Stripe test mode), build 2.4.1, MacBook Air, macOS, Safari 27
- Before you start
- Logged in as a customer with 1 item in the cart. Stripe test mode.
Steps to reproduce
- 1.Go to checkout and fill in all details.
- 2.Enter the test card 4242 4242 4242 4242, expiry 12/34, CVC 123.
- 3.Double-click Pay quickly.
Expected
One charge and one order. The Pay button is disabled after the first click.
Actual
Two charges of $48.00 appear in the Stripe dashboard and two order confirmation emails arrive. Only one order shows in the account.
Evidence: double-charge.mp4, stripe-dashboard.png (two payments 0.4 seconds apart)
Workaround: Refund the duplicate charge manually in Stripe.
Android 16: back gesture on the address form exits the app and empties the cart
- Priority
- P2 High
- How often
- Always on Android 16 (3 of 3). Not on Android 15 or iOS.
- Environment
- Android app 5.1.0 (build 512) from Play internal testing, Samsung Galaxy S25, Android 16, gesture navigation
- Before you start
- Logged in, 2 items in the cart.
Steps to reproduce
- 1.Open the cart and select Checkout.
- 2.Type part of an address on the shipping form.
- 3.Swipe back from the left edge of the screen.
Expected
The app goes back to the cart and keeps the items and the typed address (or asks before discarding it).
Actual
The app closes. When reopened, the cart is empty.
Evidence: back-gesture.mp4 (12 seconds)
Workaround: Use the on-screen back arrow in the app header instead of the gesture.
API: any logged-in user can read other users' orders by changing the order ID
- Priority
- P1 Urgent
- How often
- Always (every order ID tried)
- Environment
- https://api.example.com/v2, staging, build 7.3.0, tested with Postman
- Before you start
- Two test accounts: user A (order 10482) and user B (order 10483).
Steps to reproduce
- 1.Log in as user A and copy the access token.
- 2.Send GET /v2/orders/10482 with user A's token. The order is returned (correct).
- 3.Send GET /v2/orders/10483 with user A's token.
Expected
403 Forbidden or 404 Not Found. User A cannot see user B's order.
Actual
200 OK with user B's full order, including name, address and the last 4 digits of the card.
Evidence: postman-request-and-response.png (personal data blurred)
Workaround: None. Reported privately to the team lead, not in the public tracker.
Signup: every field is cleared when the password is too short
- Priority
- P2 High
- How often
- Always (3 of 3 tries)
- Environment
- https://app.example.com/signup, production, iPhone 15, iOS 27.0, Safari
- Before you start
- Logged out.
Steps to reproduce
- 1.Fill in name, email, company and phone.
- 2.Enter a 6-character password and select Create account.
Expected
Only the password field shows an error. Everything else stays filled in.
Actual
The error shows, but name, email, company and phone are all empty again.
Evidence: signup-cleared.mp4
Workaround: Type everything again with a longer password.
Pricing page: "Start free trial" button text spills out of the button on small iPhones
- Priority
- P3 Medium
- How often
- Always at 375 pixels wide and below
- Environment
- https://example.com/pricing, production, iPhone SE (3rd generation), iOS 27.0, Safari, 375x667
- Before you start
- None.
Steps to reproduce
- 1.Open the pricing page on a 375 pixel wide screen.
- 2.Scroll to the Pro plan card.
Expected
The button text fits inside the button on one or two lines.
Actual
"Start free trial" runs past the right edge of the button and over the card border.
Evidence: pricing-button-375.png
Workaround: None needed. The button still works.
Rather have someone find the bugs for you?
BugsQA tests web and mobile apps and sends reports exactly like the examples above, with steps, evidence and a retest once it is fixed.
Frequently asked questions
What should a bug report include?
A good bug report has a specific title, the device and browser (plus app version and URL), numbered steps to reproduce, the expected result, the actual result, how often it happens, a severity, and a screenshot, video or log. These are the same fields the ISTQB Foundation syllabus lists for a defect report, and they are what a developer needs to reproduce and fix the bug without asking you questions.
How do you write a good bug report?
Write one bug per report, reproduce it once more before you send it, and start your steps from a clean state such as logged out or an empty cart. Use a title that says what is wrong and where, copy the exact error text, say how often it happens, and attach a screenshot or short screen recording. Stick to facts about the behavior and remove passwords and personal data from anything you attach.
What is the difference between severity and priority?
Severity is how bad the impact is, and priority is how soon it should be fixed. They are set separately: a typo in the company name on the homepage is trivial severity but urgent priority, while a crash in a report that runs once a year can be critical severity but medium priority. Testers usually set severity, and the product owner sets priority during triage.
How do I use this bug report template in Jira?
In the generator, choose Jira under "Where will you paste it?", press Copy, and paste into the description of a new Bug issue; the headings and lists keep their formatting in Jira Cloud. Put the title in the Summary field and set Jira's own Priority field. If your company runs Jira Server or Data Center, use the "Copy as wiki markup" link that appears under the Copy button.
Can I use this template for GitHub issues?
Yes. Choose GitHub, Linear or Notion in the generator and paste the copied Markdown into a new issue, or download the GitHub issue form and save it as .github/ISSUE_TEMPLATE/bug_report.yml so everyone who opens a bug gets the same fields.
Is this bug report template free, and do you store what I type?
It is free with no signup. The generator runs entirely in your browser, so nothing you type is sent to BugsQA; your draft is only kept in your own browser so you do not lose it if you refresh the page.
Build your QA plan