Jira Bug tracking tool tutorial : Atlassian Documentation

Jira Bug tracking tool tutorial : Atlassian Documentation

Before jumping to this tutorial : Go through our another article on Writing Efficient Test Cases

Jira : The basic use of jira tool is to track the issue and to track bugs related to software and mobile application. and  user for Project management. Jira is complete solution for project management provided by atlassianConfluence is the one place for all the team work, Create , Organize and discuss work with your team.

Jira work flow: Configuring Workflow

Jira provides a default workflow which looks like below

  1. JIRAOpen.
  2. Assign.
  3. Resolved.
  4. Reopen.
  5. Closed.
  1. Open: Test Engineer test the application according to the requirement, while testing if test engineer find any issues, test engineer can raise the issue and change the status as open.
  2. Assign: Test Engineer assign a issue to the developer present in the company to fix the issue and change the status as Assign.
  3. Resolved: Developer can check the issue and fix the issue occurred in the application or software and change the status as resolved.
  4. Reopen: Test Engineer retest the application to check whether the issue is really fixed by developer or not and if issue is not fixed test engineer can change the status as reopen.
  5. Closed: Test Engineer retest the software or application to check the issue was fixed by developer or not and if issue was fixed change the status as closed.

How to report bug in Jira tool

  1. Project: In project drop down select a project which we have to test.
  2. Issue type:


  • Task
  • Bug
  • Epic
  • Story
  • Task: Task that needs to be done.
  • Bug: A problem which impairs or prevents the functions of the product.
  • Epic: An Epic captures a large body of work. It is essentially a larger user story that can be broken down into a number of smaller stories.
  • Story: Story is user requirement.


  1. Summary: In summary field enter the brief description about the issue or bug.
  2. Reporter: Reporter is a test engineer or a person who is analyzing, finding and reporting a bug or issue.
  3. Components: Components are sub-sections of a project. They are used to group issues within a project into smaller parts. Application contains several components like for example take gmail application,which contain login component and compose component. if user mention particular component where the issue is occurred,its easy to find issue.
  4. Description: Description contains steps to reproduce an issue or bug. And steps of scenario.

 Example: steps to validate login button.

  1. Enter Username.
  2. Enter Password.
  3. Click on Login button
  4. Fix/Versions: 
  1. Priority levels in Jira:


  • Highest: This problem will block progress.
  • High: Serious problem that could block progress.
  • Medium: Has the potential to affect progress.
  • Low: Minor problem or easily worked around.
  • Lowest: Trivial problem with little or no impact on progress.


  1. Labels:
  2. Attachments:  An attachment is any file that is included with your page. Examples of attachments are screenshots, photographs, other images, Word documents, presentations, PDF documents.
  3. Linked Issues:
  4. Issue: Select issue type, issue is either functional or integration or UI issue (User Interface).
  5. Assignee: Assignee is a developer or person who is fixing a issue.
  6. Epic Link: 
  7. Sprint: Time taken to complete a project is called as sprint.

Posted By

Vinayak Mudiyappanavar,

Trainee Test Engineer

Writing Efficient Test Case: A Test Case Template Example

A Test Case Template Example

Test case template: A template is a structural document and a test case template contains all information required for a test case. Every test engineer will write test cases in test case template, there is nothing called standard test case template. It may vary from company to company and project to project.

It mainly contains the following XLS sheets

  1. HLS Revision History – For High Level Scenario
    HLS- Test Scenario Revision
     HLS- Test Scenario Revision
  2. HLS Scenarios
    HLS-High Level Test Scenario
      HLS-High Level Test Scenario
  3. HLS Review Comments
    HLS Review_Comments_Test_Case
     HLS Review_Comments_Test_Case
  4. LLS
    HLS-High Level Test Scenario_test_case
    HLS-High Level Test Scenario_test_case


Test case parameters


Test case name:It is a unique name written by test engineer.For every individual test engineer individual  test case name should be written in the below mentioned format.


Release name: It is mandatory to mention release name because it helps to identify in which build the issue has been raised.

Requirement number: When BA(Business Analyst) write the requirement number for every individual requirement and  unique number will be given to each requirement, so test engineer should copy the requirement number and should write the test case template.

Module name: When BA(Business Analyst) write the requirement, he will also write list of all the module names so test engineer should copy the module name from the requirement and should write the test cases.

Precondition: It is the settings or actions that should be done before executing test cases or step no 1.

Test dataIt is a data created by test engineer before executing test case or step no 1.

       Example for test data : It is required to create an user account before testing file upload feature.

Test data can be created manually or we can also create test data by executing automation scripts.

Post condition:It is an expected result that we get from the application or when we give the input to the application what ever output we get from the application that is called as post condition.

We mainly use post data when one of the test case is depending on the output of previous test case.

