QMetry Test Management for Jira v4.0 and above

QTM4J Bamboo Integration - DevOps/CD add-on is designed for QMetry Test Management for Jira.

Download Link: QTM4J Bamboo Integration - DevOps/CD

Once you are done with its installation, follow these steps to set up a simple build Plan.

Note

This document is only applicable for QMetry Test Management for Jira v4.0 and above.

Build Plan

Perform the following steps to build a plan:

  1. Open Bamboo in a web browser.

  2. Click the Create drop-down list and select Create a new Plan. If you are using Bamboo for the first time, just click the Create your first build plan button.

  3. The Configure plan page appears. Enter the Project name, Plan name, and other details related to the plan.

  4. Click the Create button.

    You can even link a code repository with the plan.

  5. Click n the Save and Continue button.

  6. The next screen of Configure tasks appears.

    Note

    Bamboo follows a hierarchical order: Plan > Stage > Job > Task.

    This task remains under the default Job and the default Job remains under default Stage.

    Set up a repository for the newly created test plan. Add a Source Code Checkout task that uses the repository you created earlier.

    Configure Job Create Plan

  7. Add a Builder Task type. Maven 3.x task is added here.

    Maven3x Task

  8. Click Add task to add more tasks to the plan.

  9. The Task types wizard appears. Select task QTM4J Bamboo Integration – v4.x above from the All tab.

  10. Configure the QTM4J Bamboo Integration – v4.x above task.

Jira Cloud

Refer to this section for information on the Bamboo plugin for Jira Cloud.

Bamboo Jira Cloud

Test Cycle Fields

Cloud Test Cycle Fields

Test Case Fields

Cloud Test Case Fields

Test Case Execution Fields

Cloud Test Case Execution Fields

The following table shows the parameters used during configuration.

Parameter

Type

Required

Description

Region

selection

No

QTM4J supports two regions: USA and Australia. Check your region from Jira, navigate to QMetry > About > Hosted Region.

USA is selected by default.

Automation API Key

string

Yes

Your API Key. API Key is unique for a specific user in a single project. The result will be imported for the project associated with the given API Key.

Result File path/Result Directory

string

Yes

Path to your result file to be uploaded.

Attachment

checkbox

No

Check to upload attachments in execution. Default value: false.

Supported formats:

cucumber/json

qaf/json

Match Test Steps

checkbox

No

  • True (Default): Create/Reuse a test case with a summary and test steps that exactly match the automated test case uploaded through the result file. The execution results and other execution details of the test case and steps will be imported from the automation result file.

  • False:

When the Test Cycle is not been Reused

Create/Reuse a test case with a summary or test case key that exactly matches the automated test case uploaded through the result file, and exclude matching of test steps. The execution results of the test case will be imported or calculated based on the test case/step results from the automation result file. The execution result of the test case will be propagated to the test steps in the case of test case reuse/creation. Individual test case steps will not be matched and their execution results/details will not be picked from the result file.

When the Test Cycle is been Reused

When the Test Case Key is mapped in the result file and the Test Case Key is found linked to the Test Cycle.

The existing linked test case version, which is part of the Test Cycle will be used. If multiple versions of the same test case key are linked to the test cycle, the one which traced first will be used. The test steps will not be matched to create a new version or link a different version.

When the Test Case Key is mapped in the result file and the Test Case Key is not linked to the Test Cycle and the Test Case Key exists in the Test Case Library.

The existing latest version of the test case that matches based on the test case summary will be linked to the existing Test Cycle. If there are multiple test cases with the same summary exist, the one which is traced first will be linked to the existing Test Cycle. The test steps will not be matched to create a new version or link a different version.

In a project where propagation is off, the status of the step will not be mapped/changed.

When the Test Case Key is mapped in the result file and the Test Case Key is not found linked to the Test Cycle and the Test Case Key is not found in the Test Case Library, and the Test Case Summary matches with any existing test cases linked to the Test Cycle.

The existing linked Test Case version which is part of the Test Cycle will be used. The test steps will not be matched to create a new version.

The Test Case Key is not mentioned in the result file and the Test Case Summary matches any existing test case that is already linked to the Test Cycle.

The existing linked Test Case version which is part of the Test Cycle will be used based on the summary. The test steps will not be matched to create a new version.

When the Test Case Key is mapped in the result file and the Test Case Key does not exist in the Test Cycle OR is Not found in Library and the Test Case Summary also does not match any existing Test case in the Test Cycle andTest Case with the same summary isfound in the Test Case Library.

