Browse the Knowledge Hub32 resources
Template
A bug report a developer can act on without replying to ask you a question
Thirteen fields with three worked examples, including the two report types that most often bounce back: an intermittent defect and a security finding. Download as CSV or copy the format into your tracker.
The bug report template, with worked examples
Free to use and adapt, no sign-up. Download as CSV or Markdown, or copy it straight into your own tooling.
Last updated
3 worked examples
Order total excludes tax when a percentage discount code is applied
Reproduction rateAlways, 10 of 10SeverityCriticalPriorityP1- Environment
- Build 4.2.108, staging, Chrome 141 on macOS 15, account: standard customer (UK, VAT 20%)
- Preconditions
- Cart contains one taxable item at 100.00. Discount code SAVE10 (10%) is active.
- Steps to reproduce
- 1. Add the taxable item to the cart. 2. Go to checkout. 3. Apply discount code SAVE10. 4. Observe the order summary total.
- Expected result
- Subtotal 90.00, VAT 18.00, total 108.00. Tax is recalculated on the discounted subtotal per REQ-payments-14.
- Actual result
- Subtotal 90.00, VAT 0.00, total 90.00. The VAT line drops to zero as soon as any discount is applied.
- Evidence
- Screenshot of order summary, HAR of the /cart/totals response showing tax: 0
- User impact
- Every discounted order in a taxable region is undercharged. Roughly 18 percent of orders use a code, so this is a direct revenue loss and a tax compliance exposure.
- Notes
- Only reproduces with percentage codes. Fixed-amount codes calculate correctly, which suggests the discount type branch rather than tax config.
Session intermittently lost when returning from the payment provider 3DS challenge
Reproduction rate3 of 10 attempts, only on Safari iOSSeverityCriticalPriorityP1- Environment
- Build 4.2.108, staging, Safari 18 on iOS 18.2, account: returning customer with saved card
- Preconditions
- Customer has a saved card requiring 3DS. Payment sandbox in challenge mode.
- Steps to reproduce
- 1. Start checkout with the saved card. 2. Complete the 3DS challenge in the provider window. 3. Return to the application.
- Expected result
- Customer returns authenticated to the order confirmation page and the order is created.
- Actual result
- Customer is returned to the login page. The payment is captured at the provider but no order exists in our system. Server log shows the session cookie absent on the return request.
- Evidence
- Screen recording of all 10 attempts, provider transaction IDs for the 3 orphaned charges, server log extract at 14:02 to 14:19 UTC
- User impact
- Customer is charged with no order created, then sees a login screen. Requires manual refund and generates a support contact every time it occurs.
- Notes
- Suspected SameSite cookie behaviour on the cross-site return. Not reproducible on Chrome or Android. Did not occur on build 4.2.94, so likely introduced between 94 and 108.
Another customer saved payment methods returned by changing the account ID in the request
Reproduction rateAlwaysSeverityCriticalPriorityP1- Environment
- Build 4.2.108, staging, API direct via curl, account: customer A authenticated
- Preconditions
- Two customers exist, A and B, each with at least one saved payment method.
- Steps to reproduce
- 1. Authenticate as customer A. 2. Call GET /api/customers/{B_id}/payment-methods with A valid token.
- Expected result
- 403 Forbidden, or 404 if the design deliberately hides existence. No data returned.
- Actual result
- 200 OK returning customer B saved methods, including card brand, last four digits and billing postcode.
- Evidence
- curl request and response captured, with the token and account IDs redacted in the attachment
- User impact
- Broken object level authorisation on a payment endpoint. Sequential customer IDs make this enumerable, so it is a mass data exposure rather than a single-record leak.
- Notes
- The endpoint checks authentication but not object ownership. Reported privately to the security channel rather than the public board.
What goes in each field
ID
RequiredUsually assigned by the tracker. Include it in any conversation about the defect so the discussion stays attached to the record rather than living in chat.
Title
RequiredState the problem and where it happens, in one line a developer can triage from the list view. "Checkout fails" is useless; "Order total excludes tax when a discount code is applied" can be assigned without opening it.
Environment
RequiredBuild or commit, environment, browser or device with version, OS, and the account or role used. The build number is the single most requested missing field, so never omit it.
Preconditions
The state required before the steps make sense: data present, feature flags, account permissions, prior actions. Anything the developer would otherwise have to reverse-engineer.
Steps to reproduce
RequiredNumbered, minimal and complete. Trim to the shortest path that still reproduces, because a nine-step report where four steps matter wastes triage time. Include exact input values.
Expected result
RequiredWhat should happen, ideally with the source: the acceptance criterion, specification or agreed behaviour. This is what turns a disagreement about opinion into a check against intent.
Actual result
RequiredWhat happened, including exact error text, incorrect values and any console or server error. Describe the observed behaviour rather than your theory about the cause.
Reproduction rate
Always, or a rate such as 3 of 10 attempts. Quantifying an intermittent defect turns "sometimes" into data and stops it being dismissed as unreproducible.
Severity
RequiredTechnical impact on the system, set by QA: Critical, High, Medium or Low. Judge impact, not urgency, and keep it independent of how badly anyone wants it fixed.
Priority
Business urgency of the fix, owned by product rather than QA. Keeping it separate from severity is what allows a high-severity, low-priority defect to be scheduled honestly.
Evidence
RequiredScreenshot, screen recording, console log, network trace, or server log with a timestamp that lets the developer correlate. A recording of an intermittent defect is often worth more than the written steps.
User impact
Who is affected, how many, and what it costs them. This is the field that makes prioritisation possible, and the one testers most often leave blank.
Notes
Workaround if one exists, when it was first observed, related defects, and anything you ruled out. Recording what you already checked prevents the developer repeating your work.
Write for triage, not for the record
A report is read first by someone deciding whether to pick it up. Four habits decide whether that takes ten seconds or ten minutes.
Put the build number in
It is the first thing a developer asks for and the most commonly missing field. Its absence adds a round trip to every report.
Minimise the steps
Trim to the shortest path that still reproduces. Nine steps where four matter forces the developer to redo your isolation work.
Quantify intermittence
Three of ten attempts is data. "Sometimes" invites the report to be closed as unreproducible.
State user impact
Severity is technical, impact is human. Without impact, product cannot prioritise and defaults to whoever shouts loudest.
The fields that stop a report bouncing back
Every field in this template exists because its absence causes a specific round trip. Environment without a build number means the developer cannot tell whether it is already fixed. Actual result without exact error text means they search the codebase for the wrong string. Steps without input values mean they reproduce with different data and see nothing wrong.
Reproduction rate deserves particular attention, because intermittent defects are where reporting quality matters most. A report saying a payment flow "sometimes" loses the session invites a cannot-reproduce close. A report saying 3 of 10 attempts on Safari iOS, with a recording of all ten and the three orphaned transaction IDs, gets picked up the same day.
Severity and priority are deliberately separate columns with different owners. Severity is the technical impact and belongs to QA; priority is the business urgency and belongs to product. Collapsing them into one field is how teams end up arguing about a number instead of discussing the actual risk.
One note on the security example: findings like broken object level authorisation should usually go through a private channel rather than a public board, because a defect report describing an exploitable flaw is itself sensitive. The template records that decision in the notes rather than pretending it does not arise.
Suggest an improvementDefect reports slowing you down?
QAble engineers file reports developers can act on immediately, with reproduction evidence and impact stated, as part of every engagement.
Manual testing servicesMore templates and checklists
View allTest case template
Template12 fields with worked examples from a real authentication feature, plus guidance on what belongs in each column. CSV for Excel and Sheets.Test plan template
Template10 sections with per-section guidance and filled examples from a real release, trimmed from IEEE 829 to the parts that change a decision.QA release checklist
ChecklistPre-release gates across functional, regression, performance, security, accessibility and rollback readiness.API testing checklist
ChecklistEndpoint coverage from status codes and schema through auth, security and performance, with the reason each item earns its place.Mobile app testing checklist
ChecklistDevice, network, permission, lifecycle and store-readiness checks for iOS and Android releases.Regression testing checklist
ChecklistHow to scope a regression pass by impact instead of running everything, with the areas teams most often miss.Sources
- ISTQB Glossary standard definitions for the testing terms used here.
Want defects found before your users find them?
QAble finds, reproduces and documents defects with evidence. Start with a free QA audit of your product.