How to Set up a Bug Tracking System Using Jira

Jira is a powerful and customizable task tracking tool that’s well known for its bug tracking functionality.

Developers use the tool to easily locate, track, and record bugs within software. In fact, this functionality is a core component of Jira‘s project management solution, making it the go-to choice for software development teams. Since all issues are available in a single view, teams can easily decide the priority level of every reported bug.

In this guide, we’ll explore everything you need to know about setting up a bug tracking system using Jira.

Step 1 — Select Your Bug Tracking Process

The first thing to decide is where you want your bugs and issues to go.

You have two options here: You can do this on a per-project basis, or you can have a single large project to gather all your feedback at once. Read on as we discuss both these methods in more detail below.

Method #1: Having a Dedicated Bug Tracking Project

This is the easiest way to do bug reporting, with a team of reporters taking full responsibility for the project. For clarity’s sake, you should name this project something obvious like “bug tracking project.”

Here’s an example of what a workflow could look like with a few easy-to-follow steps:

To do
Assigned
Schedule
In progress
Done

As you can see, each of the above stages is clearly defined. This makes it easier for the involved team members to prioritize tasks as they pop up.

The other advantage of having a dedicated bug tracking project is the organized backlog. This way, developers will know where to go when they have extra time on their hands and can deal with a less urgent issue.

The only downside of this method is that a PM has to go in and divide all issues.

Nevertheless, if you want a system that gives team members a clear view of what needs to be done, setting up a dedicated bug tracking project would be your best bet.

Method #2: Having a Dedicated Issue Type

All issue types and their custom fields under this method can only work if everyone shares the same understanding of them. Precisely why you should proceed with this rule only when you’re sure everyone is (and is willing to be) on the same page.

As you may have guessed, this method is best for companies that have internal testers since it’s far easier to get everyone on the same page.

You can opt for the following custom issue types for reporting to prevent delays:

Bug
Design feedback
General feedback/ideas

You can also use the custom fields that Jira allows to keep track of bugs. Moreover, you’ll find several tools where every custom field and issue type has its own submission forms, which will give you access to all the information you want.

Whatever your choice, just aim to set up your issues in a way that makes your workflow as efficient as possible.

Step 2 — Define Your Bug Reporting Flow Based on Your Reporters

Before defining your bug reporting flow, you have to consider the people who will do the actual reporting. You can put developers in the backseat for now as most of the time they have the same requirements.

There are two types of reporters: Ones that have access to your Jira projects and the others who don’t. We’ll decode both these categories of reporters in more detail below.

People Who Have Access to Your Jira Projects (Jira Users)

If your reporting team comprises Jira users who already know how the software works and what the issue types are, you can have them report straight into the correct Jira project. The only catch? Reporting issues and bugs into Jira can be incredibly time-consuming.

In this scenario, a regular bug reporting flow would look something like this:

Spotting a bug
Taking a screenshot
Going to Photoshop, Figma, or similar imaging software to pull in the screenshot
Annotating the screenshot
Pasting the annotated screenshot into a new Jira issue, taking care to add it into the right project
Assigning the issue to the correct person, adding the labels, and so on
Typing out long explanations concerning the bug
Manually adding technical information
Saving it and sending it off to the developers

Alternatively, you can use a bug reporting tool to simplify setting up the project you want the bugs to go to, screenshot and annotate on-site and pass it down to your dev team with all the technicalities automatically attached. This is definitely simpler and faster than the traditional bug reporting flow.

People Who Do Not Have Access to Your Jira Projects (Non-Jira Users)

If your team of reporters that don’t have access to Jira, you can choose between two options:

You can request detailed emails, which will then be translated into Jira requests by a team member
You can use a bug reporting tool that has a Guest option

Of course, you might have to give additional training to reporters if you decide to use the bug reporting tool. But even then, the overall process will be much faster than manually translating emails into Jira issues.

Step 3 — Set Up a System to Prioritize Bugs Effectively

In a perfect world, all reporters will be able to work with bugs based on the severity levels. Unfortunately, we don’t live in a perfect world, and prioritizing bugs is one of the most common issues reporters face.

Additionally, every team member must agree on severity levels and bug labels. For example, a task that might be too critical for a designer would be child’s play for the developers. It’s why effective communication is so crucial here.

