Let us move on to creating an issue assuming the user logged in is not an admin and our test project “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 to create them there in 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’ dialog 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 that 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 in this list (this list might differ depending on 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 agile projects. 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 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 option 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 more apt summary/title would be “The option to clear the contents on 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 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 detail 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, it the City field 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 “City” drop down – note the city names
The above description though precise, it not complete. When it comes to this field, err on the side of providing too much information but not too little.
If the following steps are added to the description, this will make more sense.
6) Choose the state as “California” and click on “City” drop down – all the states are displayed and the user can select a city as needed.
7) Choose the state as “Louisiana” and click on “City” drop down – the list is empty.
8) The cities are empty for states New Jersey and Utah also.
So, to repeat, provide the exact steps, the exact data and any other information you think 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” dialog.
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 view the created issue, by clicking on the link that appears in the above message.
Additional details about the create issue page:
1) There is a configure fields option present 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 dialog. 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” dialog open with Project, Issue type and other fields except summary auto selected as per the previous issues created.
This brings us to the end of the topic – “Creating an issue in JIRA”.