The existing latest version of the test case that matches based on the test case summary will be linked to the existing Test Cycle. If there are multiple test cases with the same summary exist, the one that is traced first will be linked to the existing Test Cycle. The test steps will not be matched to create a new version or link a different version.

When the Test Case Key is mapped in the result file and the Test Case Key does not exist in the Test Cycle OR is Not found in the Library and the Test Case Summary also does not match any existing Test case in the Test Cycle OR is not found in the Test Case Library.

A new test case without steps will be created and will be linked to the Test Cycle being reused.

The execution results of the test case will be imported or calculated based on the test case/step results from the automation result file. The execution result of the test case will be propagated to the test steps in the case of test case reuse/creation. Individual test case steps will not be matched and their execution results/details will not be picked from the result file.

In a project where propagation is off, the status of the step will not be mapped or changed.

Automation Hierarchy

selection

No

Applicable only for JUnit or TestNG frameworks.

Set Hierarchy for Automation Uploads Test Cycle - Test Case - Test Step Hierarchy as 1 (Default), 2 or 3.

Default Settings: Will refer to QMetry > Automation > Automation API > Settings.

Automation Hierarchy 1: Test Name Tag is created as Test Case & Test Method Name Tag is created as Test Step.

Automation Hierarchy 2: Test Name Tag is created as Test Cycle & Test Method Name Tag is created as Test Case.

Automation Hierarchy 3: Suite Name Tag is created as Test Cycle & Test Method Name Tag is created as Test Case.

Append Test Name

selection

No

Applicable only for JUnit or TestNG frameworks automation result uploads with Hierarchy 2 or 3.

Accepted Values = false (Default), true

Default Settings: Will refer to QMetry > Automation > Automation API > Settings.

  • For TestNG

    • Yes: Append the Test Name to the Test Method Name while creating the Test Case Summary.

    • No: Create the Test Case Summary as per the Test Method Name in the result file

  • For JUnit

    • No: Create the Test Case Summary as per the Test Case Name available in the result file.

    • Yes: Append Test Suite Name to Test Case Name while creating the Test Case Summary.

Note

If the Test Name or Test Suite Name length is more than 255 characters, the name will be truncated.

Format

selection

Yes

Format of result file to be imported. Supported formats:

cucumber/json

testng/xml

junit/xml

qaf/json

hpuft/xml

specflow/json

Test Cycle To Reuse

string

No

Key of the test cycle to be reused.

Build

string

No

Name of the build for test cycle execution

Environment

string

No

Name of the environment on which test cycle has to be executed.

Test Case, Test Cycle Fields, and Test Case Execution Fields

Parameter

Type

Required

Description

Summary (only for Test Cycle)

string

No

Summary of test cycle.

Description

string

No

Description of test case/test cycle.

Folder Id

string

No

Folder Id to organize test cases and test cycles in that particular folder.

You can get the folderId by right clicking on the folder and selecting option Copy Folder Id.

If the mentioned folderId does not exist, an error will be shown. The test cases/test cycles will be not be created.

Priority

string

No

Priority to be added to the test case/test cycle.

Status

string

No

Status to be added to the test case/test cycle.

Components

string

No

Comma-separated names of Components to be added to the test case/test cycle.

Labels

string

No

Comma-separated names of Labels to be added to the test case/test cycle.

Fix Version Id

number

No

Id of Fix Version to be added to the test case/test cycle.

Sprint Id

number

No

Id of Sprint to be added to the test case/test cycle.

Assignee

string

No

Account Key of the current user for test case/test cycle/test cycle execution assignee.

Reporter

string

No

Account Key of the current user test case/test cycle.

Precondition (only for Test Case)

string

No

Precondition of the test case.

Estimated Time (only for Test Case)

string

No

Estimated time for test case in ‘HH:MM:SS’ format.

Planned Start Date (only for Test Cycle)

string

No

Planned Start Date of test cycle in 'dd/MMM/yyyy HH:MM' format.

Planned End Date (only for Test Cycle)

string

No

Planned End Date of test cycle in 'dd/MMM/yyyy HH:MM' format.

Custom Fields

string

No

Comma separated custom fields in JSON array

Comment (only for Test Case Execution)

string

No

Test Case Execution Comment

Actual Time (only for Test Case Execution)

string

No

Actual time for test case execution in ‘HH:MM:SS’ format

Planned On

string

No

Planned Date of Test Case Execution 'dd/MMM/yyyy' format

Note

If you are reusing the test case and test cycle, the above field values will not be updated in QMetry Test Management for Jira.

Jira Server

Refer to this section for information on the Bamboo plugin for Jira Server.

