What a bug report is
A bug report is the record of a defect found in a system: the wrong behavior, the expected behavior, the steps to reproduce and the evidence. It becomes a Jira card, an Azure DevOps work item or a service desk request, and it is where the developer starts investigating.
The fields of a good bug report
- A short, specific title: what fails and where (“Coupon returns error 500 at checkout”).
- Environment: URL, browser and version, operating system, screen size, user or role.
- Numbered steps to reproduce, starting from a clear initial state.
- Expected result.
- Actual result, with the exact error message.
- Severity and impact: who is affected and whether there is a workaround.
- Evidence: screenshots or video, failed requests (status, request and response) and console errors.
- Frequency: always, sometimes, only with certain data.
Bug report template to copy
Title: [Checkout] Applying a coupon returns error 500 when a discount already exists
Environment: https://shop.example.com · Chrome 130 · Windows 11 · 1920×1080
User: regular customer, cart with 2 items
Steps to reproduce:
1. Add 2 products to the cart
2. Go to checkout (the first-purchase discount is already shown)
3. Enter the coupon WELCOME10 and click "Apply"
Expected: coupon applied, or a clear message that discounts do not stack.
Actual: "Unexpected error"; the total does not change.
Severity: high — blocks coupons for new customers.
Frequency: always.
Evidence:
- POST /api/cart/coupon → 500 response {"error":"discount already applied"}
- Console: TypeError: Cannot read properties of undefined (reading 'total')
- Video/GIF of the steps and full report attachedMistakes that send the bug back
- “It doesn’t work” without saying what, where and with which message.
- Steps that skip parts or depend on something only the reporter knows.
- A screenshot with no context: no URL, no data, nothing about what came before.
- No network or console — the developer has to reproduce it just to see the error.
- Several problems in a single bug.
- Everything marked “critical”.
Manual vs automatic bug reports
| Manual | With Capto | |
|---|---|---|
| Time to put together | Screenshots, text and DevTools put together by hand | The time it takes to reproduce the issue |
| Steps | Written from memory | Recorded from the real clicks and inputs |
| Technical evidence | Depends on the reporter knowing DevTools | Network, console and environment always captured |
| Report text | Varies from person to person | AI rewrites it in standardized technical language |
| Cause | The developer investigates from scratch | AI points to the file, line and suggested fix (with a connected repository) |
How to generate bug reports automatically
- Install the Capto extension in Chrome.
- Describe in one sentence what you were trying to do.
- Reproduce the issue. Capto records steps, screenshots, network and console.
- Review the text the AI wrote (summary, steps, expected vs actual, severity).
- Send it: the ticket is created in Jira Software, Jira Service Management or Azure DevOps with everything attached.
Frequently asked questions
What is the difference between a bug report and a defect report?
In practice they are the same document. “Defect report” is more common in formal QA processes; “bug report” is the everyday term.
Who should write the bug report?
Whoever found the problem: QA, support, product or the customer. With Capto even non-technical people produce a complete report, because the technical context is captured automatically.
Should a bug report include video?
It helps with flow and UI bugs. More important than video are the steps, the actual result with the exact message and the failed requests.
Where should bug reports go?
Into the tool the development team uses: Jira, Azure DevOps or the service desk. Capto sends them straight to Jira Software, Jira Service Management and Azure DevOps Boards.