How to Write a Good Bug Report in Jira (Steps, Expected, Actual)
A bug report a developer can fix on the first read: a clear title, numbered steps to reproduce, expected and actual result, and the epic it belongs to. Written step by step in Jira.
Step by step
A good bug report
- Bug report in Jira. A vague bug report can cost a developer a whole day. A clear one gets fixed on the first read. Here is one written in Jira, step by step.
- Create. Click the Create button at the top of Jira to open a new work item.
- Pick Bug. Click the work type and pick Bug, the one with the red icon.
Write it
- What is wrong. The title says what is wrong and where. "Basket broken" is too vague. "Basket total wrong after removing an item" tells the developer exactly where to look.
- Steps to reproduce. Next, write the steps to reproduce as a numbered list, with one action per line: 1. Add two mugs to the basket, 2. Remove one mug, 3. Look at the basket total. Anyone can follow them and make the bug happen again.
- Expected. Then write what should happen: "Expected: the total shows the price of one mug."
- Actual. Then write what really happens: "Actual: the total still shows the price of two mugs." Expected versus actual is the heart of every bug report.
Link and create
- Parent epic. Link the bug to its parent epic, Checkout, so it shows up with the rest of the checkout work. Pick Checkout from the list.
- Create. Click Create to save the bug.
- In the backlog. The bug now sits in the backlog with the red bug icon, ready for the next sprint planning.
Recap
- Steps, expected, actual. In short: a title that says what and where, numbered steps to reproduce, the expected result, then the actual result, and the epic it belongs to.
Common mistakes
- A title that only says something is broken. "Basket broken" gives the developer nothing to search for. Say what is wrong and where, for example "Basket total wrong after removing an item".
- Steps written as one long sentence. If the steps are in one paragraph, people miss one and can't make the bug happen again. Use a numbered list with one action on each line.
- Only describing what went wrong. Without an expected result, the developer has to guess what correct looks like. Always write Expected and Actual on separate lines.
- Leaving the bug without a parent epic. An unlinked bug is easy to miss when the team plans that feature's work. Set the parent epic, like Checkout, before you click Create.
When a business analyst uses this
During user acceptance testing, a business analyst logs a Bug when a test fails an acceptance criterion. The criterion becomes the Expected line, what the tester saw becomes the Actual line, and the parent epic makes the open bug show up with the rest of that feature's work before sign-off.
Questions people ask
How do I create a bug report in Jira?
Click Create at the top, set the work type to Bug and write a title that says what is wrong and where. Add the steps to reproduce, the expected result and the actual result, set the parent epic, then click Create.
What should a good bug report include?
It needs a clear title, numbered steps to reproduce, the expected result and the actual result. Linking it to its epic keeps it with the related work.
Is a defect report the same as a bug report in Jira?
Usually, yes. Most teams log defects with Jira's Bug work type, and you write it the same way: steps to reproduce, expected result and actual result.
