Fundamentals of a Bug Tracking Tool (JIRA)

Team lead, Razvan Radutac breaks down the use of Jira in QA

By Razvan Radutac, QA Team Lead, Cognizant Softvision

Where to start? Oh, yeah, I know. Let’s start with the responsibilities of a Quality Assurance Engineer in software development projects. Simply put, we’re here to test that everything works as it should and report bugs when something doesn’t. Some of these bugs need to be squashed as soon as possible (P0-P1’s), some can be lived with for a little while (P2-P3’s), while some are released back to their original environment (P4 or Won’t Fix’es).

But what did you do there in the parentheses, Razvan? Weeeell, I grouped the bugs by Priority and Resolution. While I’m at it, I can tell you that we’re able to do all sorts of things to them: label, group, decide which one to squash first, when to squash it, who should squash it, who should verify that it is squashed, etc… segueing nicely into why this article was written in the first place: suggestions on how to use a bug tracking tool (JIRA).

Now that I’m done talking to myself (at least for the next 10 or so minutes while you read this article) let’s dive in. Let’s!

Why use a bug tracking tool?

In any software project, you need to have a system that enables you to find -> create -> report -> manage -> track the bugs / failures / defects / faults that the software has. This can be any tool from a white board, to a spreadsheet, to a software tool built specifically for this purpose.

White boards and spreadsheets work just as well at the beginning of a small team’s project, but as the project evolves, the number of test cycles and people involved increases, so the use of boards and spreadsheets become harder and harder to maintain and use in real time. And, with everything else going on in the project, the team could spend their time on much more important things, making Jira or another “debugger” an essential tool to have in your tool kit.

Some advantages of using a dedicated bug tracking tool are:

• An easy way to understand bug (defect) density on any given area of your system
• An easy way to control the bug logging standards
• An easy way to track the bug communication throughout its life cycle
• An easy way to prevent duplicates and already discussed improvements

Examples of tools on the market and why JIRA?

Hopefully by this point in the article I have your buy-in into using a bug tracking tool by now, so the next, natural step is selecting one. There are so many good and promising tools out there and descriptions and suggestions can be found across the wide web, but through personal research I stumbled upon five that caught my attention and are worthy of a test-drive: Backlog, Monday, Bugzilla, Mantis and JIRA. I won’t go into details for all, but each one has all the basic functionalities one would need, but it comes down to project’s budget, professional experience and personal preferences when selecting one.

Throughout my 8+ years of QA experience I resonated most with that last one from the above list, so without further ado, Let’s talk JIRA.

JIRA is a tool developed by the Australian Company, Atlassian Company and to quote their creators, it is a system that was originally “developed for bug and issue tracker, but evolved into a powerful work management tool for all kinds of use cases, from requirements and test case management to agile software development.”

Looking at it’s description users are able to realize that JIRA can do so much more than bug tracking, helping to create and track new requirements in features and improvements, organize them on Agile Sprints/Kanban boards, create and maintain test cases and much more. This article focuses on what JIRA can do to the Tickets (Issues) and everything that revolves around them.

Fun Fact:

According to Atlassian, 83% of Fortune 500 companies use Jira for their project management needs.

Issue Types

The tool is extremely nimble and allows users to configure JIRA projects in almost any way desired, but to begin with, users should start by selecting which type of tickets each respective project needs. This is to be done by whoever sets up the project (JIRA Administrator) by selecting one of the default Issue Type Schemes: Default Issue Type Scheme OR Agile Issue Type Scheme. Regardless of which one chosen, users can always hit the edit button and add new issue types to it. The basic issue types needed are:

• Epic — a large body of work that can be broken down into a number of smaller stories. It can also be used to group bugs that are related to the same feature or same issue type (e.g. “Testing Data Config Issues”).
• New Feature/Story — can be part of an Epic or independent and represent the main hub for the Product team’s new requirements being implemented
• Improvement — different than the average Stories or Bugs, someone can always suggest how to improve your product
• Bug — self explanatory, to be used when something is wrong in any way with the product
• Task / Technical Task — sometimes the team may work on creating/updating documents, dashboards, presentations, etc. or doing some catch up on technical debts. This is the Issue type for that, if users want it tracked.
• Sub-Task — useful for splitting up a parent issue (Story) into a number of smaller tasks that can be assigned and tracked separately

Components / Issue Fields