Bamboo Jira Server

Test Cycle Fields

Server Test Cycle Fields

Test Case Fields

Server Test Case Fields

Test Case Execution Fields

Server Test Case Execution Fields

The following table shows the parameters used during configuration.

Parameter

Type

Required

Description

Jira URL

string

Yes

Enter Jira URL.

Basic Authentication OR

Personal Access Token

string

Yes

Basic Authentication

Basic authentication with Jira's credentials.

  • Jira Username

  • Jira Password: Password for Jira instance.

Personal Access Token

If the Allow basic authentication on API calls option is disabled in Jira, then Personal Access Token is required for authentication.

To generate a personal access token, perform the following steps:

  1. Go to the User Profile of your Jira.

  2. Click on Personal Access Tokens and click on Create token.

Automation API Key

string

Yes

Your API Key. API Key is unique for a specific user in a single project. The result will be imported for the project associated with the given API Key.

Result File path/Result Directory

string

Yes

Path to your result file to be uploaded.

Attachment

checkbox

No

Check to upload attachments in execution. Default value: false.

Supported formats:

cucumber/json qaf/json

Match Test Steps

checkbox

No

  • True (Default): Create/Reuse a test case with a summary and test steps that exactly match the automated test case uploaded through the result file. The execution results and other execution details of the test case and steps will be imported from the automation result file.

  • False:

When the Test Cycle is not been Reused

Create/Reuse a test case with a summary or test case key that exactly matches the automated test case uploaded through the result file, and exclude matching of test steps. The execution results of the test case will be imported or calculated based on the test case/step results from the automation result file. The execution result of the test case will be propagated to the test steps in the case of test case reuse/creation. Individual test case steps will not be matched and their execution results/details will not be picked from the result file.

When the Test Cycle is been Reused

When the Test Case Key is mapped in the result file and the Test Case Key is found linked to the Test Cycle.

The existing linked test case version, which is part of the Test Cycle will be used. If multiple versions of the same test case key are linked to the test cycle, the one which traced first will be used. The test steps will not be matched to create a new version or link a different version.

When the Test Case Key is mapped in the result file and the Test Case Key is not linked to the Test Cycle and the Test Case Key exists in the Test Case Library.

The existing latest version of the test case that matches based on the test case summary will be linked to the existing Test Cycle. If there are multiple test cases with the same summary exist, the one which is traced first will be linked to the existing Test Cycle. The test steps will not be matched to create a new version or link a different version.

In a project where propagation is off, the status of the step will not be mapped/changed.

When the Test Case Key is mapped in the result file and the Test Case Key is not found linked to the Test Cycle and the Test Case Key is not found in the Test Case Library, and the Test Case Summary matches with any existing test cases linked to the Test Cycle.

The existing linked Test Case version which is part of the Test Cycle will be used. The test steps will not be matched to create a new version.

The Test Case Key is not mentioned in the result file and the Test Case Summary matches any existing test case that is already linked to the Test Cycle.

The existing linked Test Case version which is part of the Test Cycle will be used based on the summary. The test steps will not be matched to create a new version.

When the Test Case Key is mapped in the result file and the Test Case Key does not exist in the Test Cycle OR is Not found in Library and the Test Case Summary also does not match any existing Test case in the Test Cycle andTest Case with the same summary isfound in the Test Case Library.

The existing latest version of the test case that matches based on the test case summary will be linked to the existing Test Cycle. If there are multiple test cases with the same summary exist, the one that is traced first will be linked to the existing Test Cycle. The test steps will not be matched to create a new version or link a different version.

When the Test Case Key is mapped in the result file and the Test Case Key does not exist in the Test Cycle OR is Not found in the Library and the Test Case Summary also does not match any existing Test case in the Test Cycle OR is not found in the Test Case Library.

A new test case without steps will be created and will be linked to the Test Cycle being reused.

The execution results of the test case will be imported or calculated based on the test case/step results from the automation result file. The execution result of the test case will be propagated to the test steps in the case of test case reuse/creation. Individual test case steps will not be matched and their execution results/details will not be picked from the result file.

In a project where propagation is off, the status of the step will not be mapped or changed.

Automation Hierarchy

selection

No

Applicable only for JUnit or TestNG frameworks.

Set Hierarchy for Automation Uploads Test Cycle - Test Case - Test Step Hierarchy as 1 (Default), 2 or 3.

Default Settings: Will refer to QMetry > Automation > Automation API > Settings.

Automation Hierarchy 1: Test Name Tag is created as Test Case & Test Method Name Tag is created as Test Step.

