Best Practices for Integrating with Version One

Structuring qTest Projects Integrated with VersionOne

This article focuses on best practices for integrating your qTest Projects with Version One and how to establish an efficient process and workflow between the two tools. When thinking about how to best integrate your VersionOne projects with qTest Manager, it is important to understand which development milestones best drive your testing efforts: Releases or Sprints.

For detailed instructions on how to connect your project with your VersionOne instance please refer to the setup steps described in the following article: Setting up the VersionOne Connection

  • A Release is a set of features (Backlog Items of Stories) deployed together as a single update to your application being developed. Assigning features to Releases 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.

Example VersionOne Structure

In this article, we will be referring to a standard example where all development efforts are structured as a Project under the System root folder in VersionOne. The Development Project is broken up into various initiatives or sub-projects.

We will focus on one Sample Project that is named 'VersionOne Sample Project,' which is divided into two Releases (Child-Projects) as seen below:



Each Release is divided into Sprints. 'Sample Release 1' contains 3 Sprints as seen below in the 'Iterations' section of the screen:



Sprints also called an iteration, are comprised of items from the Backlog. As teams begin their Sprint/Iteration scheduling and planning, the team could:

  • group them by Portfolio,
  • assign work to specific teams,
  • further break down Backlog Items into specific tasks,
  • and estimate their effort to complete them.

Any items not assigned to a Sprint remains in the Backlog until they can be committed to a Sprint effort.


Configuring the Integration in qTest

After you successfully set up the connection with your V1 OnDemand instance, you can begin the integration configuration by setting up the defect integration.

Defect Integration

For detailed instructions on how to configure defects with VersionOne, please refer to the setup steps described in the following article: Configuring Defects with VersionOne

In this example, we are configuring the integration to allow our qTest users to log defects both at the root project level, 'VersionOne Sample Project', and each Release Level, 'Sample Release 1' and 'Sample Release 2'.

We recommend you add the overall project and each child-project (Releases) as a defect type so that your testing team can select the appropriate option when logging an issue at the time of test failure. But, if you want to limit users to only log defects at the root project folder or solely into a specific release this can be configured here.

Perhaps you only want testers to log defects at the project level and not the release level so your development team is responsible for assigning/committing defects to specific releases.


Next, we will configure the Requirement integration.

Requirement Integration

For detailed instructions on how to configure defects with VersionOne, please refer to the setup steps described in the following article: Configuring Requirement Integration with VersionOne

In this example, we are only adding requirement types for our Releases, 'Sample Release 1' and 'Sample Release 2', and not the entire root project, 'VersionOne Sample Project'.

The reason for this is because we only want our testing team to work on items that are committed to a release. When and only when Backlog Items are assigned to a specific release will they be imported in qTest automatically.


Below is our final configuration settings in qTest.



Organizing your qTest Project

Create your Releases in Test Plan

You will initially want to create a Release folder in Test Plan for each Release in your VersionOne project. In this example we have two Releases; 'Sample Release 1' and 'Sample Release 2'. For each new Release that is created in VersionOne your qTest team will need to create a Release folder in the Test Plan tab to ensure that your qTest project is aligned to the same release cadence your development team is working on in VersionOne.


View Imported VersionOne Requirements

Upon initial import, VersionOne objects will be treated as Requirements in qTest Manager. By default, these integrated requirements will be loaded into a common Module folder named 'Imported from VersionOne' as shown below:


Re-organizing your Imported VersionOne Requirements

The first activity you will want to complete is re-organizing your initial imported requirements. When integrating with active VersionOne projects, this folder could contain hundreds of requirements, but ideally, this integration and initial import should be configured at the very beginning of each new VersionOne project or Release. Therefore, the process is more concentrated on managing the integration than an initial organization effort.

When organizing the initial import we suggest bucketing your requirements at a single property level so the management efforts are mitigated. In this example, we are going to organize our Requirements by their specific Sprint value. Backlog Items are less likely to change Sprint values as often as they may change status or team, so if you organize requirements by more than one level e.g. (by Sprint, Team and Status), your qTest users will be spending too much time keeping your requirement folders up to date.

We are going to create a folder outside of the 'Imported from VersionOne' folder for each of our Sprints. This way you can think of the 'Imported from VersionOne' folder as the container for any new Backlog Item that comes into scope for you release that then needs to be placed in the appropriate Sprint folder. You want to create your Sprint folders outside of the 'Imported from VersionOne' folder and not nested within as sub-folders. Create your Sprint folders as seen below:


Next, you need to drag/drop your imported VersionOne requirements into the appropriate Sprint folders:


Maintaining your Imported VersionOne Requirements

Now that you have updated your existing Backlog Items into their appropriate Sprint folders, your qTest users will need to manage existing issues and organize any new Backlog Items that come into scope. This should require minimal effort if maintained properly.

The image below shows a new backlog item being created in VersionOne.


When your development team creates new stories in the VersionOne backlog and saves, they will automatically appear in qTest in the 'Imported from VersionOne folder', as seen below:


