Best Practices for Jira Release Integration

Jira Release Integration was introduced in qTest Manager version 8.9. Here are some FAQs and best practice recommendations to help you leverage this new feature and incorporate it into your Jira and qTest workflow.

For more details, refer to Import and Use Releases from Jira.

My team tests for both Sprints AND releases. How do you recommend we set up the Jira Release integration?

You can select Jira Fix Version, Sprints, or both to automatically create Releases in qTest Manager. If you select both, they will both be created as Releases. In this case, use the Releases that represent Jira Sprints to plan and execute testing within each Sprint, such as new feature development and regression. Use the Releases that represent Jira Fix Versions to plan and execute testing that is necessary in order to package up the final Release. such as regression and system testing.

Do I need to do anything on the Jira side to configure the new features?

For Jira Cloud, there is no need to do anything on the Jira side to use the new features.

For Jira Server, please ask your Jira admin to update to the latest version of the Jira Integration: qTest Enterprise plug-in. The newest plug-in version is required in order for the new Release Integration to work properly. If you don’t upgrade the plug-in, you can still import Releases from Jira fix versions or Sprints but if the fix version or Sprint properties or linked requirements scope changes, it will not reflect automatically in qTest Manager. If you remain on an older plug-in version, your existing Jira integration features (such as Requirements or Defects integration) will work fine.

What if I already organized my Jira requirements by Fix Version or Sprint?

The Jira Requirements Integration allows you to organize requirements from Jira into a nested folder structure using up to two Jira fields. If your requirements integration was already configured based on Fix Version or Sprint, you can free up one of the fields to organize requirements by some other field, such as Status, Priority, Component, or even a custom field from Jira. When you switch out the fields to organize requirements, make sure to save the new configuration and then click Retrieve Jira data, which will reindex your imported requirements and organize them into the new folder structure. Your Jira requirements will still retain any linkages to test cases and executions even if they’re reorganized by the data retrieval.

After the data is retrieved, new folders will be created under the Imported from Jira folder based on the fields you selected for the new organization. Keep in mind that any old requirements folders (such as Fix Version or Sprint folders) will still exist. Before you delete these empty requirements folders, check to make sure that there aren’t any test cases in these folders in Test Design.

I’ve been using the Jira integration for a while and have a lot of data in Test Execution already. What is the best way to handle my existing data and incorporate this new Release Integration into my project?

How you manage your existing data to incorporate the new Release Integration may be affected by your existing use (or non-use) of Releases in the Test Plan area. See the options laid out in scenarios 1A, 1B, 2A, and 2B below.

Scenario #1 - If your Test Plan area was previously NOT Used

If you didn't create any Release objects at all in Test Plan, you had most likely skipped Release objects altogether and started Test Execution hierarchy by creating Test Cycles as the highest level of the hierarchy in Test Execution. You most likely used Test Cycles to represent the Sprints or Releases from Jira. If this description matches your existing Test Plan usage, consider options A and B below:

Option A - "Fresh Start"

  1. Setup JiraRelease integration for new Releases / Sprints - don't worry about bringing over Releases that already happened or Sprints that were already completed. In the configuration, bring over:

    • Fix Versions: Unreleased only (clear Released) - FYI this is the default selection

    • Sprints: Active and Future only (clear Completed) - FYI this is the default selection

  2. When the new Release objects are created in the Test Plan...

    • For past Releases, leave your existing Test Execution as-is.

    • For all current and future Releases, there's no need to manually create Test Cycles to represent the Sprint or Fix Version. You can build your Test Execution hierarchy directly underneath the newly created Jira Releases.

Option B - "Consolidate Historical Data"

  1. Setup JiraRelease integration for new Releases / Sprints AND old Releases / Sprints. In Integration Settings, setup the Release Configuration to import:

    • Fix Versions: Unreleased AND Released - FYI this is NOT the default selection

    • Sprints: Active, Future, AND Completed - FYI this is NOT the default selection

  2. When the new Release objects are created in the Test Plan... in Test Execution, you'll end up with Test Cycles that you manually created previously to represent your old Fix Versions or Sprints. You'll also notice new Release objects that were just now automatically created to represent the same Fix Version or Sprints.

  3. To consolidate the data:

    • For past Releases, drag and drop your previous Test Cycles to reorganize them under the corresponding Releases that were just now created from Jira

    • For all current and future Releases, build your Test Execution hierarchy directly underneath the newly created Jira Releases.

Scenario #2 - If your Test Plan area WAS used

If you did create Release objects manually in the Test Plan to represent Sprints or Releases from Jira. you likely organized your Test Execution area so that Test Cycles and Suites were nested underneath the Release objects. If this description matches your existing Test Plan usage, consider Options A and B below:

Option A - "Fresh Start"

  1. Setup JiraRelease integration for new Releases / Sprints - don't worry about bringing over Releases that already happened or Sprints that were already completed. In the configuration, bring over:

    • Fix Versions: Unreleased only (clear Released) - FYI this is the default selection

    • Sprints: Active and Future only (clear Completed) - FYI this is the default selection

  2. When the new Release objects are created in the Test Plan... in Test Execution, you'll end up with Releases that you manually created previously to represent your old Fix Versions or Sprints. You'll also notice new Release objects (distinguishable by the Atlassian symbol) that were just now automatically created to represent the same Fix Version or Sprints.

  3. Going Forward:

    • For past Releases, leave your existing Test Execution as-is, since your execution data is already organized by the manually created Releases.

    • For all current and future Releases, build your Test Execution hierarchy directly underneath the newly created Jira Releases.

Option B - "Consolidate Historical Data"

  1. Setup JiraRelease integration for new Releases / Sprints AND old Releases / Sprints. In the configuration, bring over:

    • Fix Versions: Unreleased AND Released - FYI this is NOT the default selection

    • Sprints: Active, Future, AND Completed - FYI this is NOT the default selection

  2. When the new Release objects are created in the Test Plan... in Test Execution, you'll end up with Releases that you manually created previously to represent your old Fix Versions or Sprints. You'll also notice new Release objects (distinguishable by the Atlassian symbol) that were just now automatically created to represent the same Fix Version or Sprints.

  3. To consolidate the data:

    • For past Releases, Drag and drop the execution data that was housed under the old manually created Releases (Test Cycles, Suite, Runs) to reorganize them under the corresponding Releases that were just now created from Jira.

    • For all current and future Releases, build your Test Execution hierarchy directly underneath the newly created Jira Releases

Will the number of Site Fields I have affect the performance of my qTest instance?

Yes, a large number of site fields can affect the performance of your qTest instance. We recommend establishing a method for governing the site fields in your instance, such as limiting the users who can create site fields and the number of site fields that can be created, to ensure that all site fields created are needed for your organization. Any instruction or discussion of site fields, including integration with site fields, assumes that your instance contains a reasonable amount of site fields. For more information about site fields, refer to Site Fields.