Use Case

My team uses both Releases AND Sprints in our Jira Scrum Project. How do you recommend we configure the Release and Requirement integration in qTest Manager?

Overview

Scrum Projects in Jira are recommended for teams working with an iteration-based approach to development.

A Release (or Fixed Version) is a set of features (issue types) deployed together as a single update to your application being developed. Assigning issues to versions will determine which new features for your application will be available to your customers when the release is deployed. To ensure teams release new versions on a regular basis, releases are often scheduled on a fixed date.

Sprints define a period of time in which development teams implement and deliver a prescribed amount of product functionality. A sprint is a collection of features you ideally will complete in a fixed period of time, but you may not necessarily do so by the release date. Features and issues may change sprints during a release (or even change releases), and once a team reaches a release date any incomplete features may move out of their active Sprints into the product backlog to be reassigned.

Because of this, releases may span multiple sprints and sprints may span multiple releases.

When thinking about how to best integrate your Jira projects with qTest Manager it is best to understand which milestones best drive your testing efforts, Releases or Sprints.

For instructions on how to import releases and requirements from JIRA, please refer to the setup steps described in the following sections.

Import and Use Releases from Jira
Import and Use Requirements from Jira

When Sprint Development Efforts Span Multiple Releases

The first Jira Project example uses both Releases and Sprints to plan User Story development efforts.

• Releases are planned as Fixed Versions
• User Story development is planned according to Sprint

The important factor in this example is that Sprint work can span multiple Releases and Releases are developed across multiple Sprints.

How to Structure

• Import Jira Fixed Versions into qTest Release Integration.
• Import Jira Issues into qTest Requirement Integration.
• Organize by Fixed Version and then by Sprint Value.

Importing Jira Fixed Versions as Releases in your qTest Project ensures that your QA Project is structured at the same Release cadence your development team is driving towards in Jira. Your qTest users will always be sure which User Stories they should be testing against for each Release since the release scope is automatically populated from Jira.

 

Importing User Stories (or any issue type) as Requirements in your qTest Project and organizing them automatically by Fixed Version and then Sprint ensures that your QA team is aligned to the development cadence for new features being implemented.

Limitation

The one limitation is that the two available fields are both used to automatically organize imported requirements into a nested folder structure. While you cannot choose another field such as "Status” (or any other custom field) to drive the imported folder structure, your qTest users will be aligned with your development teams efforts.

You can manually add additional folder levels to organize User Stories by Priority, Status, etc.

The folder structure in the Test Execution tab will align with your Jira Release versions to ensure that your QA team is testing against the correct release for your system under test. When creating Test Runs you will be able to view Test Cases according to Jira Sprint Value.

If Sprint Development Efforts Do Not Span Multiple Releases

The second Jira Project example uses both Releases and Sprints to plan User Story development efforts. However, this assumes that Sprints never span multiple releases. Releases are still planned as Fixed Versions and User Story development is planned according to Sprint, but all User Stories in any given Sprint align to a single Fixed Version. If this aligns with your Jira Project structure you may want to consider this option.

How to Structure

• Import Jira Fixed Versions in qTest Release Integration.
• Import Jira Issues in qTest Requirement Integration.
• Organize by Sprint Value.
  

Importing Jira Fixed Versions as Releases in your qTest Project ensures that your QA Project is structured at the same Release cadence your development team is driving towards in Jira. Your qTest users will always be sure which User Stories they should be testing against for each Release since the release scope is automatically populated from Jira.

Importing User Stories (or any issue type) as Requirements in your qTest Project and organizing them automatically by Sprint and then Status (or any other Jira field value) ensures that your QA team is aligned to the development cadence for new features being implemented.

Benefit

The potential benefit is that this opens up an additional Jira field value to automatically organize imported requirements into a nested folder structure. You can now automatically organize User Stories one level past Sprint such as "Status” (or any other custom field).

 

The folder Structure in the Test Execution tab will align with your Jira Release versions to ensure that your QA team is testing against the correct release for your system under test. When creating Test Runs you will be able to view Test Cases according to Jira Sprint Value.

NOTE: As previously mentioned, Releases may span multiple Sprints and Sprints may span multiple Releases. The example above assumed that all issues tied to a Sprint are part of a single Release.

If your Sprints span multiple Releases and you choose to set up your environment as described above, you will need to ensure that when creating Test Runs the linked requirements are part of the appropriate Release Scope. This can still be done because traceability is maintained throughout your qTest project. The drawback is that this is a manual effort for each Test Run that needs to be created.

My QA Team and Reporting does not Require Release Alignment

The third Jira Project example use both Releases and Sprints to plan User Story development efforts. However, this assumes that Sprints never span multiple releases. Releases are still planned as Fixed Versions and User Story development is planned according to Sprint, but all User Stories in any given Sprint align to a single Fixed Version.

The important factor in Option 3 is while your Jira Projects are structured according to Releases for deployment milestones, your development and testing efforts, as well as their traceability, may not need to align to Releases, only Jira Sprint Values.

How to Structure

• Import Jira Sprints in qTest Release Integration.
• Import Jira Issues in qTest Requirement Integration.
• Organize by Sprint Value.

Importing Jira Sprints as Releases in your qTest Project ensures that your QA Project is structured at the same development cadence your development team is driving towards in Jira. Your qTest users will always be sure which User Stories they should be testing against for each Sprint since the release scope is automatically populated from Jira.

Importing User Stories (or any issue type) as Requirements in your qTest Project and organizing them automatically by Sprint and then Status (or any other Jira field value) ensure that your QA team is aligned to the development cadence for new features being implemented.

Benefit

The potential benefit is that this opens up an additional Jira field value to automatically organize imported requirements into a nested folder structure. You can now automatically organize User Stories one level past Sprint such as ‘Status” (or any other custom field).

The folder Structure in the Test Execution tab will align with your Jira Sprint Values to ensure that your QA team is testing against the current Sprint for your system under test. When creating Test Runs you will be able to view Test Cases according to Jira Sprint Value.

NOTE: The option above does not take into consideration your Jira Project Fixed Versions. However, if your QA team would best be structured at the Sprint level to drive testing efforts you will not lose the ability to create custom reports in qTest Insights since the Jira Fixed Version value is populated in your Requirements.

Limitation

The drawback is that you will have to create custom reports. The out of the box Release Filter in qTest Insights pertains to the Release Objects in your qTest Manager project (in this example Jira Sprint Values).