This story will remain in the Backlog in VersionOne until it has been assigned to a Sprint. In the same vein, the Requirement should remain in the 'Imported from VersionOne' folder in qTest until it has been assigned to a Sprint and at that point, you should drag/drop it into the appropriate Sprint folder in qTest.



Your qTest users will need to periodically check the Requirements in the backlog ('Imported from VersionOne' folder) and move them to the appropriate Sprint folder once they have been assigned a Sprint value.


You have to Re-Retrieve each Requirement to get the updated data of V1 objects using the 'Retrieve Data' button on the requirement. Ensure that your qTest team does this each time they are viewing a Requirement so they are viewing the latest updates from VersionOne.

Before Retrieve Data:



After Retrieve Data:


Now you can move this Requirement to the Sprint 3 folder:



HINT: Currently, all VersionOne fields cannot be used to Search or Query in qTest Manager, but you can Search for the name of a VersionOne Requirements by using double quotes. 

Clicking on the search results will take you to that object in qTest Manager.

search_for_name_double_quotes.pngOptional: Maintaining your Release Scope in Test Plan

In the Test Plan, you may want to take the time to populate and maintain the Release Scope for each Release object.

For detailed instructions on how to add Requirements to your Release please refer to the setup steps in the following article: Add Requirements to your Release




By adding Backlog Items to their appropriate Release folder in Test Plan you are ensuring you have full end-to-end traceability between objects in qTest. Several Reports in qTest Insights are driven off the Release Scope and you can also plan your Test Runs in the Test Execution Tab of qTest Manager using this Release traceability.


One limitation may be the amount of time this may take to manage if you have large Releases. You can still generate the same reports in qTest Insights that are driven from this traceability but they may need to be manually created and not provided out-of-the-box.

The other limitation is when planning Test Runs your qTest users will not be able to add Tests based on the Release Traceability. They will not have the option to add Test Runs based on their linked Requirements in a specific Release as seen below (any requirement that has linked test cases that are part of the Release Scope will be available for selection):



This is not a critical piece of functionality, but simply something to consider when deciding if it’s worth taking the time and effort to manage the Release Scope in Test Plan.

However, if all Backlog Items in a Sprint are tied to a single Release this can easily and quickly be managed by selecting the entire Sprint folder when adding Requirements as seen in the screenshot above.

Linking Test Cases to VersionOne Requirements

Imported VersionOne objects can be linked to qTest Manager Test Cases. The linking with qTest Manager Test Cases will be generated in the corresponding VersionOne object's Links section.

For detailed instructions on how to link Test Cases and Requirements, please refer to the setup steps described in the following article: Linking Test Cases and Requirements


When you link or create associated Test Cases to an Imported VersionOne object, qTest Manager also generates a link under the corresponding VersionOne object. To quickly navigate to the Backlog Item in VersionOne click on the ID hyperlink on the Requirement in qTest.



Submitting Defects to VersionOne

You can submit defects to VersionOne from qTest Manager during TestPad Execution or from the Test Log.

For detailed instructions on how to submit Defects to VersionOne, please refer to the setup steps described in the following article: Submitting Defects to VersionOne

qTest users can submit a defect during test execution using the Quick Run or Test Pad window. Optionally they could use the Test Log in Execution History to submit a defect after executing a test run as seen below:

Test Pad window:

Test Log in Execution History:


Once a qTest user selects the appropriate VersionOne Project and Defect Type they will be taken to a native VersionOne defect submission form as seen below:



Specific fields could be auto-populated with qTest information (e.g. the Test Steps in the Description field) depending on your integration configuration.

After clicking save and submitting the Defect into VersionOne, your qTest users will be returned back to qTest Manager.

IMPORTANT: Before closing out of the defect submission window in qTest users need to click on the Defect hyperlink so they can establish traceability to the Backlog Item on the Defect object in VersionOne. If they do not immediately do this after submitting the defect and before closing the defect window in qTest they risk forgetting to establish this critical traceability.

Test Pad window:


Test Log in Execution History:


Users need to assign any BackLog Items to the Defect to track which workitems the Defect is blocking. This should include any and all BackLog items the Test Case was linked to in qTest Manager as a minimum.

qTest users should be able to quickly reference the linked VersionOne Requirements in their active qTest Manager window:


Once the BackLog item has been assigned to the Defect it should be visible as a link in the “Breaks Workitems” section.

image1.png image22.png

Now your qTest users can return to the Defect window on the Test Pad or Test Execution tab of qTest Manager to close it and return to testing.

Review VersionOne Defect After Submission

Review VersionOne Defects in Manager

In qTest Test Execution, you can find VersionOne defect information in many areas:

To view VersionOne defects for a single Test Run, select the Defect icon from the Test Run grid.

For an aggregate list, select the Defect Summary tab for a roll-up of all VersionOne defects related to associated Test Runs. This Defect Summary tab can be customized so that you can display additional VersionOne Defect fields as columns.



Review Defects in Version One

From VersionOne, you can see the link to the qTest Test Run in the Link section of the defect.


Powered by Zendesk