JIRA Bug Tracking Tool Tutorial: How To Use JIRA As A Ticketing Tool

JIRA Bug Tracking: Defect Life Cycle in JIRA

Jira Download and Installation was explained in detail in our previous tutorial. The test teams are always apprehensive about picking up JIRA for Defect Management.

The doubt is warranted. It 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 or discomfort, the test teams have no choice but to use the JIRA bug tracking tool in most companies. Our Complete guide on JIRA training will give you an excellent knowledge of the tool.

=> Click Here For Complete JIRA Tutorials Series

 

Why? 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 with purchasing too many licenses.

 

So, if a Development team is using Atlassian JIRA bug tracking tool to track its requirements, enhancements, tasks or user stories, then the test team, most probably, has 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.

This is the tutorial that will demonstrate to you, via screenshots and everything, JIRA’s applicability to bug tracking.

The 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 recorded for every issue:

• Defect ID
• Defect title
• Defect description (steps to reproduce)
• Environment information
• Screenshot(attachment)
• Severity
• 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
• Status

These two fields are auto-created by JIRA. All issues will have a unique ID assigned to them by JIRA. Status of all issues is “To-Do” or “New” in JIRA by default on creating a bug.

Therefore, all the common facilities for defect reporting are available in JIRA too. In fact, more options such as labels, linking defects, estimating efforts can be used.

#3) Defect Life Cycle:

All bug life cycle statuses as in Bugzilla (or any other popular bug tracker) can be accomplished here too:

This will need a little bit of customizing by your JIRA admin, but it is easy to do. For those, do not want to bother with the 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 fields 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 in the issue details page as 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 at once. 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 defect data, especially useful if you want to share your defect 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:

If we have to review JIRA’s analytics in one word, it’s fantastic.

Advanced/Power users of JIRA can also create advanced search filters to generate deeper insights.

For example, if 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 to 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. When used right, 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 could explore a few other cool features of JIRA (that might not directly be related to bug tracking) that might make it your go-to choice.

• Customizable Dashboards
• Test Management Add-ons
• Vote and Watching an issue
• Time tracking
• Agile Project and Scrum boards
• Confluence/Documentation support integration, etc.

---

Creating A Jira Issue And Various Fields

Jira Issues: Different Types of Jira Issues

Jira gives you very simple ways to create/log issues.

It not just allows us to file bugs but also enables us in other kinds of ‘tickets’ or ‘requests’. It is more of a general request management application.

This tutorial will explain more on Issue types in Jira, creating an issue, different fields on ‘Create Issue’ page and their details in simple terms with pictorial representation for your easy understanding.

Jira Issues

Different organizations may have different types of issues depending upon their suitability/ needs. A Jira administrator can efficiently customize this field.

Issues can be of different types and given below are the Description/meaning of Issue types:

1. Bug: This is any defect or deviation that is found in the application.
2. Enhancement request: It 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.
3. Task: This is more of a configuration or analysis issue. For Example, setting up proper configurations can be a task.
4. 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.
5. 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.
6. Financial Object: Often project/product management uses this type of issue to track their finances.
7. Story: Entire user story about a feature could be a type of issue.
8. 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 a user has logged into Jira and the desired project.

Step 1:

Click on ‘+’ (‘Create’) toolbar button.

This will display a screen/page as shown in the below image:

On this page, select 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:

Step 2:

Enter the mandatory details and other data as much as possible on the ‘Create issue’ page.

Step 3:

Click on the ‘Create’ button. This will generate a unique issue ID. ID will consist of 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 ‘Create issue’ Page

(Create issue page images are divided into 3 parts for better readability).

Note: Jira administrator and/or developer can add/remove the custom fields depending upon the organization needs.

#1) Summary:

This is also more often called as 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 helps the bug review board and/or product owners to prioritize and assign the issue without looking deep into it.

#2) Component/s:

Name(s) of the module or area of the application where the defect is detected in case of the ‘Bug’ issue type.

It could be the area where the changes are required in case of a CR. This is usually a drop-down consisting of different modules/components which exist in the application. Project person has to get it populated from the administrator.

#3) Description:

Typically should contain the steps to reproduce the issue if the issue type is a bug.

In case of an enhancement request, it should detail about the new requirement which is typically called as a story in the 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.

#5) Priority:

This field indicates the criticality of the issue.

It can be a show stopper, meaning application testing cannot go ahead in a testing phase. The crash of an application is an ideal Example of a ‘Show Stopper’ (critical) issue.

Bug review board and the 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.

#6) Labels:

This field is entered with the texts which will help in categorizing issues.

#7) Environment:

This is an optional field and the test environment is specified here.

#8) Attachment:

Supporting images for the issue being created. The user can simply drag and drop images or copy and paste.

#9) Affects Version/s:

For a ‘bug’ type of issue, 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.

#11) Assignee:

It is the 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 master. Again who assigns the issue may vary from one organization to another.

=> Clicking on ‘Assign to me’ (located at the right corner of ‘Assignee’ field) will assign the issue to the logged in user.

#12) Epic Link:

Choose the relevant link of the epic.

#13) Sprint:

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.

#14) Team:

There can be different teams, in an Agile environment. The issue is 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 consist of the required testing efforts also. 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.

#16) Reporter:

This filed is auto-populated by 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.

This field values may vary from organization to organization. If Jira is used to create issues only internally in the organization and not by end customers, then this field may not exist at all.

(ii) Reproducible:

Is the defect reproducible? This field will not be available for any issue type other than a bug.

(iii) Customer:

This field names the end customer who has filed the issue. In 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 with JIRA Issues – How to log defect 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 form 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 in 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 to.

Issue type:  This field displays all the 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 setting set by the administrator):

The items Bug, new feature, task, improvement are exactly what their names imply. Epic and story are more relevant to the agile projects. A Story is a requirement in Agile that needs to be tracked from the start to finish. An 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 right, this field can be very successful at transmitting a lot of critical information. Some aspects to note here:

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 is 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 an appropriate option for your bug.

Component: This list will display the components of the Project. Choose appropriately.

Affected Version and Fix 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 that, you can choose the affected version as the current version and the fix 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 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 in a 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 it 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 the 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 though precise, it is not complete. When it comes to this field, 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 empty for the states New Jersey and Utah also.

So, to repeat, provide the exact steps, the exact data and any other information you think that 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 remember the changes for your subsequent issues too.

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.

=> Visit Here For Complete JIRA Tutorials Series

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?

PREV Tutorial | NEXT Tutorial