A good bug report lets another person understand, reproduce and investigate the problem without guessing.
Before reporting
- Reproduce the issue and remove unrelated steps.
- Check the expected behaviour in requirements or with the product owner.
- Search for an existing report.
- Check another browser, user or environment when useful.
- Collect evidence while the issue is visible.
Effective title
Use: area + action + problem + condition.
Checkout — Place order creates two orders after a retry
Avoid:
Checkout broken
Button does not work
Report structure
| Field | What to write |
|---|---|
| Environment | Build, URL, browser, OS, device, account role and relevant data. |
| Preconditions | State required before step 1. |
| Steps | Short, numbered actions with exact values. |
| Expected | Observable result based on the requirement. |
| Actual | What happened, including message and state. |
| Frequency | For example 3/3 or intermittent. |
| Impact | Who is blocked and whether a workaround exists. |
Precondition: Signed in as a standard customer with one item in the basket.
1. Open Checkout.
2. Enter card test data ...
3. Select Place order.
4. Disconnect and reconnect the network.
5. Select Retry.
Expected: One order is created and one confirmation appears.
Actual: Two orders are created with different IDs.
Evidence
- Screenshot for a static visual problem.
- Short video for timing, movement or a multi-step flow.
- Console error and stack location.
- Network method, safe URL, status and relevant response.
- Timestamp, request ID and application log reference.
- DOM, accessibility or storage detail when relevant.
Protect data: remove passwords, tokens, cookies, personal data and production secrets before attaching evidence.
Severity and priority
| Term | Question |
|---|---|
| Severity | How badly does the defect affect the product or user? |
| Priority | How soon should the team fix it? |
- Critical: major outage, data loss, security or no viable core flow.
- High: important flow blocked with no reasonable workaround.
- Medium: feature impaired but workaround exists.
- Low: minor visual, text or edge-case issue.
Use the project's definitions. Business priority may differ from technical severity.
Final check
- Can a new team member reproduce it?
- Are expected and actual results different and measurable?
- Is every attachment relevant and safe?
- Does the title distinguish this issue from similar ones?
- Did you include the exact build and test data?