How-To Guides

The Ultimate Guide to Bug Tracking in Jira

Last updated:
April 9, 2021

If you work with Jira, you understand it is incredibly powerful... but also not the most intuitive tool. So, when it gets used for bug and issue tracking, there are a number of problems and mistakes that keep getting made.

As a result, bug often get reported in a way that is difficult to organise and resolve.

So, whether you are a product manager trying to keep projects organised or a reporter trying to get bug reports right the first time, this post is for you!

1. Set up your bug tracking process

First, decide where you want your bugs and issues to go.

You can do that per project you are working on, or one big project where all feedback arrives.

Method 1: a dedicated bug tracking project

The easiest way to do bug reporting with a team of reporters is having the issues sent to a dedicated bug project.

In this project, which you should name something obvious like "bug tracking project", you need to define a workflow.

We opted for a flow with few, but easy to follow steps.

  1. To do
  2. Assigned
  3. Scheduled
  4. In progress
  5. Done

When working with these clearly defined stages, it is easy to see priorities as they pop up!

Another perk of the dedicated bug tracking project is that you can easily keep an organised backlog. Developers love knowing where to go to pick up a less urgent issue when they have the time.

The downside of this one big project is of course that a PM has to go in and divide all issues.

In this dedicated bug reporting project, it is easy to see what needs to be done next.

Method 2: create a dedicated issue type

If you decide to go for dedicated issue types versus a dedicated project for feedback collection, there is only one rule: make sure everyone is on the same page.

All issue types and their custom fields can work, but everyone must have the same understanding of them.

We opt for these custom issue types for reporting to keep things flowing smoothly:

  1. bug
  2. design feedback
  3. general feedback/ideas

Of course, if you only work with internal testers, it is easier to get everyone on the same page.

Don't be shy to use the custom fields that Jira allows to keep track of bugs. With a tool like, the custom fields and issue types all have their own submission forms, so you get all desired information!

Set up your issues the way you need them to be the most efficient for your workflow.

All to help your devs to decide on what to work on next!

2. Define your bug reporting flow

In this next step, it is good to think about the people who will be reporting, since developers all need the same thing (we'll talk about that below).

There are generally two types of reporters, and that is people with access to your Jira projects and people without access.

Jira users

For Jira users, you can let them report straight into the correct Jira project. They understand how it works and what the issue types mean.

However, reporting issues and bugs into Jira is time consuming.

A regular bug reporting flow looks something like this:

  1. Spotting a bug
  2. Taking a screenshot
  3. Going to Figma/Photoshop/... to pull in the screenshot
  4. Annotating it
  5. Pasting the annotated screenshot into a new Jira issue (into the correct project!)
  6. Assigning the issue to the correct person, adding the labels,...
  7. Typing out long explanations
  8. Manually adding technical info (and sometimes forgetting some 😅)
  9. Saving it and sending it off to the developers

If you don't want them to spend the time doing all this, you can always opt for a bug reporting tool like With, you:

  1. Set up the project you want the bugs to go to
  2. Click the button when spotting a bug
  3. Screenshot and annotate on-site
  4. Send it off, all technical info automatically attached for your devs integrates deeply with your Jira projects, so you can start reporting straightaway!

Need some more information on how you can use to transform Jira into an efficient bug tracking tool? Watch the video 👇

Non-Jira users

For your reporters who don't have access to Jira, you have two similar options.

  1. You request detailed emails that one of your team members translates into Jira issues
  2. You let them use too

With there is a Guest option, which means that they see a limited submission form so internal details stay secure, and you still get all information sent straight into your Jira.

With Guests, it is definitely advisable to set up a dedicated Jira project for bug tracking. The PM can easily go in and check the issues before sending them to the devs! An extra step that saves you a lot of time in the long run.

3. Create a system to prioritise bugs

Ideally, all reporters have a good grip on the levels of severity of bugs. Unfortunately that is often not the case!

What a designer might consider "critical" might look like child's play in the eyes of the developers, so agreeing on levels and labels really matters.

We decided to go with a classic system:

  1. Highest
  2. High
  3. Medium
  4. Low
  5. Lowest

In this ranking and with our dedicated bug reporting project, we do not necessarily need a label for "bug" or "design element".

We still like to label Jira issues as well, mostly when they are NOT essentially bugs.

Look at this example 👇

What I spotted was a missing image on the pricing page. It is very important to have a pleasing pricing page, but it is not necessarily a bug. We needed a specific issue type!

Having devs fix some slightly wonky spacing in the side bar is less important than a visual missing on the pricing page!

Knowing what to tackle first can make all the difference.

4. Create efficient communication

To understand and clarify every issue that gets sent in, you need a separate communication flow. Because one of the biggest problems when it comes to using Jira for bug reporting, is that you need to do a lot of flipping between tools to collect all information.

If you send your devs issues like this 👇 they will most definitely get back to you to ask for more information!

Developers have a baseline of information they need if they want to resolve bugs in a timely fashion! The more complicated a bug is, the more additional information they need.

If you want to reduce time-wasting phone calls and frustrated developers, you need to be concise and complete at the same time.

Your devs will need all this information:

  1. Title
  2. Description/summary
  3. Reporter's information
  4. Source URL
  5. Console logs
  6. Environment: browser, operating system, zoom level and screen size
  7. Visual proof

Want your developers to love you? The tickets you create through automatically get enriched with technical metadata and console logs. You can also communicate with your reporters from within Jira!

Even the most perfect issues might require some more information or details, so it is important to pre-plan how that communication is going to happen.

In most cases, teams resort to either email or phone calls. If you use a tool like though, you can use the internal messaging system.

With, you get the messages of your clients or external reporters straight into your Jira issue! Super helpful when you are trying to work fast.

There is no reason to sit on questions.

5. Resolve bugs and notify the reporters

After you or your developers close a Jira issue, you need to notify the reporter. This also prevents impatient follow-up emails or calls 😉

It is always advisable to use the same channels of communication as you used before. Anything that reduces possible miscommunication and lost information, is a win!

Option 1: Email

It is an obvious choice, with good reason. People check their emails all the time and if you have let them submit their issues in the first place, it is a good channel.

When sending emails, always attach:

  1. The issue number
  2. The title
  3. A screenshot of the issue before it got resolved

Especially when working with people who have no access to your Jira and who report a lot. They tend to forget the details of what they reported.

Option 2: comes with automated status-sync. This means that when you close an issue in Jira, it automatically also closes in

Your reporters get notified through automated email or Guest Portal update. A good way to save time!


Jira as a project management system is as popular as it is for good reason! It is powerful, highly customisable, and allows complex workflows with ease.

For bug reporting, either set up a strict flow with a dedicated PM, or get a visual bug reporting tool like

When deciding on the best visual bug reporting tool, take into account if you want everything to get two-way synced with your Jira account, or if you want a separate tool. With, you get a powerful two-way sync, easy collaboration with clients and non-technical team members, and happy developers.

Get →

Continue reading

Speed up website testing and collect client feedback!

Start free trial
Free 15-day trial  •  No credit card required •  Cancel anytime