Menu

Best Practices for Jira Release Integration

Jira Release Integration was introduced in qTest Manager 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, check out these articles: 

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 and / or Sprints 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 like 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 like regression and system testing.

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

Jira Cloud: No need to do anything on the Jira side to use the new features.

Jira Server: Please request your Jira admin to update to the latest version of qTest Test Management for Jira Server plugin v6.11.7. The new plugin version is required in order for the new Release Integration to work properly. If you don’t upgrade the plugin, you can still import Releases from JIRA fix versions or sprints but the auto-sync (if the fix version or sprint properties or linked requirements scope changes), those changes won’t reflect automatically in qTest Manager. If you remain on the old plugin version, your existing JIRA integration features (e.g. 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 2 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 re-index 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 re-organized by the data retrieval.

NOTE: 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 (e.g. 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 already used 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, 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 Jira Release 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 (uncheck Released) - FYI this is the default selection
    • Sprints: Active and Future only (uncheck 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 Jira Release 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 Jira Release 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 (uncheck Released) - FYI this is the default selection
    • Sprints: Active and Future only (uncheck 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 Jira Release 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
Subscribe To Our Blog
Powered by Zendesk