An optional, but very important feature of JIRA if used properly, is the Components feature. Think of Components as sub-sections of a project that are used to group issues into smaller parts. These are independent of the issue type or EPIC allegiance. Some top of mind examples are: “Backend_Service1'’, ““Backend_Service2, “User Interface — Home Screen’’, “User Interface — LogIn Screen”.

Now that the types of issues have been defined in the project, the next step is to see what fields are relevant for each one. This is also an operation done by the JIRA Admin and they will have a wide range of fields to choose from. Fields can be of many types themselfs: text box, drop down selection, multi choice selection box, etc. and some of them can be set with a predefined value while others can have Autocomplete in their usage.

For example, for a Bug Issue Type you may want:

• Epic Link — to group all bugs under a given EPIC
• Summary — reading the summary should allow anyone to understand what the ticket is about without opening the ticket in full view
• Priority — we need to know how bad the issue is, right?
• Component — we can group the issue by whichever components we defined, as per previous description
• Assignee — who should be responsible for prioritizing the ticket. An engineering manager or a product owner can be set as default here
• Reporter — usually defaults to the current user, used to know who to ask for more information
• Story Points — useful if we use work estimation on tickets through story points. During a Sprint/time frame your team can work on x number of story points
• Description — here is where all informations and steps to reproduce the ticket are to be filled in
• Attachments — place where you can add screenshots, videos and logs
• Labels — you may want to label tickets in others ways than under EPICs, Components as well, e.g. “regression”, “dev-accept”
• Linked Issues — some tickets are related to others. There are a lot of options here, e.g. “discovered while testing”, “is blocked by”, “duplicates”, etc.
• CC To — who should be made aware of the issue?
• Sprints — if you are working with Sprints, this will allow you to define in which Sprint the issue will be investigated
• Environments — where did you discover the issue? Is it a Production issue? Or is it a testing environment specific defect?
• Region/Countries — is your product available in multiple regions/countries? Is this issue specific to one or all of them?

Of course, for other Issue Types, users may need different fields set up, as Due Date or Acceptance Criteria and more — the actual list could go on for a while.

Once that is completed, users need to determine what Fields are to be shown in each ticket during an operation. For example, this means that users can customize which fields are displayed on the Screen of creating a bug or on the Screen of viewing an already created EPIC. This can be done under the JIRA Screens configuration section, by the JIRA Admin.

Users can also throw predefined templates when creating an issue type, in the mix. Through this, users can say which fields are mandatory when a new ticket is created and can even predefine the description with suggestions of what needs to be filled in: “Steps to Reproduce”, “Actual Behaviour”, “Expected Behaviour”, “Notes”, etc..

Fun Fact:

The “etymology” for JIRA, traces the word back to the Japanese word “Gojira” which means “Godzilla”.

There’s a lot of information being thrown out, but hang in there, we’ve reached the halfway milestone. And how cool is Godzilla? Will it beat Kong? Should they even fight? Can’t they be friends? There I go, rambling again!

Workflow & Issues Attributes

All issue types must move through their lifecycle in a seemingly straightforward way. For that to happen users need to define a JIRA Workflow while understanding the Issues Attributes — Statues, Resolutions and Priorities.

If we are to keep it simple, and I recommend it that way, Statuses should be:

• Open — new open ticket, no work has been done, ready to be picked up by @workingdev.
• In Progress — work has been started on the ticket, ticket is assigned to @workingdev.
• In Review — the @workingdev has finished the work. Ticket is up for review and assigned to @reviewerdev
• Resolved / Merged — the ticket passed the review and has been merged to main branch
• Ready for QA — ticket is deployed to the testing environment. Ticket is ready for testing and assigned to @QA
• Waiting for Deployment — the ticket has passed the QA check. Ticket is ready to be deployed to Production
• Closed — Ticket was deployed to Production after a Production verification from QA
• Reopened — Ticket was Reopened because the work on it is not finished or needs additional changes

Looking at Resolutions, depending on the ticket’s status, users can have: Unresolved, Fixed, Won’t fix, Duplicate, Incomplete, Cannot reproduce, Done.

For Priorities, users can use one of two systems which need no explanation:

A. Blocker, P0, P1, P2, P3, P4

B. Blocker, Critical, Major, Minor, Trivial

