Q2 of 14 · JIRA
What makes a good bug report in JIRA? Walk through the key fields.
Short answer
Short answer: A good bug report gives a developer everything they need to reproduce the issue without asking follow-up questions: a clear title, reproduction steps, expected vs actual result, environment details, severity/priority, and evidence (screenshots, logs, network traces).
Detail
Summary (title) — short, specific, searchable. Describe the symptom, not the cause:
- Bad: "Checkout broken"
- Good: "Payment fails with Visa card when cart total exceeds £500 — 500 error returned"
Description — standard structure:
Steps to reproduce:
- Log in as a standard user
- Add 3 items totalling £501 to the cart
- Proceed to checkout and enter a Visa card ending in 4242
- Click "Pay now"
Expected result: Order is placed and confirmation page is shown.
Actual result: A generic "Something went wrong" page appears. The network tab shows a 500 response from POST /api/payments.
Environment:
- App version / build: 2.4.1-RC3
- Browser: Chrome 124 / macOS Sonoma
- Test environment: staging.example.com (as of 2024-05-15 14:30 UTC)
- Test account: testuser+checkout@example.com
Severity vs Priority:
- Severity = how bad is the impact? (Blocker / Critical / Major / Minor / Trivial)
- Priority = how urgently must it be fixed? (P1 / P2 / P3 / P4)
Attachments: screenshot of the error page, HAR file or network log showing the 500 response, console error log.
Linked issues: Link to the story this was found in, any duplicate bugs.
A bug that takes a developer 5 minutes to reproduce is fixed faster than one that takes 2 hours to understand.