Working with JIRA Issues
JIRA – we are now in the midst of self-learning this tool. In the last JIRA tutorial, we talked about the underlying JIRA process – the Incident Management and a few high-level details of the tool itself.
Today we are going to move on to yet another interesting topic – How are the issues handled in JIRA?
Before we get into more details let us now reiterate what an issue is:
An issue is anything that you would track to completion. Some examples specific to QA can be – a document to be created, a document to be reviewed, a bug or an environmental issue.
Now 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 form the crux of JIRA, so in order to create them there is an option right on the menu bar:
Click on “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 for 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.
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.
Stay tuned and do let us know your comments, questions, and suggestions below.