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. 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.

=> Click Here For Complete JIRA Tutorials Series

JIRA for Bug Tracking

JIRA Bug Tracking Tool

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”.

create an issue

#2) Defect reporting needs the following information to be recorded for every issue:

  • Defect ID
  • Defect title
  • Defect description (steps to reproduce)
  • Environmental 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:

create a defect

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 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:

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

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:

Jira Comments

#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.

Linking the defect

The resulting links will appear on the issue details page below:

issue details page

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.

CSV file

#7) Defects can be exported into Word, XML, and printable formats

Defects exported

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:

Comprehensive Issue Reports

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:

JQL query

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.

Creating a JIRA issue

Jira Issues

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:

  1. Bug: This is any defect or deviation found in the application.
  2. 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.
  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 Objects: Often project/product management uses this type of issue to track their finances.
  7. Story: Entire user stories about a feature that 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 the 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 image below:

create issue button

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:

create Issue in JIRA

create issue -2

Step 2)

Enter as many mandatory details and other data as possible on the “Create issue” page.

Step 3)

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.

#1) Summary:

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.

#2) Component/s:

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.

#3) Description:

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.

#5) Priority:

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.

#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 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.

#11) Assignee:

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.

#13) Sprint:

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.

#14) Team:

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.

#16) Reporter:

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.

(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. 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.

Issues handled in JIRA

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:

Creating a JIRA issue 1

Click on the “Create Issue” button. Alternately, when you type “c” while on the JIRA page, the following “Create Issue” dialogue opens up.

Creating issues in JIRA 2

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.

Creating issues in JIRA 3

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):

Creating issues in JIRA 4

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.

Creating issues in JIRA 5

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:

Creating issues in JIRA 6

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.

Creating issues in JIRA 7

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:

Creating issues in JIRA 8

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.

Creating issues in JIRA 9

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”

Creating issues in JIRA 10

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 To 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

Recommended Reading

13 thoughts on “JIRA Bug Tracking Tool Tutorial: How to Use JIRA as a Ticketing Tool”

  1. Hi,
    I am a qa user of jira. Defect management is OK. I agree. However, I am concerned about test management. How can we manage test cases, test result, test execution. Let me know. Thanks

    • There is a plugin called Zypher which is comparable for JIRA. By integrating this tool with JIRA, you can maintain test cases (step wise, if you prefer) and track results..

    • Hi nayan,
      This cannot be solely done by jira but you can use add ons like test rail which is complete test case management add on for jira.
      Other than this you can use checklist add on as well which very simple and free as well

  2. Hi,

    Nice article. In addition to this, Use Chrome Extension “Capture For Jira”. By this, If You found any issue on page, Just click on this icon, It will take screenshot of that page.
    You can add multiple screenshots & also put focus area with text on captured screen.
    By this extension, You can create template by pre-selecting all jira fields. Just use the template, all fields get filled, You just need to add sumary & description. This extension is very easy to use & saves lot of time.
    Happy Testing 🙂

  3. I am a QA Manager and I have been using Jira for 3 years to manage my Test Case Repository. You can customize Jira to fit your needs. For example; We use a different set of Status’ for Test Cases:
    TC – Passed, TC – Failed, TC – Awaiting Review, TC – Ready to Run. Also, the required fields are customizable as well. Jira is an awesome tool. I have a Test Board that I use to manage test suites for multiple clients and multiple builds in a day. I have a repository of 2900 plus test cases all managed through Jira.

    • Hi Joanne,
      How do you Manage your Test Case Repository in Jira?
      Looks Like you have separate tickets for Test Case – Separate Statuses – How do you do this?
      How do you manage the Test Suits in Jira?
      Interested to find out more.

  4. Tell me about automation testing.

  5. How about if we buy JIRA for Defect Tracking and Zypher for Test Management. Can someone give me some pricing idea for both of these licenses, Please.

  6. Hi…I want to Jira bug tool..

  7. Hi, My company has started using jira a few days ago. Can anyone tell me how to manage sprints in Jira??

  8. It’s called Zephyr

  9. Very interesting , good job and thanks for sharing such a good information about top SOFTWARE. This is a so useful post ever.

  10. JIRA bug tracking seems like a write-only system. We have been using JIRA for agile workflow, and we have processed numerous bugs through JIRA, but once “done” they disappear. I can’t find any way to get a list of past bugs that we have fixed or decided not to fix. Without this it is useless as a bug-tracking tool.


Leave a Comment