JIRA Bug Tracking: Defect Life Cycle in JIRA
Jira Download and Installation was explained in detail in our previous tutorial. Test teams are always apprehensive about picking up JIRAs for Defect Management.
Doubts are warranted. This stems from the fact that though JIRA bug tracking tool is applicable to IT businesses, it is a generic ticketing system.
Even for IT projects, JIRA’s popularity with the Development teams makes testers and QA teams uncomfortable. Despite the comfort and discomfort, the test teams have no choice but to use the JIRA bug tracking tool in most companies. Our Complete guide to JIRA training will give you an excellent knowledge of the tool.
Simple logic – Companies do not want to invest in multiple tools. It just makes good business sense to maximize your tool utilization and not go crazy about purchasing too many licenses.
What You Will Learn:
- JIRA for Bug Tracking
- Best Features of JIRA Bug Tracking Tool
- #1) JIRA treats all work inside it as an Issue
- #2) Defect reporting needs the following information to be recorded for every issue:
- #3) Defect Life Cycle:
- #4) Comments and collaboration with the Dev Team
- #5) Linking the defect to a requirement to enable traceability
- #6) Defects can be imported from a CSV file
- #7) Defects can be exported into Word, XML, and printable formats
- #8) Comprehensive Issue Reports:
- Applicability of JIRA for Testing – An Alternative Dilemma
- Creating Jira Issues and Various Fields
- How Are Issues Handled in JIRA
JIRA for Bug Tracking
If the Development team is using the Atlassian JIRA bug tracking tool to track its requirements, enhancements, tasks and user stories, then the test team will most probably have to use it for bug tracking.
But, relax. JIRA’s Defect Management is just as good as any other tool. In fact, in some situations, it could even be better.
Here is the tutorial that will demonstrate to you, via screenshots and everything, JIRA’s applicability for bug tracking.
Best Features of JIRA Bug Tracking Tool
Here we go.
#1) JIRA treats all work inside it as an Issue
So, in JIRA, to create a defect would be to create an issue of the type “Bug”.
#2) Defect reporting needs the following information to be recorded for every issue:
- Defect ID
- Defect title
- Defect description (steps to reproduce)
- Environmental information
- Assign it to someone
- Status – All the statuses in the bug life cycle
All the options are available to be able to create a defect effectively.
Please note the fields highlighted in red below:
The two fields you are not seeing here are:
- Defect ID
These two fields are auto-created by JIRA. All issues will have a unique ID assigned to them in JIRA. Status of all issues is “To-Do” or “New” in JIRA by default on creating a bug.
Therefore, all common facilities for defect reporting are available in JIRA too. More options such as labels, linking defects, and estimating efforts can be used.
#3) Defect Life Cycle:
This will need a little bit of customizing by your JIRA admin, but it is easy to do. For those who do not want to bother with customization, you can’t go wrong with the default set up as well.
#4) Comments and collaboration with the Dev Team
Every issue, its updates, people assignment, comments received from the Dev team – everything is tracked in JIRA under the activity log.
This allows for better visibility and collaboration with the development teams:
#5) Linking the defect to a requirement to enable traceability
Link option in the JIRA issue field lets you link a particular issue to another one. Let’s say if Defect 2 is a duplicate of Defect 1 you can establish that relationship.
Similarly, if a defect is blocking a requirement or is related to a requirement – you can make this aspect visible in JIRA.
The resulting links will appear on the issue details page below:
The relationship types are self-explanatory and the usage of simple-common-everyday-language words (such as relates to, caused by, etc.) makes it super easy and intuitive for any JIRA user to use this right.
#6) Defects can be imported from a CSV file
This aids the bulk creation of issues in JIRA. Also, if your team is new and you don’t want them creating issues directly into the tool, you can have them report the defects in an excel sheet. Once they are reviewed and confirmed as valid, they can be imported all at once into the tool using this functionality.
Whichever way you use it, this is a big plus.
#7) Defects can be exported into Word, XML, and printable formats
This supports better portability of your defective data, and is especially useful if you want to share your defective data with people who are non-JIRA users.
#8) Comprehensive Issue Reports:
In addition, if you need reports, go to “Project – reports” and generate all sorts of reports as below:
It would be fantastic if we could review JIRA’s analytics in one word.
Advanced/Power users of JIRA can also create advanced search filters to generate deeper insights.
For example, if you want to look at all the defects assigned to you across multiple projects (BM and AB), you could use a JQL query like below:
So all in all, bug tracking/defect management in JIRA is very similar if not superior to dedicated bug trackers. Next time you have to work on it, don’t worry. You are in good hands.
Applicability of JIRA for Testing – An Alternative Dilemma
While this is one side of the coin, there is definitely another dimension to how people view the applicability of JIRA to QA or testing.
When you ask a group of QAs, “What is JIRA?”- Many will answer that JIRA is a defect tracking tool. Mind you, I have heard this from many senior QA professionals. This might be from the fact that, defect management/tracking is all they might have used JIRA for.
But there is a lot more to it. If used correctly, a core JIRA with its agile capabilities can be your one-stop-shop for high-level project management.
It can really support requirement tracking and progress, bug tracking, estimating, sprint tracking through SCRUM & KANBAN boards, reporting and collaborating.
You might be using a tool for one thing, but next time try and learn a few things around and about the tool that will help you understand and use it better.
So, as a next step, you can explore a few other cool features of JIRA (that might not be directly related to bug tracking) that might make it your go-to choice.
- Customizable Dashboards
- Test Management Add-ons
- Vote and Watch for an issue
- Time tracking
- Agile Projects and Scrum boards
- Confluence/Documentation support integration, etc.
Creating Jira Issues and Various Fields
Jira Issues: Different Types of Jira Issues
Jira gives you very simple ways to create/log issues.
It not only allows us to file bugs, but also enables us to file other kinds of tickets or requests. This is more of a general request management application.
This tutorial will explain more on Issue types in Jira, creating an issue, different fields on the “Create Issue” page and their details in simple terms with pictorial representation for your easy understanding.
Different organizations may have different types of issues depending upon their suitability/ needs. Jira administrators can efficiently customize this field.
Issues can be of different types and given below are the Description/meaning of Issue types:
- Bug: This is any defect or deviation found in the application.
- Enhancement Request: This is also known as a change request (CR). This type is used to depict any change in the existing functionality or altogether a new functionality.
- Task: This is more of a configuration or analysis issue. For example, setting up proper configurations can be a task.
- Question: Issue can be as simple as asking a question about how to use some functionality in the application. This type is more often used by the end customers.
- Epic: This is normally a huge issue which is ideally broken done into several small issues. It can take several sprints to complete the main epic issue in an agile environment.
- Financial Objects: Often project/product management uses this type of issue to track their finances.
- Story: Entire user stories about a feature that could be a type of issue.
- Test case: Issue can be a test case. This type of issue will be available once Jira is integrated with plug-ins like Zypher.
Creating an Issue
Assuming that the user has logged into Jira and the desired project.
Click on ‘+’ (‘Create’) toolbar button.
This will display a screen/page as shown in the image below:
On this page, select the project and issue/request type and then click on the ‘Next’ button.
This will open up the “Create issue” page as displayed in the following images:
Enter as many mandatory details and other data as possible on the “Create issue” page.
Click on the “Create” button. This will generate a unique issue ID. The ID will consist of a project identifier concatenated with numeric digits.
In the above Example, the project chosen is ‘TestProject’, hence the ID could be like ‘TESTPROJ1234’.
- Once the issue is created, thereafter it can be searched using the issue ID.
Description of Fields on the “Create issue” Page
(Create issue page images that are divided into 3 parts for better readability).
Note: Jira administrators and/or developers can add/remove custom fields depending upon the organization needs.
This is also more often called the title of the issue and is a very important field of a Jira issue.
The title should be as unique and precise as possible so that by looking at the title itself, the issue can be understood. This will help the bug review board and/or product owners to prioritize and assign the issue without looking deep into it.
Name(s) of the module or area of the application where the defect is detected in case of the issue type of the issue.
This could be an area where changes are required in case of a CR. This is usually a drop-down consisting of different modules/components which exist in the application. The project person has to get it populated by the administrator.
Typically, it should contain the steps to reproduce the issue if it is a bug.
In case of an enhancement request, it should detail the new requirement which is typically called as a story in agile terminology. Ideally, this field should be updated regularly during the course of the issue workflow.
#4) Fix Versions:
Name of the version in which the issue/enhancement request will be delivered. This value is typically filled by the product owner in co-ordination with the scrum master in an agile scrum environment.
This field indicates the criticality of the issue.
It could be a show stopper, meaning application testing cannot go ahead in the testing phase. The crash of an application is an ideal Example of a ‘Show Stopper’ (critical) issue.
Bug review boards and product owners have every right to change the priority of the issue. This field is a drop-down list with values like ‘Low’, ‘Medium’ (‘Major’), ‘Critical’, ‘Trivial’ etc.
This field is entered with the texts which will help in categorizing issues.
This is an optional field and the test environment is specified here.
Supporting images for the issue being created. The user can simply drag and drop images or copy and paste.
#9) Affects Version/s:
For bug types of issues, the product version should be entered here.
For Example 5.6, 5.7 etc.
#10) Linked Issues:
Other relevant issues can be linked to the new issue by choosing a proper value from this drop-down.
For instance, if the issue is introduced by a fix of some other issue, then the value to be chosen from the drop-down could be “Introduced By”. This field becomes extremely important if a new defect is triggered by some fix or enhancement.
=> Issue: After selecting a proper value in ‘Linked issues’, relevant issue ID is mentioned here.
Name of the user who will be working on the issue.
For instance, in the case of a bug, it will be the name of the developer who will fix the issue. This field is typically filled by the product owner or scrum owner. Again, those who assign the issue may vary from one organization to another.
=> Clicking on “Assign to me” (located in the right corner of the “Assignee” field) will assign the issue to the logged in user.
#12) Epic Link:
Choose the relevant link for the epic.
The name of the sprint is selected here, indicating when the issue will be worked upon. It could be a future sprint as decided by the product owner.
There can be different teams, in an Agile environment. This issue has been assigned to one of the teams. This assignment is usually done by the product owner or scrum master in coordination with the product owner.
#15) Estimate at the Start:
This field will indicate how much time effort will be required to resolve the issue.
More often called as ‘guesstimate’. This will also consist of the required testing efforts as well. It could be mentioned in hours/days/weeks or story points. In an agile environment during sprint planning, the entire team reaches a common guess.
This field is auto-populated in Jira with the name of the logged in user.
Note: We could have some other custom fields as below (which are not seen in the above images):
(i) Environment type:
Indicates if a defect is found in a test or production environment.
Field values may vary from organization to organization. If Jira is used to create issues only internally within the organization and not by end customers, then this field may not exist at all.
Is the defect reproducible? This field will not be available for any issue type other than a bug.
This field names the end customer who has filed the issue. For some organizations where Jira is used only for internal issue handling, this field might not exist.
Note: All the above-described fields belong to the “Field” tab on the “Create issue” page, which is usually the default tab. The page can be customized to have more tabs like ’Documentation’ etc. which we will be covering in our subsequent tutorials.
Jira gives us an effective way to manage the different types of issues easily and efficiently.
With lots of customization that are possible nowadays, Jira has become the most popular choice.
How Are Issues Handled in JIRA
Working on JIRA Issues – How to log defects in JIRA
Let’s move on to creating an issue, assuming that the user logged in is not an admin and our test project is “Test for STH” with components – Module 1 and Module 2, versions – version 1 and Version 2. Key – TFS is already created.
Creating a JIRA Issue
Issues from the crux of JIRA, so in order to create them there is an option right on the menu bar:
Click on the “Create Issue” button. Alternately, when you type “c” while on the JIRA page, the following “Create Issue” dialogue opens up.
All the fields on this page are self-explanatory. We will discuss the most important one below.
Project: Every issue belongs to a project. You can choose the same by clicking on the drop down and choosing the project to which you want this issue to belong.
Issue Type: This field displays all types of issues that can be created and tracked via JIRA. The following options are available on this list (this list might differ depending upon the settings set by the administrator):
Item Bugs, new features, tasks, and improvements are exactly what their names imply. Epic and stories are more relevant to agile projects. This story is a requirement in Agile that needs to be tracked from start to finish. Epic is a group of stories.
Choose the issue type as needed. I am going to go with “Bug”.
Summary: Give your bug a title here. When used correctly, this field can be very successful at transmitting a lot of critical information. Here are some aspects to note:
A bug/defect is essentially something that is not right. The right way to approach a bug title is to concisely define “what’s wrong”.
An example of a bad title/summary is “There should be an option to clear the contents on the screen”. When I read this my initial reaction is going to be – “Okay, there should be- but what’s the problem here? Is the option not present at all? Or are the options present and not clearing the content?”
It is also agreed that when I open this bug and look into it in detail, I am sure I will find the answer to this question.
However, the emphasis here is to use this “Summary” field in the most efficient manner. Therefore, a very apt summary/title would be “The option to clear the contents of the home login page does not clear the fields when clicked.”
In the limited space that this field provides, try to write your title in a way that communicates the exact issue without any ambiguity.
Priority: This field can take one of the following values.
Choose the appropriate option for your bug.
Component: This list will display the components of the Project. Choose appropriately.
Affected Version and Fixed version: These two fields will display the versions available for the project. It is not necessary that a certain issue that you encountered in a certain version gets fixed in the same one. In cases like this, you can choose the affected version as the current version and the fixed version as the next one.
Also, these fields can take multiple values. You can choose to set that a certain issue affects both version 1 and version 2 as shown below:
Assignee: You can type the name of the person to whom this issue should be handed over further. You can also assign an issue to yourself.
Description: This is an optional text field that aids you to enter as much information as you would like about your issue. In case of a bug, it is typical to use this field to give detailed information about the steps to reproduce the defect.
It is of utmost importance to give all the information.
“Say, there are two fields – dependent ones- State and City. When I choose State from the drop down, in the City field it should display the respective cities in the state I chose.
If I raised a bug as “The cities are empty for some states I selected”. The description field is the place for me to elaborate on this defect.
An example of an insufficient description is:
1) Enter the site
2) Click on the address page
3) Enter other details like name, street address, etc.
4) Click on the ” State” drop-down. Choose a state
5) Click on the “City” drop-down – note the city names
The above description is precise, it is not complete. When it comes to this field, it is on the side of providing too much information but not too little.
If the following steps are added to the description, then this will make more sense.
6) Choose the state as “California” and click on the “City” drop down – all the states will be displayed and the user can select a city as needed.
7) Choose the state as “Louisiana” and click on the “City” drop down – the list will be empty.
8) The cities are also empty for the states of New Jersey and Utah also.
So, to repeat, provide the exact steps, the exact data and any other information you think is necessary to complete this field.
Attachment: Any supporting document can be uploaded with an issue.
Once all the information is entered to your satisfaction, the issue can be created by clicking on the “Create” button at the end of the “Create Issue” dialogue.
The issue gets created and a message is displayed to the user with the issue ID:
Note: notice the issue ID; it is prefixed by the “Key” of the project. It is JIRA’s way of tracking/grouping the issues that belong to a certain project.
You can now view the created issue by clicking on the link that appears in the above message.
Additional Details About the Create Issue Page
1) There will be a configure fields option found on the top-right corner of the “Create Issue” page.
This option can be used to choose/alter the fields that you would like to see in your create issue dialogue. Once a choice is made, JIRA will also remember to make the changes for your subsequent issues.
2) At the bottom of the “Create Issue” page, there is a “create another”
When you choose this option and click “Create”- once, the current issue is created; JIRA keeps the
“Create Issue” dialogue open with Project, Issue type and other fields except summary auto selected as per the previous issues created.
With that, we conclude the topic “Creating an issue in JIRA”.
In the next Atlassian JIRA tutorial, we will learn about sub-tasks and how to use them for specific QA purposes.
Over to you
Now, it is time to hear from you. Have you faced any challenges using JIRA for bug tracking?
Do you think there is any weight to the resistance that test teams have in adapting JIRA for defect management?