After configuring all of the above, the final piece of the puzzle is to define the Transitions between Statuses and the JIRA Workflow is complete. To get the transitions name right, users should ask: How do I get a ticket from Status A into Status B? For example, to get it from Open to In Progress a simple “Start” transition will do. If users want to get it from Ready to QA to Waiting for Deployment a “QA Verified” transition is needed. Additionally, users can fill in the rest until something like this is reached(mind the arrows):

Boards

Having all of the above configured, the team can roll out their sleeves and start creating tickets. These new created tickets usually end up in the project’s Backlog and regardless of the Software Development methodology your team uses (Waterfall, FFD, Agile, Scrum) JIRA has your back and it provides you with three types of high-level Boards to customize:

• Next-gen board: a simplified board dedicated to teams who are new to agile. Has capability to turn on and off features like Backlog and Sprints.
• Scrum board: a board used by teams that plan their work in sprints. It includes a Backlog, a Sprint and a Reports tab.
• Kanban board: a board used by teams that focus on managing and constraining their work-in-progress. It includes the option of a Kanban backlog, a Kanban Board and a Reports tab.

Next, here are a few suggestions on how to configure the Boards in general. As an example, we’ll focus on a Scrum Board, because that is the most popular one out there. To do that, you’ll need to hit the “Configure” option in the top-right “Board” menu. From this screen, let’s only highlight the most important configuration options in my opinion, because this article is getting waaay too long, sorry ‘bout that.

In the General tab, users will find — general configuration options like Board Name, Board Administrators, Board Filters and others. The important one here is the Filter as that tells your board what tickets to contain (we’ll get to JIRA filtering in the next section).

Because users put in all that work in setting up the proper Statuses for tickets it is only normal to map those to the board and that can be achieved through the Columns tab. It is recommended here to keep it as simple as possible while including the needs of both Developers and QA. So if we had eight Statuses set up for tickets as per this article, users will need to have 1 to 1 columns for each, apart from “Open” and “Reopen” who can share the same To Do column. The rest should be: In Progress, In Review, Merged, Ready for QA, Waiting for Deployment and Closed.

Horizontally, JIRA thought of Swimlanes to group the tickets and there are several options, my preferences being Epics or Assignees. Users can even go with the No swimlanes option, but that will not help get a big picture on the Sprint’s workload and balance, especially if using Agile Stand-up meetings.

Finally, something that is very useful for boards are Quick Filters. Using them gets rid of the noise of a heavily packed board and highlights tickets grouped by whatever is preferred: Status, Assignee, etc..

Search & Filters + Dashboards

A very powerful feature of JIRA is the Search function which allows users to filter tickets based on specific criteria used as search input. The Basic mode of Search has a few predefined filters like Project, Type, Status, Assignee or Contains Text, but from the “More” button users can select almost any configuration option in JIRA like Epic Link, Priority or Reporter. If that isn’t enough, JIRA Search can switch to Advanced mode — where users use JQL queries syntaxes. This isn’t as scary as it sounds and after users understand the basic syntax, they are able to build on it — achieving complex searches.

Users can then save the JIRA search as Filters that can be private or visible to a specific user or group of users. These can be used in sharing results, configuring Boards or Quick Filters in Boards, for gathering metrics that will help improve projects or for creating JIRA Dashboards.

Think of Dashboards as a JIRA canvas where Gadgets from a 40+ options list can be added.. Most of these Gadgets are customizable on their own based on Filters so the possibilities are almost endless. What may come in handy here are: Filter of tickets created in the past X hours, Pie Chart with tickets statuses, Bar Chart with number of tickets created/resolved by certain users (a friendly competition doesn’t hurt).

Fun Fact:

At this current time, more than 70% of Cognizant Softvision projects are using JIRA as their Bug tracking tool.

Long read, short conclusion :)

Although this lengthy article contradicts me, trust me when I say that I barely scratched the surface of what JIRA can do. There is so much more to talk about, like JIRA integrations with other tools (e.g. Github, TestRail, Slack..) or JIRA Boards Reports or how to use JIRA to its full potential in a team that abides to Agile Scrum, etc..

Now imagine the discussions about other tools as well, it’s a LOT of information!. The goal of the article wasn’t to talk about the overwhelming amount of information though, it was to give readers a glimpse into the fundamentals of Bug tracking tools capabilities and I can only hope I managed to do that. Now it’s up to you: do your research, be bold towards making changes, talk with your team and improve your processes with a customized Bug tracking tool.