Severity:Test engineer should give severity for each and every individual test cases based on complexity of the feature and importance of feature and importance of feature to the customer business, based on severity test engineer will decide which test cases should be executed first and which test cases executed next.

3 types of severity

1)  Critical

2)  Major

3)  Minor

Test case type: Test engineer should mention which type of testing he is writing in the test case type.

Functional testing

Integration testing

System testing

Smoke testing

Brief description:This field describe the complete information about  the test case

Test execution hours:Test engineer should mention how much time he has taken to write and execute the test case ,the value for this field should be enter once of after test execution.


Step no:This field is mainly use to identify each and every step uniquely.

Action or description:It consists of all the navigation steps.

Input:This field consist of the values entered by test engineer while testing the application (URL,Username,password and all  +ve  and  -ve value you entered for every field)

Expected Result:Test engineer will write Expected result by looking in to the requirement the value for this field is entered before test execution.

Actual Result:Test engineer will write actual result while executing the test cases execution. Test engineer will get the actual result from the application.

Status:Test engineer will enter the status of test case as pass or fail after test execution. if expected result is not matching with actual result than test case status  is fail else it is pass.

Comments:If the test case is fail then test engineer should enter the reason in the comments stating why the test case is failed.


Author:Test engineer one who write the test case is called as author.

Reviewer or reviewed by:Test engineer one who reviews the test case which is written by other test engineer is called as reviewer.

Approved by:Test engineer one who approves the test case is called as approved by or approver.

Approval date:The date on which test case is approved is called date.

Download Test Case Template XLS file

Important : Learn  to use JIRA bug tracking tool

Posted By

Vinayak Mudiyappanavar,

Trainee Test Engineer


What are test cases, test scenario and Advantages of writing test cases

What is test case:

Test case is a document which gives all possible scenarios for one particular requirement. Ideally a test case document contains set of test data like preconditions,post conditions, actual results and expected results.

Test Scenario : Is a any functionality or a test condition or a test possibility.

Software Testing Life cycle:

Software Testing Life Cycle

Why to write test case: 

Test Coverage : Test coverage is a measure of testing and to have better test coverage it is required to write all the tested cases for identified scenario. Ideally the following process will be in action.

  1. Customer will give requirement to developer.
  2. Test engineer has to spend enough time to understand the requirement 
  3. Test engineer has to identify all possible scenarios
  4. Test engineer has to write test cases for all identified scenarios.

What are benefits of writing test cases:

  1. Better Consistency :  When test cases are written for a test execution, the test engineer work will be organised better and simplified. Let us consider a scenario as an example.

When a release1.0 is being tested using existing test cases, the same test cases can be quickly executed for the next release 1.0.1, having test cases helps to identify issues which impacting the old release, this way we can achieve better consistency in test execution.

2. Avoid training : To avoid training every new test engineer on the product or requirement. Consider the following situation.

  • Test Engineer write test cases.
  • Test engineer quits the job
  • New test engineer joins

It takes lot of effort to explain every module and it takes lot of time for new tester to understand the complete requirement.

  • But if we write test cases in the beginning, then the newly joined test engineer can test application by looking in to test cases on his own.
  • Here its not necessary to train him on requirement because, if he execute test cases for couple of release on test cycles he can understand the product.

3. No dependency : To depend on process rather than person. Every company will set their own process

EX: when we get the requirement test engineer should do follow the process.

Understand requirement

identify all scenarios and document.

Prepare a test cases for each scenarios and document.

This process of documenting each and everything will remove the dependency on a person

4. Writing test cases will keep track of all the steps for a particular scenario, this is very important because complicated steps to test a scenario might be difficult to remember always.

    Let us consider an example :

          Assume that an UI distortion issue will be produced by following steps in a particular scenario

Step1 : Login into Chrome browser ( Hard to remember the platform some times, issue is only in Chrome)

Step 2: Navigate to Home page 

Step 3: Select profile from menu in the header

Step 4: Edit First name and Last Name details by giving big string

Step 5: Go back to Home page

Step 6: Navigate to Events page ( only navigating to events page will reproduce the issue)

Step 7: Go back to Home page, the header will shift 100px down leaving black pack at the top

Assuming these steps were not recorded in test cases, when build release 1.0 is given, it is hard to reproduce the same issue again quickly. 

If test cases have written, test engineer can easily follow the steps to reproduce and test the issue.

5. Test cases will ensure that complete functional and non functional testing will be done and hence test cases will give complete list of all scenarios to meet the software product quality expectations.

6. The main objective of test case is to exercise every flow in application.

7. To ensure that it satisfies the BRS that is Business Requirement Specification and SRS that is System Requirement Specifications.

8. Test cases will ensure that every functionality working as expected in every possible scenario.

9. Test cases will ensure that all the requirements have been met as per the customer requirement document.

Check an example for Test Case Template


Posted By

Vinayak Mudiyappanavar,

Trainee Test Engineer