Automation Hierarchy 2: Test Name Tag is created as Test Cycle & Test Method Name Tag is created as Test Case.

Automation Hierarchy 3: Suite Name Tag is created as Test Cycle & Test Method Name Tag is created as Test Case.

Append Test Name

selection

No

Applicable only for JUnit or TestNG frameworks automation result uploads with Hierarchy 2 or 3.

Accepted Values = false (Default), true

Default Settings: Will refer to QMetry > Automation > Automation API > Settings.

  • For TestNG

    • Yes: Append the Test Name to the Test Method Name while creating the Test Case Summary.

    • No: Create the Test Case Summary as per the Test Method Name in the result file

  • For JUnit

    • No: Create the Test Case Summary as per the Test Case Name available in the result file.

    • Yes: Append Test Suite Name to Test Case Name while creating the Test Case Summary.

Note

If the Test Name or Test Suite Name length is more than 255 characters, the name will be truncated.

Format

selection

Yes

Format of result file to be imported. Supported formats:

cucumber/json

testng/xml

junit/xml

qaf/json

hpuft/xml

specflow/json

Test Cycle To Reuse

string

No

Key of the test cycle to be reused.

TestNG:

Hierarchy 2: The Test Cycle To Resue will be ignored.

Hierarchy 3: If the Test Cycle To Resue is provided, then the suite name in the files will be ignored. All the test case results for all suites and files will be uplaoded in a single cycle similar to Hierarchy 1 (default).

JUnit:

Hierarchy 2: The Test Cycle To Resue will be ignored.

Hierarchy 3: If the Test Cycle To Resue is provided, then test case results for all suites and files will be uploaded in a single cycle.

Build

string

No

Name of the build for test cycle execution

Environment

string

No

Name of the environment on which the test cycle has to be executed.

Test Case, Test Cycle Fields and Test Case Execution Fields

Parameter

Type

Required

Description

Summary (only for Test Cycle)

string

No

Summary of test cycle.

Description

string

No

Description of test case/test cycle.

Folder Path

string

No

Folder path to organize test cases and test cycles.

Priority

string

No

Priority to be added to the test case/test cycle.

Status

string

No

Status to be added to the test case/test cycle.

Components

string

No

Comma separated names of Components to be added to the test case/test cycle.

Labels

string

No

Comma separated names of Labels to be added to the test case/test cycle.

Fix Version Id

number

No

Id of Fix Version to be added to the test case/test cycle.

Sprint Id

number

No

Id of Sprint to be added to the test case/test cycle.

Assignee

string

No

Account Key of the current user for test case/test cycle/test cycle execution assignee.

Reporter

string

No

Account Key of the current user test case/test cycle.

Precondition (only for Test Case)

string

No

Precondition of the test case.

Estimated Time (only for Test Case)

string

No

Estimated time for test case in ‘HH:mm’ format

Planned Start Date (only for Test Cycle)

string

No

Planned Start Date of test cycle in 'dd/MMM/yyyy HH:mm' format

Planned End Date (only for Test Cycle)

string

No

Planned End Date of test cycle in 'dd/MMM/yyyy HH:mm' format

Custom Fields

array

No

Comma separated custom fields in JSON array

Comment (only for Test Case Execution)

string

No

Test Case Execution Comment

Actual Time (only for Test Case Execution)

string

No

Actual time for test case execution in ‘HH:mm’ format

Planned On

string

No

Planned Date of Test Case Execution 'dd/MMM/yyyy' format

Note

If you are reusing the test case and test cycle, the field values will not be updated in QMetry Test Management for Jira.

After adding parameters, perform the following steps:

  1. Click the Run drop-down menu and select the Run plan option.

    Run Plan

    You can see the success message in the logs for the job.

  2. Navigate to the Jira Issue page. You can view the report by clicking on the graph icon.

Configure Specflow

Perform the following steps to configure Specflow:

  1. Checkout the code from the repository.

    Source Code Checkout

  2. Add script in Script body field to update packages for msbuild using NuGet.exe file from checkout repository.

    Script.png

  3. Configure MS Build Executable

    1. Click Add new executable.

    2. Set path for executable.

  4. MS Build Configuration

    1. Project File: Give path to the Solution. Project File or MSBuild project will be executed when this Job runs.

  5. VS Test Executable

    1. Click Add new executable.

    2. Add executable for vstest.

  6. VS Test Configuration

    1. Tests File Path: The relative path to your .dll/.exe/.appx/.pyproj/.ps1/etc... that your Test Adapter will discover and execute tests from.

      VStest Configuration
In this section:
© 2025
Publication date: