How To Build A Bug Tracking Report In Jira
Jira is an issue tracker tool from Atlassian, and it’s probably one of the most popular tools used for development project management (especially in agile environments) and bug tracking.
I have personally used it for many projects in the past years, with both Scrum and Kanban, and I find it very versatile.
Whether you are in charge of setting up the Jira workflows, or you just report defects using it, it doesn’t hurt to know its workings.
Jira is more than just a bug reporting tool, but in this article, we will focus more on tracking bugs than managing other types of issues.
Setting Up A New Project With Jira Software
If your project is new, the first thing you need to do is set up the Jira project. This is usually a job for the scrum master or the project manager, but if your QA role overlaps with one of these roles, this task might fall on your shoulders. It’s not complicated, and anyway, it should be a one time thing 😙
The sign-up is free, and for small projects with less than 10 users, you can use the free plan. If you have a larger team or if you need some advanced features, you can opt for one of the paid plans. I won’t get into the details, but you can check the Jira pricing page if you’re interested.
I’ve only created new projects to teach a class, but the process is quite intuitive. You’ll have the option to choose between different types of projects for software development:
Project Types
- A Kanban project allows you to create Kanban boards. You can use the classic template with the classic stages: To do, In Progress, and Done.
- Scrum - this template allows the team to manage their sprints and backlog when using the Scrum framework.
- Bug tracking - this is a simple template that allows issue tracking without using any agile methodology.
All projects can be customized to include the stages, transitions, and statuses the project needs.
For the purpose of this tutorial, I’ll use the Scrum project template so you can track stories and bugs in the same project, but don’t worry! Everything I show can be applied to other project types, too 😉
Related Read: AGILE VS DEVOPS: WHICH SHOULD YOU CHOOSE AND WHY
Issue Types
The default issue types provided by Jira are:
- Epic: in agile, an epic is a high-level collection of user stories and tasks.
- Bug: the type of issue we use in Jira to track found bugs and defects - we’ll focus on these in the rest of the article.
- Story: an agile user story (the description of the feature or functionality to be developed and tested).
- Task: usually used to track single issues or to-do items, for example researching a new test automation tool or updating the documentation.
- Subtask: this is an individual task assigned to a member of the team, and is a child issue to the “Task” issue mentioned above.
As I already mentioned, Jira is very versatile, and if you need to create your own issue type, you can do this at any time in the project.
For instance, I used to work on a project where we had a separate issue type for improvements. These were similar to user stories but were related mostly to enhancements for existing features in the application.
Or you can create an issue type for test cases, but we’ll get to that a bit later, where we cover available plugins and Jira integration tools.
Bug Tracking With Jira
Moving on to what interests us as testers—bug reporting and tracking. While Jira is a project management tool, not specifically a bug tracking tool, we QAs will probably be using it to do a lot of bug reporting 😁
Workflow And Bug Life Cycle
The default bug workflow (and all issues as a matter of fact) provided by Jira looks like this:
Which means that when an issue is opened, it is created with the To-do status. Then the issue, or bug, can be moved to any of the other statuses.
The test management team, the scrum master, or the project manager are usually the ones in charge of designing any custom workflows.
The workflow reflects the bug life cycle you want to have in the project. You can keep the default, simple one, or have it as complex as needed. I’ve honestly never worked on a project that didn’t have its own, customized statuses and transitions.
To personalize the life cycle, you’ll have to go to the project settings, select the bug issue type, and click on Edit workflow.
Here, you can add any new status and choose a specific transition for it, if necessary. Here’s an example:
In this specific case, when a new issue is created, it will have the To do status, from where they can only be moved to In progress. Then, before the bug can be tested, the code needs to be reviewed. Then the QA team can close it once it was validated in the In QA status. Of course, both the code review and the QA processes can fail, so the bug will be moved back to In progress.
Step By Step Workflow Creation
I’ll go through each step you need to do to go from the first workflow to the second one (or any custom workflow you find fitting for your project):
1. First, click on the Edit workflow button
2. To add a new status, click on one of the statuses—the statuses are separated into 3 categories: Todo, In progress, and Done, each one assigned a specific color. You can choose where your status best fits. I decided that In code review and In QA statuses mean that the issue is still in progress:
You can also have other To do statuses; for example an In review status, for when a new feature is opened and the product owner or business analyst still needs to add information about it, or the team has yet to refine it and decide on its complexity or estimate its story points.
3. Once you’ve added the new status, you can add a transition for it. The default will be that the status can be updated from any other status. If you don’t want specific transition rules, that’s fine. But a good workflow would allow bugs and issues to be moved in specific statuses only after they have already been through certain steps of the process.
In my example above, the QA team cannot start working on verifying the fix before the code was reviewed by another developer. To add this transition, simply click on the Transition button, and enter the details:
4. You can also delete any existing transitions and statuses if you want everything to be 100% customized.
5. A really cool feature is the automatic assignees. This is also done from the workflow, where you can set a default assigned user when a certain transition is performed on the issue.
For example, after a bug is Reviewed and moved to In QA, it’s automatically assigned to a certain tester, or the test manager who will decide who works on it. The same goes for In Progress and the development team. Newly created issues can be automatically assigned to a project manager or product owner, who will prioritize them in the backlog. It is highly customizable so you can personalize it however it works for your team.
Even if you are not in charge with setting up the issues life cycles, or if you don’t have access to the project settings, you can see the workflow for each Jira issue by expanding the status dropdown:
Viewing Issues In Jira
If the project is not a bug tracking project, you can view the current issues in the Kanban or the Scrum boards:
This is just to demonstrate, I doubt you’ll ever be lucky enough to have a sprint with just one user story and one bug 😅
Clicking on any issue will display its details. These contain, but are not limited to: an ID which is automatically created by Jira, a title, a description, the reporter, the assignee, any attachments or comments that were added by the team members.
The fields can also be customized, and I’ll demonstrate that in a bit, when we discuss what we should include in a good bug report.
Assignees
All Jira issues can be assigned to a specific team member. You can tag people in comments or in the description by using the @ character before the user’s name.
You’ll receive notifications when someone tags you and when an issue assigned to you, or reported by you, is updated. You can also “watch” issues. You’ll get a notification when watched issues are updated regardless of the reporter or the assignee.
Bug Reporting In Jira
An app with few bugs is what everyone strives for, but let’s be honest, testers are always happy when we find a good bug 😅
But a good bug is only as good as how we report it—a good bug report will make sure that it will get fixed with as little back-and-forth between the testing and development team as possible. Jira is a great bug tracker tool, and— did I already mention it? —allows a lot of flexibility.
To create a new issue, you just need to click the big Create button and a dialog will open. Here, select the Bug issue type:
A good bug report should include a good description (or Summary, in Jira). It should be short and concise, but providing enough details so it’s clear what the issue is about.
Then, in the description, add all the relevant details. You can structure them in a classic manner:
- Steps to reproduce
- Expected result
- Actual result
Then include any other details that are relevant to the defect. Screenshots or recordings are always a good idea, as well as logs or any specific files that were used during the execution.
Jira allows adding custom fields to issues. I personally like to separate the Severity from the Priority. So while Priority is a default field added by Jira, you can add a custom one for Severity.
Other custom fields worth adding can be related to the operating system—this could be a text field or a drop-down with predefined values, such as the Android and iOS versions used in testing, the browser, build number, or any other information that can be relevant when tracking bugs.
To add new fields, you can go to the project settings, select the Bug type, and choose which type of field you need:
Test Cases In Jira
The last thing I want to talk about are test cases. Jira software can be integrated with various test management tools, or you can add Atlassian extensions and add-ons, such as Zephyr (which used to be my personal favorite) or Xray. When you create a bug as a result of a failed test case, the test can be linked to the bug, which can be very helpful in managing bugs, tests, and test case execution.
The Takeaway
Jira can be a great defect tracking tool and can improve the development process because it allows a lot of customization. When it comes to bugs, it’s really useful because you can customize the workflow to fit the life cycle you want to have in your project. You can link bugs to test cases and add custom fields in the way that makes the most sense to your specific project.
For more how-to guides like this, subscribe to The QA Lead newsletter.
Also Worth Checking Out: