Test case management in JIRA on ZERO budget

Keep getting the question regarding how do you do test management with JIRA without paying for any plugins. Trying to explain it in one sentence it would be something like this…

For a given JIRA project there is a set of master test cases from where executable tests/test-runs can be cloned based on version and executed against a system under test.

This post (in a beta) will describe a working flow that fits well with JIRA (assuming you have test cases in JIRA already) and what needs to be setup to get it working including some code for automating tedious manual tasks.

The sections are…

  • The master test case
  • Executable test case (i.e. master test case clone)
  • JIRA configuration and set-up
  • Test management, visibility and linkage of entities in JIRA
  • Automation of the bulk (cloning master test cases into executable copies)

The master test case

The master test case is the reference on which to base a test on at any current point in time. If a feature changes the master tests case gets updated accordingly, no magic in that. The master test case shall have a workflow that represents the purpose of a master test-case/reference, hints: written and approved. Exemplified in the JIRA setup/configuration section…

  • New – In progress
  • Pending approval – Written and waiting for approval from product owner
  • Approved – Active and up to date test case
  • Closed – obsoleted state / retired test case

Avoiding the never ending cloning of a test case

A usual problem with test case management in JIRA is that test cases are cloned, tweaked a bit, cloned again and again, which is a big mistake. The recommendation to solve this is that there can ONLY be ONE living test case in place for a given functionality. Something which is a common practice if looking at tools from major vendors.

To make this work there has to be something else in JIRA hence another ticket type or something that resembles an executable form of the ‘master’ test case.

The executable test case

Since the master test case act as a reference/template we have to derive and use its content in a another JIRA entity. The way this gets done (the manual way) is to clone a master test case, convert it to a new ticket type (executable test case) and make sure it is a sub task to the master test case. What is the benefit with that?

  1. it will have better suited workflow
  2. there will only be one test case to update
  3. there will be one historical instance for every time the executable test case was executed – which will be a clone of the master test case at the point when it was cloned

Creating the JIRA entities

The master test case type will most likely be present in your current JIRA setup but to be sure these are the configurations that needs to be made. Issue types If your JIRA installation does not include any Test Case issue types, add the ones needed. NOTE that the executable test case type has to be a Sub-Task Issue type.

  1. Master test case as a Standard Issue Type (Test Case)
  2. Executable test case as a Sub-Task Issue Type (Test Run)

Workflows The master test case type needs a simple approval workflow to make sure the product owner input is there.

Master test case workflow

The executable test case shall have states that tracks progress, and the final verdict.

Executable test case / test run workflow

The glue and workflow

Test case to story linkage is handled by linking issues together with the regular Link feature. The full entity relations will look like this.


Entities in JIRA, a story can be covered by multiple test cases, which in turn might have been executed multiple times.

The executable test case is a sub-task issue and shall have a master test case as its parent at all times and is at the same time a clone of a master test case at the point in time when it was created. The master test case is expected to change over time and the history will be visible in its sub-tasks, the executable test runs.

Using the sub-task concept will give a very good overview regarding execution history.


All executable tests / test runs are listed in the master test case with its execution version and verdict.

Use case – setting up a test plan

How would this work if I was to create a test plan including a set of test cases? Pick the test cases you want to get executed and for each of these test cases clone it and convert the clone into an executable test case that is a sub-task to the test case you wanted to include in your test plan. To make it easier to find the cloned executable tests give them all the same affects version. All set, a set of executable test case ready to be executed using its well fitted work flow.

Create a new JIRA Dashboard for your test plan/phase and check the progress of your executed test cases in (browser refresh) real-time.


Dashboard example

Smooth right? OR ??? Ugh, this will require a huge amount of manual work! Lets automate it…

Generating the test runs

Here comes the not so smooth part of JIRA. Cloning a master test case into an executable test case. Do not do this in manually, automate it.

This is based on that you have selected a set of test cases you want to include in your test plan. They are all listed if using a shared JIRA filter and the easiest way is to set the affects version of all these test case to the same (trust me it makes sense).

The second thing you need to know is what the JIRA type id is for the executable test case sub type. Inspect the element in your favourite browser (e.g. Firebug) and you will find out.

# This is Python code
import requests
import json
import base64

headers = {'Authorization':'Basic %s' % base64.b64encode("username" + ':' + "password"),

# 4 getting JIRA issues from a given filter
filter = "12345"
fields = "key"

# Details in a specific issue that we are interested in,
# add fields that you want to clone. For custom fields you will need
# to lookup its real name e.g. customfield_1234 which you can easily
# find out by inspecting the elements of your ticket in your browser.
fields_to_clone = [

# Get all master test case given an existing public JIRA filter
all_master_tests = requests.get(url="https://jira.mycompany.com/rest/api/2/search?jql=filter="+filter+"&fields="+fields, headers=headers)
issues = json.loads(all_master_tests.content)['issues']
for issue in issues:
    master_test = requests.get(url=issue['self']+"?fields="+",".join(fields_to_clone), headers=headers)
    fields = json.loads(master_test.content)['fields']
    fields['project'] = {'id':'10000'}
    fields['parent'] = {'id':issue['id']}
    fields['issuetype'] = {'id':'21'}

    # If you want assignee and versions to be set for the created test case add it here.
    #fields['versions'] = {'id':version}
    #fields['assignee'] = {'id':assignee}

    payload = {
    rs = requests.post(url="https://jira.mycompany.com/rest/api/2/issue", headers=headers, data=json.dumps(payload))
    if rs.status_code == 201:
        print "Test case created: "+rs.text

SonarQube quality gate feedback in a Slack channel

Well it is easy to agree on that Slack is awesome for team collaboration and with the hooks it has available it is rather easy to get some decent feedback into the team channels.

There is a Jenkins CI plugin available for Slack that pushes build notifications into a given channel. But that merely pushes what Jenkins provides, failed, unstable asf.. If you are working with SonarQube and want to know a bit more than if the build turned unstable, then there is an additional Jenkins plugin available for you, SonarQube-Slack-Pusher

… which would push a notification like this in a Slack channel.


What needs to be in place

  1. QualityGate for a SonarQube project
  2. Incoming WebHook integration to your Slack channel
  3. Installed Jenkins plugin, Sonar-Slack-Pusher
  4. Configured Jenkins job pushing to Slack

Quality gates
The notification above highlights a quality gate that has failed in SonarQube. A quality gate is a way of highlighting that we are not meeting expected quality criteria for a SonarQube project. In the SonarQube UI this is visualised by read and yellow highlighting and could be things like warnings in the code or not enough unit test coverage.

Well, yes a quality gate needs to be defined in SonarQube. It could be linked to an existing project already but it is also possible to pass the quality gate as a part of running a SonarQube analysis job.

Configure the Slack channel
The SonarQube project/’quality gate’ and the Slack channel is there. Add an Incoming WebHook to the channel and note down the hook URL, you will need it when configuring the Jenkins job, you will also need channel admin rights to perform this step.

Pushing quality gate information from Jenkins to the Slack channel
Assuming that there is a Jenkins job that triggers and runs a SonarQube pipeline, i.e. pushing the results to SonarQube. Add the Sonar-Slack-Pusher plugin to your Jenkins installation and add the corresponding Post-build Action to she SonarQube job.

Configure it to use

  • hook URL given when configuring the Slack WebHook
  • sonar URL
  • SonarQube job name and if using branches add that as well.


Bam all set! Run the job and if you have any failing quality gates you will get a notification in your channel.

Overview of sporadically failing test cases in Jenkins – UnitTH Jenkins plugin

Never, ever a stable blue build right? It does not seem to matter what you do, but for system integration tests there always seems to one or a few sporadically failing test cases. What can be extra annoying is that there might always be different test cases that sporadically fail, not the same one or two. To be able to determine the success of executed test suites there is a need to get an overview of the last few runs. The easiest way to visualise this is to create a matrix of test runs versus test cases to get a hit map with frequency of failures for specific test cases.


Test case failure spread.

For those using Jenkins there is a small Jenkins plugin at Sourceforge that can be added to the post build steps of any job that generates test results. The plugin gives you useful overview and stats for the available build test results.



  • Edit the configuration of a Jenkins job and in the post build section select the plugin
  • Run the job again to get the first matrix report, there will be a link in the sidebar
  • Every failed run of a test case has a link to the report trace in the build it was executed, simply click on the red hits in the matrix