Bug tracking in Jira, done properly
Jira is a genuinely good bug tracker, and everything you need is already in the box: a Bug issue type, a workflow you control, priorities, JQL, and dashboards. Teams rarely struggle because Jira is missing a feature. They struggle because the Bug type was never configured, the workflow grew to fourteen statuses, and nobody set the Resolution field.
This is the setup that works: the issue type, the fields that make a bug reproducible, a five-status workflow, priority versus severity, the JQL your triage actually needs, and the dashboards that show whether quality is improving or quietly rotting.
Written for Jira Cloud. Atlassian now labels issues as “work items” in parts of the UI; the mechanics below are unchanged either way.
1. Start with the Bug issue type
Bug ships with the Jira Software project templates, but it is not guaranteed to be enabled on your project. If your team is filing bugs as Tasks, everything downstream breaks: you cannot filter them, chart them, or tell a defect apart from a piece of planned work.
- Team-managed project: Project settings, then Issue types, then add Bug. A project admin can do this without a Jira admin.
- Company-managed project: Bug lives in the issue type scheme, so a Jira admin adds it to the scheme the project uses. It then applies to every project sharing that scheme.
- Do not create a second type called Defect alongside Bug. Two types for the same thing splits every report you will ever run. If you need to separate production incidents from defects found in testing, use a label or a component.
- Do not use sub-task bugs. Sub-tasks do not appear on the backlog in their own right and cannot be scheduled independently, so bugs filed that way become invisible the moment their parent closes.
2. Log a bug a developer can actually reproduce
Press Canywhere in Jira, or use the Create button, then set the type to Bug. The mechanics take five seconds. What decides whether the bug gets fixed this week or bounces back with “cannot reproduce” is which fields you fill in.
Summary
What broke, where, and under what condition. "Checkout: Apply Coupon returns 500 when the cart total is 0" beats "coupon bug" every time, because it is the only part of the bug most people will ever read.
Description
Four blocks, always in the same order: steps to reproduce, expected result, actual result, environment and build. Jira has no default text on the system Description field, so agree a template and paste it, or have an automation rule fill it in on create.
Attachments
A screenshot, a screen recording, the browser console output, a HAR file. Attach them to the bug itself so they stay with the record rather than in a chat thread.
Affects version and Fix version
Affects version tells you where it was found, Fix version tells you where it goes out. Without both, release notes and "is this in production yet" become guesswork.
Component
The cheapest routing mechanism Jira has. Components can auto-assign a default owner, and they turn a flat bug list into a heat map of where quality actually hurts.
Priority
Ships with Jira as Highest through Lowest. Set it during triage, not at creation time, or every reporter will pick Highest.
Linked issues
Link the bug to the story or requirement it broke. This is the field teams skip, and the one that makes the difference six months later.
A useful discipline: a bug report should be readable by someone who was not in the room. If the description does not say which build it happened on, it is not a bug report, it is a note to yourself.
3. A bug workflow that does not rot
Workflows fail by growing. Someone asks for a “Waiting for QA” status, then “Ready for Deploy”, then “Awaiting Info”, and within a year nobody can say what half of them mean. Four active statuses plus Reopened covers the entire life of a bug.
| Status | What it means | Leaves when |
|---|---|---|
| Open | Reported, accepted as a real bug, waiting for someone to pick it up. | Triaged: it has a priority, a component and an owner, or it is closed as Duplicate, Cannot Reproduce or Will Not Do. |
| In Progress | A developer is actively working the fix. | A fix exists and is up for review. |
| In Review | Code review, and then verification by whoever reported it. | The reporter has re-run the failing scenario against the fixed build. |
| Done | Fixed and verified. This transition must set a Resolution. | Nothing. This is the end state. |
| Reopened | It came back, or the fix did not hold. Clear the Resolution on the way in. | Straight back to In Progress. Reopen rate is one of the most honest quality metrics you have. |
Set the Resolution, or your reports will lie to you
Status and resolution are different fields, and this catches nearly every team once. A bug sitting in Done with an empty Resolution is still unresolved as far as JQL, dashboards and release reports are concerned. Add a resolution screen or a post function to the transition into Done so a resolution is always set, and a post function that clears it on the way into Reopened.
While you are there: Duplicate, Cannot Reproduce and Will Not Do belong in the resolution list, not the status list. Endings are resolutions. Statuses are stages of work.
4. Priority is not severity
Severity is how bad the bug is when it happens. Priority is when you are going to fix it. Conflating them is why a cosmetic typo on the pricing page can legitimately outrank a crash in an admin screen three people use, and why arguments about “this is a Highest” never end.
Priority (ships with Jira)
Highest, High, Medium, Low, Lowest. A scheduling decision, owned by whoever runs triage. Set it in triage, not at creation, or every incoming bug will be a Highest.
Severity (you add it)
Critical, Major, Minor, Trivial. A factual observation, owned by whoever found the bug. Jira does not ship it: a Jira admin adds a single-select custom field and puts it on the Bug screens.
The practical rule for triage: priority is a function of severity multiplied by how many users hit it and how easily they can work around it. Write that sentence into your triage guide and most of the arguing stops.
5. The JQL your triage actually needs
Swap ABC for your project key. Save the ones you use weekly as shared filters so the whole team is looking at the same list, and remember that a saved filter can be subscribed to on a schedule, which turns the triage list into an email that arrives whether or not anyone remembers to look.
Every open bug, worst first
project = ABC AND type = Bug AND resolution = Unresolved ORDER BY priority DESC, created ASCUntriaged bugs, the daily standup list
project = ABC AND type = Bug AND status = Open AND (assignee IS EMPTY OR priority IS EMPTY) ORDER BY created ASCNew bugs raised this week
project = ABC AND type = Bug AND created >= -7d ORDER BY created DESCStale bugs nobody has touched in a fortnight
project = ABC AND type = Bug AND resolution = Unresolved AND updated <= -14d ORDER BY updated ASCBugs that came back
project = ABC AND type = Bug AND status CHANGED TO Reopened AFTER -90d ORDER BY updated DESCBugs blocking the release you are about to ship
project = ABC AND type = Bug AND fixVersion = "2.4.0" AND statusCategory != Done ORDER BY priority DESCWhere the pain is concentrated
project = ABC AND type = Bug AND resolution = Unresolved AND component = "Checkout" ORDER BY priority DESCTwo syntax notes worth knowing. type is the accepted short form of issuetype. And statusCategory != Done is safer than listing statuses by name when your projects use different workflows, because categories are fixed while status names drift.
6. Dashboards, filters and boards
A bug list nobody looks at is a bug list nobody fixes. Build one dashboard, share it with the project role rather than with individuals, and make it the thing you open in the weekly triage.
Filter Results
Your triage query, live on the dashboard. If a team looks at one gadget, make it this one.
Created vs Resolved Chart
The single most useful bug chart in Jira. If the created line runs above the resolved line for a month, you are accumulating debt no status report will admit to.
Two Dimensional Filter Statistics
Component against priority. Turns a list of bugs into a map of which area of the product is generating them.
Average Age Chart
How long unresolved bugs have been sitting. Rising age is the early warning that triage has stopped happening.
Pie Chart
Open bugs by assignee, component or priority. Good for a wallboard, weak for decisions.
On the board itself, add a quick filter of type = Bug and, if bugs regularly compete with feature work, a swimlane for them. It makes the trade-off visible in the standup instead of in the retrospective.
What to actually watch
- Created versus resolved over the last quarter. A persistent gap is debt, no matter what the sprint report says.
- Age of the oldest unresolved bug. If it is measured in quarters, triage has quietly stopped happening.
- Reopen rate. Bugs that come back point at thin verification, not at careless developers.
- Bugs per component. This is where you find the module that needs refactoring rather than another fix.
- Where bugs are found: in testing, or in production. The ratio is the clearest measure of whether your testing is working.
7. Keep the process alive
Configuration is the easy half. The half that decays is the routine around it.
- Triage on a fixed schedule, weekly at minimum. Anything that has sat in Open untriaged for five days is a process failure, not a backlog item.
- Close duplicates properly: link them with the "duplicates" link type and resolve as Duplicate, so the original collects all the evidence instead of the story fragmenting across three tickets.
- Automate the boring parts with Automation for Jira: auto-assign by component, nudge stale bugs with a comment, notify the reporter when a bug is reopened, transition on the linked pull request merging.
- Re-run the scenario that found the bug after the fix ships, not just the developer smoke check. A fix that is never re-tested is a fix nobody has verified.
- Resist logging routine test runs as issues. A 300-case regression suite run every sprint would add thousands of records that are not work, and your backlog, boards and JQL all slow down under the weight.
That last point is worth reading about properly if your Jira instance has started to feel slow: why Jira issue bloat matters covers what actually degrades when issue counts run away, and running regression cycles covers the re-testing loop after a fix.
The chain is requirement, test, bug. Keep it together.
Everything above is worth doing because Jira is the right home for a bug. It is where developers already work, where triage happens, where the fix gets assigned and burned down. Nothing on this page argues for moving your bugs somewhere else.
What tends to go missing is the other two links in the chain. A bug is the last step of a sequence: there was a requirement you promised, a test that checked it, and the bug that proves it is broken. When all three are linked, two questions that are normally guesswork become lookups: which requirement is at risk because of this bug, and what else does this bug threaten.
That is what BesTest adds. It is a requirement and test management app built on Atlassian Forge, so it is a Jira app rather than a separate tool with its own login. When a tester fails a step in the test player, they create the bug from right there, and it is created as a real Jira issue in your project, carrying the test context with it: the case, the step that failed, what was expected, and the requirement behind it. Screenshots, logs and other evidence go on that Jira issue, exactly where the developer expects to find them.
- Bugs stay Jira issues, in your workflow, on your board, in your reports. Nothing about the process above changes.
- The bug arrives already linked to the test that found it and the requirement that test covers, so triage starts with context instead of questions.
- Coverage is significance-weighted, so a requirement counts as covered when it has enough testing for its complexity and impact, not because someone linked one test to it.
- Requirements, test cases and executions live in a dedicated, secure database rather than as Jira issues, so a full regression cycle adds nothing to your backlog.
- Host your data in the EU, US, or India.
Common questions about bug tracking in Jira
How do I log a bug in Jira?
Press C or use the Create button, pick the project, and set the type to Bug. Write a summary that says what broke and under what condition, then use a fixed description structure: steps to reproduce, expected result, actual result, and environment or build. Attach a screenshot or console output, set the Affects version and Component, and link the bug to the story or requirement it breaks. Leave Priority for triage rather than setting it yourself, otherwise every report arrives as Highest.
What is a good bug workflow in Jira?
Open, In Progress, In Review, Done, plus a Reopened status for bugs that come back. Four active states plus Reopened is enough for almost every team. The two rules that matter more than the shape of the workflow: the transition into Done must set a Resolution, and the transition into Reopened must clear it. Statuses like Duplicate, Cannot Reproduce and Will Not Do should be resolution values, not extra statuses, otherwise your workflow grows a branch for every possible ending.
Why do my closed bugs still show as unresolved in Jira?
Because status and resolution are two different fields. A bug can sit in Done with an empty Resolution field, and JQL that filters on resolution = Unresolved will still return it. Fix it by adding a Resolution screen or a post function to the transition into Done so a resolution is always set, and a post function that clears the resolution when a bug is reopened. Then clean up the existing backlog with a bulk change on resolution = Unresolved AND statusCategory = Done.
What is the difference between priority and severity in Jira?
Severity is how bad the bug is when it happens: data loss, crash, cosmetic. Priority is when you are going to fix it. They are not the same, which is why a cosmetic typo on the pricing page can outrank a crash in an admin screen three people use. Jira ships with Priority only. If you want severity as well, a Jira admin adds a single-select custom field with values such as Critical, Major, Minor and Trivial, and puts it on the Bug screens. Severity is set by whoever found the bug, priority is set in triage.
How do I find all open bugs in Jira?
Use JQL rather than the issue navigator filters: project = ABC AND type = Bug AND resolution = Unresolved ORDER BY priority DESC, created ASC. Save that as a filter, share it with the team, and add it to a dashboard with the Filter Results gadget. A saved filter can also be subscribed to on a schedule, so the triage list lands in your inbox each morning instead of relying on someone to remember to look.
Should I store test cases as Jira issues so bugs can link to them?
It is tempting, because Jira links are excellent and it makes the connection between a test and a bug trivial. The cost is volume: a 300-case regression suite run every sprint turns into thousands of issues that are not work, and your backlog, boards, JQL and reporting all get slower and noisier. The better arrangement keeps bugs as real Jira issues, where they belong, and keeps test cases and executions outside the issue tracker while staying linked to it. That way the traceability survives and the backlog stays a backlog.
Can automated tests create Jira bugs automatically?
Yes. Jira has a REST API for creating issues, and Automation for Jira can create, transition and assign bugs from rules or from incoming webhooks, so a CI pipeline can raise a bug on a failed run. The thing worth designing before you switch it on is de-duplication, because a flaky test that fails on every nightly build will happily open a new bug every night. Search for an existing open bug with the same signature first, and comment on it instead of creating a duplicate. On the BesTest side, the REST API and MCP server that let automated runs report results and defects back with their test context are in closed beta, available on request, with general availability to follow.
Ready to Get Complete
Testing Visibility?
Start using BesTest today and experience complete testing visibility from requirements to release. Free to get started!
Available on the Atlassian Marketplace. Install in seconds, free for up to 10 users.
Start Free on Marketplace