Every team member should reach a mutual decision to avoid misunderstandings and knowledge gaps. When it comes to setting bug priority, there’s a classic system that you can follow:

Highest
High
Medium
Low
Lowest

Because of this self-explanatory and detailed bug reporting project, there’s no need to have a label for, say, a “bug” or “design element.“ However, you can still label Jira issues, especially when they aren’t really bugs.

For instance, if you find the About Me page is missing an image—something that will make the web page more appealing to visitors—you cannot categorize this as a bug. Instead, you have to treat it as an issue, which also means it’ll require a specific issue type.

Knowing what to tackle first can make all the difference in your team’s productivity. After all, having a developer add a crucial visual image on your pricing page is more important than fixing a slightly misplaced sidebar.

Step 4 — Facilitate Free-Flowing and Efficient Communication

You require a separate communication flow to understand and clarify all issues that may pop up. And while there’s no doubt Jira is incredibly powerful, it’s not the most intuitive.

You have to be prepared to do a lot of flipping between tools to gather all information when using Jira for bug reporting. You can’t just send an issue to the devs without defining and clarifying the problem. If you do, you’ll most definitely get a message back where they ask you to elaborate and give more information concerning the issue.

You see, developers need a baseline of information to resolve bugs in a timely fashion. The more complicated a bug is, the more additional information they need.

Therefore, if you want to reduce time wastage and avoid frustrating developers, you have to make sure your bug reporting is concise and complete. Typically, devs require the following information:

Title
Description or summary of the issue
Reporter’s information
Source URL
Console logs
Environment: browser, operating system, zoom level, and screen size
Visual proof

Even the most perfect issues can require additional information or details. Keeping this in mind, we highly recommend pre-planning the course of action and how the communication will take place to avoid having anyone sit on questions.

Step 5 — Resolve Bugs and Notify Reporters

Nobody likes to deal with impatient follow-up emails or calls. Not only does this kill productivity, but it also creates frustration in both the involved parties.

You or your developers should make a point to notify the reporter after closing a Jira issue using the same channel of communication as used before. Essentially, any channel that reduces possible miscommunication and delivers all information intact is a win.

Email is understandably the most popular communication channel, with good reason.

People are always checking their emails, so you can be sure they’ll read the notification. More so, if they’ve used the same medium to submit their issues. If you want to notify reporters via email, you need to attach the following:

The issue number
The title
A screenshot of the issue before it was resolved (there’s a common tendency to forget the details of the reported bug, which is why the screenshot can serve as a good reminder)

This will be particularly helpful if your reporters are non-Jira users and don’t have access to your projects.

Again, you can use a bug reporting tool with automated status sync if email sounds too tedious. Whenever you close an issue in Jira, it’ll automatically close in the tool as well. All your reporters will receive notifications through automated email or system portal updates.

Common Problems When Setting up a Bug Tracking System Using Jira

Let’s take a look at some of the most common problems you may face when setting up a bug tracking system using Jira.

Problem #1: Information Gathering

Developers need detailed information about a bug to solve it effectively and swiftly. The problem here is that since Jira isn’t the most intuitive tool, you have to take matters into your own hands.

You have to go through all the tools, scan processes, and make a list of all the problems before feeding them into Jira, which makes it very time-consuming. As discussed above, you‘ll have to take screenshots, annotate them, and type out elaborate explanations so the developer understands the problem and can start fixing it.

Problem #2: Confusing User Interface

You can have reporters that know how to use Jira as well as those who don’t. However, irrespective of their expertise, people do find Jira‘s user interface cluttered, and its filtering tools slightly more complex to use.

The main reason for this is that some parts of the software still use an older version of their graphical interface, while other parts employ the newer version. So it’s necessary for everyone to get a hang of how Jira works before they start reporting and tracking bugs.

Problem #3: Prioritization of Reported Bugs and Issues

Bugs and issues must be resolved depending on their severity. Ideally, everyone should be on the same page with regard to prioritizing bugs. But since every individual has their own way of thinking, this is a job easier said than done.

Ensuring everyone is on the same page when setting up a workflow can be difficult. You can force users to have the same viewpoint when prioritizing issues. This, in turn, can create problems and misunderstandings between team members.