Example of Using Polarion with XRay with OSLC Connect

Overview

Configuring your Jira installation (with XRay) with the QM mappings will make the integration with Siemens Polarion more powerful. You can reference your test artifacts directly to Requirements in Polarion. In Polarion, you can access Tests from Requirements directly on the Validated By links. This improves the ability to have strong traceability across the lifecycle and in reporting on traceability.

Connecting from Jira to Polarion

First, let’s focus on connecting from Jira to Polarion.

Adjusting Type Schemes for Xray Types

The “Issue Types Mapping” for OSLC Connect (in Manage Apps) allows teams to declare many important values about their Jira artifacts on how they connect externally. These options are tied to Jira Schemes, so you can align workflows and actions across many projects.

OSLC defines a set of resource types for Change, Requirements, and Quality Management (testing) and an overlay for Configuration Management. By default, OSLC Connect for Jira targets Change Management Artifacts, however we are now expanded to other optional mappings. You will see this when you open your Scheme’s configuration.

When using Xray, we detect that some elements look like QM artifacts, so you can click “Do you want to associate them?” to create some default mappings.

The result is the following:

I will customize this further to disable some elements from Polarion and set some defaults.

When I unmap the OSLC Resource Type this means I am not supporting linking from Polarion to these artifacts.

I also updated Sub Test Execution to a Test Execution Record to enable linking and reporting.

For each item, I can now set the Edit Link Settings.

On one Tab, I set the label I will see from Polarion, for example:

On the other tab, I changed the linking behavior from Jira to other tools (limiting the available link types).

Once I am done, I will have an overview of the configurations for my scheme.

This is an example configuration. Your configuration may be different based on the needs of your organization and processes.

Creating Project Associations

We must create project associations to link to Polarion from your XRay Tests.

On your project settings, look for OSLC Connect Project Associations.

Add a Polarion project.

Now, your Jira project knows what RM projects can be used for linking.

Linking to Polarion

Now, when navigating to a Test, you can start creating Links. In this link dialog, you see many of the configurations you have made. A Test is a “OSLC Test Case” type supporting these relation types. We focused on the Validates Requirement Relationship.

From Jira, perform Link → Collaboration Link and select the link type and the remote project.

Users will then be provided the remote selection dialog from Polarion.

Note, if you are missing Requirements in the dialogs, you have not configured Polarion to expose requirements as OSLC Requirement Resources. Please review our basic configuration guide for more details → Siemens Polarion OSLC Configurations

Once you link, you can see remote content and have link decorators.

Live links from your Xray artifacts to Polarion Requirements!

Connecting Polarion to Jira XRay

To connect Polarion to Jira in most applications, you should follow our guide, which is linked above. However, to add Xray/QM support, follow the steps as outlined below.

Configuring Polarion for QM

Polarion has a significant amount of configurability to support QM. Since it is not a native ability to support QM, some extensions must be performed.

Update Semantics

The admin of Polarion must update the semantics to recognize both the qm domain and the qm to rm relationship types. Three updates need to be made.

In the namespace section, add the oslc_qm namespace.

CODE

<namespace prefix="oslc_qm" url="http://open-services.net/ns/qm#"/>

In the domains section, add the qm domain and the resource types.

CODE

    <domain prefix="oslc_qm">
       <resourceType label="Test Case" uri="oslc_qm:TestCase"/>
       <resourceType label="Test Plan" uri="oslc_qm:TestPlan"/>
       <resourceType label="Test Script" uri="oslc-qm:TestScript"/>
       <resourceType label="Test Execution Record" uri="oslc-qm:TestExecutionRecord"/>
       <resourceType label="Test Result" uri="oslc-qm:TestResult"/>       
    </domain>

In the linking section, add the relationship types.

CODE

   <!-- OSLC QM Links -->
    <!-- To CM -->
    <link name="oslc_cm:testedByTestCase" reverse="oslc_qm:testsChangeRequest">
      <to type="oslc_qm:TestCase"/>
      <from type="oslc_cm:ChangeRequest"/>
    </link>
    <link name="oslc_cm:blocksTestExecutionRecord" reverse="oslc_qm:blockedByChangeRequest">
      <to type="oslc_qm:TestExecutionRecord"/>
      <from type="oslc_cm:ChangeRequest"/>
    </link>
    <link name="oslc_cm:affectsTestResult" reverse="oslc_qm:affectedByChangeRequest">
      <to type="oslc_qm:TestResult"/>
      <from type="oslc_cm:ChangeRequest"/>
    </link>

    <link name="oslc_cm:relatedTestPlan" reverse="oslc_qm:relatedChangeRequest">
      <to type="oslc_qm:TestPlan"/>
      <from type="oslc_cm:ChangeRequest"/>
    </link>
    <link name="oslc_cm:relatedTestCase" reverse="oslc_qm:relatedChangeRequest">
      <to type="oslc_qm:TestCase"/>
      <from type="oslc_cm:ChangeRequest"/>
    </link>
    <link name="oslc_cm:relatedTestExecutionRecord" reverse="oslc_qm:relatedChangeRequest">
      <to type="oslc_qm:TestExecutionRecord"/>
      <from type="oslc_cm:ChangeRequest"/>
    </link>
    <link name="oslc_cm:relatedTestScript" reverse="oslc_qm:relatedChangeRequest">
      <to type="oslc_qm:TestScript"/>
      <from type="oslc_cm:ChangeRequest"/>
    </link>

    <!-- To RM --> 
    <link name="oslc_qm:validatesRequirementCollection" reverse="oslc_rm:validatedBy">
      <to type="oslc_rm:RequirementCollection"/>
      <from type="oslc_qm:TestPlan"/>
    </link>
    <link name="oslc_qm:validatesRequirement" reverse="oslc_rm:validatedBy">
      <to type="oslc_rm:Requirement"/>
      <from type="oslc_qm:TestCase"/>
    </link>
    <!-- Note, we can currently create Collection relationships where we have singluar relationships -->
    <link name="oslc_qm:validatesRequirement" reverse="oslc_rm:validatedBy">
      <to type="oslc_rm:RequirementCollection"/>
      <from type="oslc_qm:TestCase"/>
    </link>

Now, Polarion will understand QM resources.

Perform your Polarion Mappings

Like in the standard configurations for Jira using Change Management links, users need to update their mappings to support the OSLC Link types.

Users should update the project or global configuration (depending on the desired scope and commonality) to include a mapping of the link types they wish to use. For example the following mapping would be used if there is a Polarion “validates” link type and these are going to be used to link test cases to requirements artifacts.

CODE

    <link-role-mapping linkRole="validates" oslcLinkProperty="oslc_qm:validatesRequirement"/>
    <link-role-mapping linkRole="validates" oslcLinkProperty="oslc_qm:validatesRequirementCollection"/>

Linking to Jira

Once the above configurations are complete, users can link Polarion requirements to Jira Test Cases.

On a Polarion Requirement, edit the Linked Work Items and use the “is validated by” link relation. The Globe showing the “Linked Data Friend Server” allows the selection of the Jira dialog.

The Selection Dialog will allow you to select the artifact of choice (and ensure it is of the desired project and artifact type).

Or if the Creation is selected, a user can create an Xray Test Case from Jira.

Advanced Options

In Polarion, there will be two advanced options that can be leveraged: Reporting and Tables. Users can customize the Reports to include Test Artifacts with the new Resource Types and Shapes. Users can add Test Data to be visible on a requirement artifact with Tables.

An example Report utilizing Xray Test data.

For example, you can create a new section on your requirement artifact to show the remote artifacts including custom Xray Fields such as TestRunStatus.