Jira is a licensed software application to track the bugs as well as managing the projects. The software has been released by Atlassian(Software company who develops products for developers, project managers etc). These tutorials help us to get a basic understanding of JIRA.
All the fields and UI of the JIRA is configurable by the JIRA admin and as per the requirement of the organization. A sample of the JIRA UI is mentioned below:
Key features of JIRA
- Creating the different type of issues bugs, story, task, subtask, epic etc.
- Defining workflow, create projects etc like JIRA Admin.
- Project management using agile boards, dashboards and other techniques.
- Search issues, creating filters based on n number of fields.
- Generating reports, dashboards, agile boards etc to view the overall project health.
- Bulk changes based on the particular search. It means at the same time you can edit multiple issues for specific values.
In this tutorials, we would target below features of JIRA
- Overview of JIRA
- Creating the different type of issues
- Understand various fields/components while creating issues.
- Edit an existing issue
- Understand workflow of the issues.
Overview of JIRA
When an authorized user logged in to the JIRA, the initial view looks like exactly what appears in above image. There is a menu panel present at the top of the page, which contains below options.
Creating the different type of issues
All the bugs, epics, story, tasks can be created by using a single click on Create button present at the top of the page. When a user clicks on this button another pop-up appears as mentioned below:
Understand various fields/components while creating issues
Project: First of all we have to select Project name from the Project drop-down. All the projects created by the user, assigned to the user, will appear in this drop-down.
Issue Type: Next we have to select required issue type from the Issue Type drop-down. Mainly it contains below values:
- Bug: The difference between the agreed requirement and current functionality of application would be reported as a bug.
- Epic: An epic can be defined as a high-level project requirement, which may contain a number of modules. An epic contains multiple Stories/tasks depending upon the requirement size.
- Story: A story is a statement of an objective or a module as per user requirement. It also contains basic requirement and positive workflow and negative workflow of that particular module. It is like a user story which describes requirements/functionality of various users. A sample story will look like as mentioned below:
As a end-user : I should be able to login to the website using valid credentials.
So that : I could access the information and other features of the site.
Positive Workflow : User should be able to login with valid credentials.
URL : www.tempUrl.com
User ID: firstname.lastname@example.org
Alternate Workflow: All negative scenarios
- Valid UserID / Invalid Password
- Invalid UserID / Valid Password
- Invalid UserID / Invalid Password
- Blank UserID / Valid Password
- Valid UserID / Blank Password
- Task: A story can have multiple tasks and sub tasks based on the module complexity and team size. In simple, we can say that there would be different tasks for QA, Developer, UX designers, Content auditors, SMEs etc.
All the remaining fields on Create Issue pop-up will change according to the type of issue selected.
Priority: Depending on the project and business requirement we have to select Priority of an issue. The values of these fields are configurable. As per the organizational standards below are the category of Priority:
In some cases it can be as:
Severity: The value of severity shows the impact of the bug on the application which is being tested. All the possible values of this field are mentioned in below image.
Summary: Short description of an issue is called summary. A basic example is given below:
Summary of bug || Unable to click Save button.
Description: This field contains all the required information of the issue. For example, if we are logging a defect it should contain below information:
- Problem statement
- Expected Result
- Actual Result
- Special Note
- Affected configurations and more.
Step to Reproduce: After describing the issue summary and description, we have to provide steps to locate the issue. A simple example is given below:
- Navigate to URL: www.allinoneblogs.com
- Navigate to the Menu bar.
- Click on a link “Ask a Question”
- Fill all the required fields on the page.
Assignee: This field is also very important. It contains a list of all the users who have access to a specific project under which an issue is logged. Whenever a user types any letter it auto-populate the list of all users.
After submitting the create issue form the assignee would get an email notification regarding the same.
Attachments: At the end, we have to attach a screenshot, video or a reference document to give the actual picture of an issue or we can say proof of presence of issue.
Other than fields mentioned above there are few fields like:
- Build Version
- Link to another issue
All these fields would help a user to categorized the defects.
Create Button: When all the required fields get filled with correct information user has to click Create button in the pop-up box. On clicking the Create button issue get saved and a unique issue id gets generated on the screen. In the below screenshot unique issue id is “DMP-1234”.
Create Another checkbox: Have a look on the checkbox “Create Another” just left side of the Create button(pop-up box). If this checkbox gets selected, Create Issue pop-up box remains open on the screen. All the fields remain as it is except Summary and description. This would help us to create multiple issues faster.
Below is a presentation of a sample bug:
Configure Fields: While creating an issue we can configure input fields based on the project requirement. Suppose in below example we do not need Priority and Severity fields, in that case, we can deselect them from ‘Configure Fields’ panel.
Now the pop-up box will appear as mentioned below:
Note that only the optional fields would be configurable.
There are multiple ways to locate any existing issues or created issues on JIRA. Few of them are mentioned here which we would learn later:
- Search issue
- Creating Filters
- Using dashboards
- Recent Issues
Sometimes we forgot to remember the issue id generated recently by a user. In that case, we can use Issues option from the Menu bar.
On clicking more… option, user would redirect to the list of all the issues reported/logged by the current user.
- Selenium-1 || Understanding Selenium and Selenium WebDriver.
- Selenium-2 || Let’s learn Selenium IDE.
- Selenium-3 || First program using Selenium Web Driver.
- Selenium-4 || Handling multiple web browsers.
- Selenium-5 || Locating web elements using various type of Locators.
- Selenium-6 || XPath is the best way to locate web elements.
- Selenium-7 || Let’s learn to create complex XPath.
- Selenium-8 || Implementing Wait(s) in Selenium.
- Selenium-9 || Understanding WebDriver API.
- Selenium-10 || Taking Screenshots using Selenium
- iFrame || Multiple ways to handle iFrame html tag using selenium.
- iFrame || iFrame Handling within a web page.
- getWindowHandle() and getWindowHandles() methods.
- Properties File | Accessing properties file for user input or test data.
- Framework || Simple example of Key Driven Framework using excel sheet in Selenium(JAVA).
- TestNG – 16 || Access data from Excel sheet using DataProvider.
- Selenium Grid | Configuration and implementation with Example.
- Headless Testing | HtmlUnitDriver
- TestNG – 1 || Introduction and benefits of TestNG Framework.
- TestNG – 2 || Installation process and a sample program of TestNG.
- TestNG – 3 || Create and execute multiple Test Cases.
- TestNG – 4 || Let’s understand @Test Annotation and attributes.
- TestNG – 5 || Understand Assertion in TestNG.
- TestNG – 6 || Use of @BeforeMethod and @AfterMethod.
- TestNG – 7 || Use of @BeforeClass and @AfterClass.
- TestNG – 8 || Creation and execution of Test Suites.
- TestNG – 9 || Let’s move deep into the Test Suites.
- TestNG – 10 || Use @BeforeTest and @AfterTest Annotations.
- TestNG – 11 || Groups attribute with @Test Annotation.
- TestNG – 12 || Use of @BeforeGroups & @AfterGroups.
- TestNG – 13 || Use of @BeforeSuite & @AfterSuite.
- TestNG – 14 || DataProvider annotation & attribute.
- TestNG – 15 || DataProvider with parameters.
- TestNG – 16 || Access data from Excel sheet using DataProvider.
- TestNG – 17 || Passing multiple Parameters in testng xml.
- TestNG – 18 || Multiple Browser and Parallel Execution in TestNG.
- TestNG -19 || Concept of Parallel Execution.
- TestNG – 20 || Run TestNG Program using main() method.
Editing an existing issue
After creating any issue sometimes we need to edit the same. This can be done easily by clicking on Edit button present on the top of the issue. On clicking the Edit button issue will open in the same pop-up box as mentioned earlier with all the editable fields.
Multiple options for existing issues
As we can see in the above image, there are options present to perform multiple actions on an existing issue.
On clicking Comment button, an editable text field would appear on the screen. A user can put their comment and click Save.
Tagging users: While putting comment on any issue we can tag any user by using “@” symbol. Whenever user type @, a list of all project users populate on the screen and current user can choose any one.
There are two ways to change the assignee of a specific issue, we can
- click on Assign button on the menu bar or
- by using Assignee field present at the right side panel.
Other than above options there is a More drop-down, which contains few more options as per the requirements.
Understand workflow of the issues
The basic meaning of workflow is defining the process of building something from the initial stage to completion stage. ‘Workflow of issue’ means defining all the possible status for the next level. Below image shows ‘Workflow’, ‘Define Issue’, ‘Start Progress’ options. All these are the various status of issues on JIRA based on the user activity.
A user can be a tester, a developer or a manager. Also, workflow status would depend on the different issue type.
Here we tried to show how the status of an issue changed based on the user activity. Here, we will talk about issue type of a Bug.
Status v/s Resolution
As mentioned in the above diagram it is clear that Status is the position of an issue in a predefined workflow. This workflow has already been defined by the JIRA Admin or Project Manager as per requirement. Commonly used values of Status is Backlog, In-progress, Resolved, Closed.
On the other hand, Resolution is the solution of a problem. In simple words, what is the solution for a specific issue? There are multiple values which tend to be changed as per the Status of the issue. Few examples are Works as designed, Fixed, Won’t Fix, Can not reproduce, Done etc.