In this section:

Introduction

If your organization tracks and manages software development projects in Jira, you can connect DTP to your Jira system in the administration page. Connecting DTP to Jira provides the following functionality:

  • Ability to manually create a Jira issue from the Violations Explorer view.
  • Ability to manually create a Jira issue from the Test Explorer view.
  • If you are using the Xray plug-in for Jira, you can also send, view, and update Parasoft Test results in Jira (see Sending Test Data to Jira/Xray)
    • For users who plan to track traceability using traceability reports in Jira. In order to do this, you need to first send test results from Parasoft DTP to Jira.
  • Traceability from Jira requirements to tests, static analysis results, and code reviews (see Viewing the Traceability Report). 
    • For users who plan to track traceability using traceability reports in Parasoft DTP. In order to do this, use @req to associate your automated tests in Parasoft to Jira requirements.

Requirements

The following requirements are only applicable if you are going to send test results to Jira:

  • Tests executed by the following Parasoft tools are supported:
    • C/C++test Professional, dotTEST, or Jtest 10.4.3 +
    • Selenic 2020.1 +
    • SOAtest 9.10.8 +
  • Xray plug-in

Configuration

The configuration is performed by the Parasoft administrator and only needs to be set up once. Developers, testers, and other DTP end users should review the Usage section for instructions on how to use Parasoft with Jira.

Connecting DTP to Jira

  1. Choose Report Center Settings from the settings (gear icon) drop-down menu.
  2. Choose External System, click Edit Settings, and choose Jira from the System type drop-down menu.
  3. Enable the Enabled option.
  4. Enter a name for the server in the Name field. The name is required but does not affect the connection settings or render in any other interfaces.
  5. Enter the URL of your Jira system in the Application URL field. The URL should include the protocol, host, and port number, e.g., http://jira.yourcompany.com:8080Do not include paths or parameters.
  6. The Display URL field defines the URL which is displayed in Parasoft DTP pages when links to your Jira system are presented in a web browser. Typically, this should be the same as the above Application URL field. However, it might be different, for example, when you work in a reverse proxy environment and links to Jira from the user's local web browser with Parasoft DTP are different than from the Parasoft DTP server,  e.g., http://jira.yourcompany.com.
  7. Enter your username and either a password (self-managed Jira server) or an API token (Jira Cloud) in the appropriate fields. The login must have sufficient privileges to create Jira issues in the projects specified in the Project Associations section. 
  8. (Optional) You can enter a JQL query to filter the Jira requirements presented in Parasoft IDE plug-ins and Jira traceability reports. The JQL query applies to requirements in Jira projects that have been associated with DTP projects (see Associating Parasoft Projects with Jira) and to requirements that have been customized with the jira.issueType.requirement setting (see Advanced Configuration). This query will be overwritten by any JQL queries defined in the Jira dashboard widgets (see Adding and Configuring the Widgets).    
  9. Click Test Connection to verify your settings and click Confirm.

Connecting to Xray Cloud

Xray is an extension for Jira that manages tests. Xray is available as a hosted or cloud-based application. DTP can send data to hosted instances of Xray through the connection as described in Connecting DTP to Jira. For cloud-based instances of Xray, enable the Xray (Cloud) enabled option and specify the Xray client ID and secret so that you can leverage the functionality described in the Sending results from DTP to JIRA/Xray section.

Refer to the Xray documentation for information about generating client IDs and secrets: https://docs.getxray.app/display/XRAYCLOUD/Global+Settings%3A+API+Keys

Associating Parasoft Projects with Jira

Associating a Parasoft project with a Jira project enables you to create defects from the Violations or Test Explorer views that are linked to the correct project in Jira. The association is also important when using the the Sending Test Data to External System flow. You can associate multiple projects in DTP with a project in Jira, but you cannot associate the same DTP project with more than one Jira project.

  1. Click Create Project Association and choose a project from the DTP Project drop-down menu in the overlay. 
  2. Enter the name of a Jira project in the External Project field and click Create to save the association.

Click the trash icon to remove a project association. Deleting the project association does not remove links in DTP explorer views to defects in Jira. If an association is deleted and recreated later, existing links between violations and Jira issues will be reactivated. 

You can reconfigure an existing association between DTP and Jira projects:

  1. Click the pencil icon and choose either a different DTP project from the drop-down menu or specify the name of a different Jira project in the External Project field.
  2. Click Save

Enabling the Requirements Traceability Report

You can configure DTP to generate widgets and reports that help you demonstrate traceability between the requirements stored in Jira and the test, static analysis, and build review data sent to DTP from Parasoft tools (C/C++test, dotTEST, Jtest, SOAtest).

If you want the Traceability Report to include code review and static analysis information, you must associate your source code files with stories in Jira. See Associating Requirements with Files for instructions on enabling this optional feature.

DTP interfaces that display and track traceability are enabled by deploying the External System Traceability Report artifact shipped with the Traceability Pack. The Traceability Pack also includes the Sending Test Data to External System flow, which automates part of the requirements traceability workflow. Refer to the Traceability Pack documentation for additional information about the pack.

Use DTP Extension Designer to deploy the External System Traceability Report and the Sending Test Data to External System flow to your environment. Verify that DTP is connected Jira as described in Connecting DTP to Jira before deploying the artifact. 

Installing the Traceability Pack

The first step is to install the Traceability Pack artifact. The artifact is a collection of configuration files and assets that enable traceability.

  1. Choose Extension Designer from the settings menu (gear icon). 
  2. Click the Configuration tab to open Artifact Manager.
  3. Click Upload Artifact and browse for the traceability-pack-<version>.zip archive (also see Downloading and Installing Artifacts).
  4. Click Install and a collection of assets and configuration files for enabling traceability will be installed.

Deploying the Traceability Report

Deploy the report components to your DTP environment after installing the External System Traceability Report artifact.

  1. Open Extension Designer and click on the Services tab.
  2. Choose an existing service to deploy the artifact or create a new service in the DTP Workflows category. Refer to Working with Services for additional information on organizing services and artifacts.
  3. If you are adding the artifact to an existing service, add a new Flow tab (see Working with Flows) and choose Import from the ellipses menu.
  4. Choose Local> Flows> Workflows> Traceability Pack> External System Traceability Report and click Import.
  5. Click inside the Flow tab to drop the nodes into the service and click Deploy

Deploying the External System Traceability Report adds new widgets to Report Center, as well as a drill-down report. See Viewing the Traceability Report for instructions on adding the widgets and viewing the report.

Deploying the Sending Test Data to External System Flow

This artifact sends test data to Jira when DTP Data Collector retrieves test results from a Parasoft tool. This artifact ships with the Traceability Pack, which must be installed as described in Installing the Traceability Pack before deploying the flow. 

  1. Open Extension Designer and click on the Services tab.
  2. Choose an existing service to deploy the artifact or create a new service in the DTP Workflows category. Refer to Working with Services for additional information on organizing services and artifacts.
  3. If you are adding the artifact to an existing service, add a new Flow tab (see Working with Flows) and choose Import from the ellipses menu.
  4. Choose Library> Workflows> Traceability Pack> Sending Test Data to External System and click Import.
  5. Click inside the Flow tab to drop the nodes into the service and click Deploy

Advanced Configuration

You can modify the ExternalSystemSettings.properties configuration file located in the <DTP_DATA_DIR>/conf directory to change the default behavior of the integration. DTP's out-of-the-box integration with Jira/Xray is configured to use default or commonly used fields and types. If you customized your Jira/Xray system, however, then you can configure the following settings to align data in DTP with your custom Jira/Xray configuration.  

jiraIssueUrl

Specifies the URL template for linking work items created in the DTP Violation Explorer and Test Explorer to work items in Jira.

Default:

JiraIssueUrl=<JIRA_URL>/browse/<ID> 

The value of the <JIRA_URL> segment of the URL path is specified when connecting DTP to Jira. See Connecting DTP to Jira.

jira.issueType.bug

Specifies the name for the issue type in Jira that takes the role of bugs when creating work items from the DTP Violations Explorer and Test Explorer.

By default, the property is not set. As a result, bug work items created in DTP are associated with bug work items in Jira.

jira.issueType.task

Specifies the name for the issue type in Jira that takes the role of tasks when creating work items from the DTP Violations Explorer and Test Explorer.

By default, the property is not set. As a result, task work items created in DTP are associated with task work items in Jira.

jira.issueType.test

Specifies the name for the issue type in Jira that takes the role of tests. When test results are sent from DTP to Jira/Xray, tests will be labeled as the issue type specified in this setting.

Default:

jira.issueType.test=Test 

This setting can be used in on-premise and cloud-based instances of Jira/Xray.

jira.issueType.requirement

Specifies the entity type in Jira that DTP treats as requirements. DTP will present Jira entities specified with this setting in traceability widgets and reports. When sending test results from DTP to Jira/Xray, DTP will update or create test cases for the entities specified with this setting that match the IDs specified with the @req annotation. 

Default: 

jira.issueType.requirement=Story 

This setting can be used in on-premise and cloud-based instances of Jira/Xray.

jira.testDone.transitionId

Specifies a custom status for tests sent from DTP to Jira/Xray. If not specified, the default system status for completed tests is used.

See Getting Default Test and Test Execution Statuses for information about getting the default test status names used in your system.

jira.testExecutionDone.transitionId

Specifies a custom status for test executions sent from DTP to Jira/Xray. If not specified, the default system status for test executions is used.

See Getting Default Test and Test Execution Statuses for information about getting the test execution status names used in your system.

jira.testType.customfieldId

Specifies the ID of the test type custom field in your Jira/Xray system. The value should match the existing custom field. Tests will be labeled according to the type specified with the jira.testType.customfieldValue setting. 

Both the jira.testType.customfieldId  and jira.testType.customfieldValue settings must be configured to specify a custom value. 

By default, both jira.testType.customfieldId and jira.testType.customfieldValue settings are not configured. As a result, the default test type value is used

See Getting Values for Custom Test Type Fields for additional details.

This setting can be used in on-premise and cloud-based instances of Jira/Xray.

jira.testType.customfieldValue

Specifies which test type is assigned to tests created when results are sent from DTP to Jira/Xray. The value should match the existing custom field in your Jira/Xray system. The custom value is identified by the ID specified in with the jira.testType.customfieldId setting.

Both the jira.testType.customfieldId  and jira.testType.customfieldValue settings must be configured to specify a custom value. If only the jira.testType.customfieldId  or jira.testType.customfieldValue settings are configured, will result in an error.

By default, both jira.testType.customfieldId and jira.testType.customfieldValue settings are not configured. As a result, the default test type value is used. 

See Getting Values for Custom Test Type Fields for additional details. 

This setting can be used in on-premise and cloud-based instances of Jira/Xray.

jira.xrayOnPremises.testCaseFindingStatus.pass

Specifies the test run status name in Jira/Xray to assign to passing test results sent from DTP. This enables you to set custom statuses you may have configured in Jira for test results in DTP.

Default:

jira.xrayOnPremises.testCaseFindingStatus.pass=PASS 

This setting can be used in on-premise instances of Jira/Xray.

jira.xrayOnPremises.testCaseFindingStatus.fail

Specifies the test run status name in Jira/Xray to assign to failed test results sent from DTP. This enables you to set custom statuses you may have configured in Jira for test results in DTP.

Default:

jira.xrayOnPremises.testCaseFindingStatus.fail=FAIL 

This setting can be used in on-premise instances of Jira/Xray.

jira.xrayOnPremises.testCaseFindingStatus.incomplete

Specifies the test run status name in Jira/Xray to assign to passing test results sent from DTP. This enables you to set custom statuses you may have configured in Jira for test results in DTP.

Default:

jira.xrayOnPremises.testCaseFindingStatus.incomplete=ABORTED 

This setting can be used in on-premise instances of Jira/Xray.

jira.xrayOnPremises.testToRequirementRelationName

Specifies the name of the requirement type in Jira for tests sent from DTP. This enables you to associate tests with requirements using a custom name you may have configured in Jira. 

Default:

jira.xrayOnPremises.testToRequirementRelationName=Tests 

This setting can be used in on-premise instances of Jira/Xray.

jira.xrayCloud.testCaseFindingStatus.pass

Specifies the test run status name in Jira/Xray to assign to passing test results sent from DTP. This enables you to set custom statuses you may have configured in Jira for test results in DTP.

Default:

jira.xrayCloud.testCaseFindingStatus.pass=PASS 

This setting can be used in Cloud instances of Jira/Xray.

jira.xrayCloud.testCaseFindingStatus.fail

Specifies the test run status name in Jira/Xray to assign to passing test results sent from DTP. This enables you to set custom statuses you may have configured in Jira for test results in DTP.

Default:

jira.xrayCloud.testCaseFindingStatus.fail=FAIL 

This setting can be used in Cloud instances of Jira/Xray.

jira.xrayCloud.testCaseFindingStatus.incomplete

Specifies the test run status name in Jira/Xray to assign to passing test results sent from DTP. This enables you to set custom statuses you may have configured in Jira for test results in DTP.

Default:

jira.xrayCloud.testCaseFindingStatus.incomplete=ABORTED 

This setting can be used in Cloud instances of Jira/Xray.

jira.xrayCloud.testToRequirementRelationName

Specifies the name of the requirement type in Jira for tests sent from DTP. This enables you to associate tests with requirements using a custom name you may have configured in Jira. 

Default:

jira.xrayCloud.testToRequirementRelationName=Test 

This setting can be used in Cloud instances of Jira/Xray.

Getting Values for Custom Test Type Fields

The jira.testType.customfieldId  and jira.testType.customfieldValue settings are used to specify a custom type for tests sent to Jira/Xray from DTP. The jira.testType.customfieldId setting identities the name of the field for the custom type, and the jira.testType.customfieldValue setting identifies the specific value. Both values must exist in your Jira/Xray system.

To get the value for the jira.testType.customfieldId  setting:

  1. Send a GET request to the following endpoint to get the value of the custom field: 

    curl -X GET "http(s)://<jira-host>/rest/api/2/field"
  2. Locate the custom field object with the Test Type property in the response:
  3. Set the jira.testType.customfieldId setting to the id property:
jira.testType.customfieldId=customfield_10800

To get the value for the jira.testType.customfieldValue setting:

  1. Log into your Jira system and click Create in the Jira toolbar.
  2. Choose Test (or equivalent) from the Issue Type drop-down menu and click Test Details.
  3. Open the Test Type drop-down menu and copy the type that you want to use for tests sent from DTP.

     
  4. Set the jira.testType.customfieldValue property to the test type value:
jira.testType.customfieldValue=Automated[Generic]

Save the ExternalAppsSettings.properties configuration file to apply the changes.

Getting Default Test and Test Execution Statuses

The jira.testDone.transitiondId and jira.testExecutionDone.transitionId settings are used to specify a custom status for tests and test executions sent to Jira/Xray from DTP. You can use the Jira REST API to get the status names to use in the ExternalAppsSettings.properties file so that the data sent from DTP matches the existing entities in Jira.

Send a request to the following Jira transitions endpoint and specify the Jira test ID to determine the correct value for jira.testDone.transitiondId setting:

curl -X GET "http(s)://<jira_host>/rest/api/2/issue/<testId>/transitions" 

The ID, as well as the status name, will appear in the response:

Specifying the ID in the ExternalAppsSettings.properties file:

jira.testDone.transitiondId=41

Send a request to the following Jira transitions endpoint and specify the Jira test execution ID to determine the correct value fo ther jira.testExecutionDone.transitiondId setting: 

curl -X GET "http(s)://<jira_host>/rest/api/2/issue/<testExecutionId>/transitions" 

The ID, as well as the status name, will appear in the response:

Specifying the ID in the ExternalAppsSettings.properties file:

jira.testExecutionDone.transitiondId=31

Usage

After configuring the integration with Jira, developers, testers, and other users can leverage the functionality enabled by the integration.

Manually Creating Bugs and Tasks in Jira

The Test Explorer and Violations Explorer views enable you to create bugs and tasks for any test and violation, respectively, regardless of status. Refer to the following sections for details on creating Jira assets in explorer views:

Sending Test Data to Jira/Xray 

The following diagram shows how you could implement an automated infrastructure for integrating Parasoft DTP and Parasoft test execution tools into your Jira environment:

  1. Create tests and/or stories in Jira. The items will be associated with tests executed by Parasoft C/C++test, dotTEST, or Jtest. 
  2. In your test file, add the Jira test or story IDs using the @test or @req annotation. See the C/C++test, dotTEST, or Jtest documentation for details on how to add annotations. 
    • Use the @test <Jira Test ID> annotation to associate tests with test executions in Jira.
    • Use the @req <Jira Story ID> annotation to associate tests with stories in Jira
    • The Jira work item ID is available in several Jira interfaces, such as the URL:
  3. Execute your tests as part of the CI process. You can also manually execute the tests from the IDE.
  4. As part of the test execution, Parasoft test execution tools will tag the results with the filter and build IDs and send the data to DTP. You can verify the results in DTP by adding Test Widgets to your DTP dashboard and setting the filter and build ID. Developers can download the test execution data from DTP into their IDEs so that they can address any failed tests.
  5. If you deployed the Sending Test Data to External System flow (see Deploying the Sending Test Data to External System Flow), then unit and functional testing results will automatically be sent to Jira when Data Collector receives the data from the Parasoft tool. By default, the flow forwards unit and functional test results that were received by Data Collector for any project, but you can configure the flow to only send data for a specific project (see Sending Results from a Specific DTP Project). You can also manually send a POST request to the DTP REST API endpoint in order to send results from the DTP database to Jira (see Manually Send a POST Request to the DTP REST API Endpoint).

  6. DTP will locate the test results that match the filterId and buildId parameters and send the data to the items in Jira.
    • When DTP locates results with an @test <ID>, it will search for and update tests with a matching ID in Jira. No action will be taken if the IDs do not exist in Jira.
    • When DTP locates results with an @req <ID>, it will search for Jira stories with a matching ID and add test executions to the story. If the ID does not exist, new test executions will be added to Jira. 
    • An external-app-sync.log file will also be written to the the <DTP_INSTALL>/logs directory. This log file contains progress information about sending test results from DTP to Jira. 

After DTP processes the report and sends results to Jira, you should expect a response similar to the following:

{
   "createdTestSession": "DTPP-521",
     "created": [
        "DTPP-519, testName = testBagSumAdd"
     ],
     "updated": [
        "DTPP-519, testName = testBagSumAdd",
        "DTPP-518, testName = testBagSimpleAdd"
     ],
     "ignored": [
        "MAGD-567, testName = testBagNegate",
        "QAP-512, testName = testTryThis3",
        "QAP-512, testName = testTryThis4",
        "MAGD-567, testName = testBagMultiply"
     ]
}

Manually Sending a POST Request to the DTP REST API Endpoint 

The Sending Test Data to External System Flow shipped with the Traceability Pack will automatically send data from DTP to Jira when new results are collected in DTP (see Deploying the Sending Test Data to External System Flow). Alternatively, you can send a POST request to the DTP REST API endpoint to start this action (refer to syncTestCases Endpoint Reference for details about the endpoint).

Pass the DTP filter and build IDs as URL parameters in the API call:

curl -X POST -u <username>:<password> "http://<host>:<port>/grs/api/v1.7/linkedApps/configurations/1/syncTestCases?filterId=<filterID>&buildId=<buildID>"

The filter and build IDs are available in the Test Explorer URL:

If you are using the Jira Xray traceability report (in addition to, or instead of, the Parasoft traceability report), the test information sent to Jira must include the Fix Version field. By default, the DTP API does not populate the Fix Version field when it creates test execution entities in Jira,
but you can add the fixVersions parameter to your API and specify one or more values to populate the field:

curl -X POST "https://<host>:<port>/grs/api/v1.7/linkedApps/configurations/1/syncTestCases?filterId=<filterID>&buildId=<buildID>&fixVersions=<version1>,<version2>"

You must also first enable the Version field in your Jira project to use the fixVersions parameter. The value of the parameter must match the version specified in your Jira project. In the following example, tests would be updated for fixVersions=1.0

Refer to the Jira documentation for information about configuring versions.

syncTestCases Endpoint Reference

The syncTestCases endpoint sends test data that has been reported to DTP to the integrated ALM system.

Resource/syncTestCases
URL<protocol>://<host>:<port>/grs/api/v1.7/linkedApps/configurations/1/syncTestCases

Method

POST

The following table describes the endpoint parameters.

ParameterValueDescriptionRequired
filterId integerSpecifies the filter ID containing the test data. The filter ID is an integer value and should not be confused with the filter name.Required
buildId stringSpecifies the build ID containing the test data.Required
fixVersion comma-separated list of string stringSpecifies a value for populating the Fix Version field in Jira. The Fix Version field is a necessary field for using Jira's traceability reports.   Optional
groupResultsBySOAtestTST boolean

Setting to true groups SOAtest results by .tst file. As a result, one .tst file will be associated with one Xray test.

Setting to false associates each test step within a SOAtest .tst with an Xray test.

Default is false 

See Changing Test Granularity for SOAtest Results for additional information. 

Optional

Changing Test Granularity for SOAtest Results

SOAtest offers the flexibility to implement several testing strategies, such as:

  • creating a limited set of .tst files that contain many test steps,
  • creating many .tst files with a limited number of test steps, or
  • a combination/balance of the above strategies.

By default, each test step in a SOAtest .tst file is associated with an Xray test. This configuration may be too granular for your organization, however, if the functional tests are spread across many .tst files. You can change the default behavior by adding groupResultsBySOAtestTST=true to the syncTestCases endpoint call, e.g.:

curl -X POST "https://<host>:<port>/grs/api/v1.7/linkedApps/configurations/1/syncTestCases?filterId=<filterID>&buildId=<buildID>&groupResultsBySOAtestTST=true"

If you deployed the Sending Test Data to External Systems flow, you can add the parameter to the linkedApps - syncTestCases node to enable grouping by .tst file:

Sending Results from a Specific DTP Project

If you are using the Sending Test Data to External System flow to forward unit and functional test results, data will be sent to Jira for all DTP projects by default. As a result, work items will be updated to include the tests collected for any DTP project that contain annotations matching Jira IDs. You can configure the flow, however, to only send data for a specific project. 

  1. Open Extension Designer and open the service where the Sending Test Data is deployed.
  2. Drag a new switch node to the workspace.
  3. Select and delete the connector line between the "DataCollectorProcessedEvent" node and the "Is dynamic analysis" node.
  4. Drag a new connector from the "DataCollectorProcessedEvent" node to the switch node and from the switch node to the "Is dynamic analysis" node.
     
  5. Double-click the node and specify the following string in the Property field:

     event.message.resultsSession.project
  6. Specify the name of the DTP project in the string field.
  7. (Optional) Provide a more descriptive name for the node.
  8. Click Done to finish configuring the node and click Deploy.

When the flow executes, only test results for the specified DTP project will be sent to Jira. 

Viewing Results in Jira and Xray

You will be able to view results in Jira after sending the test data. The following image shows a Jira story that contains several tests.

You can click on a test associated with the story to view additional details.

You can also drill into test executions associated with the test.

Viewing the Traceability Report 

If the External System Traceability Report has been deployed to your system (see Enabling the Requirements Traceability Report), you can add widgets to your dashboard to monitor traceability from requirements to tests, static analysis, code reviews for your project. The widgets also drill down to a report that includes additional details.

Adding and Configuring the Widgets

The widgets will appear in a separate Traceability category when adding widgets to your DTP dashboard. See Adding Widgets for general instructions on adding widgets.

You can configure the following settings:

TitleYou can enter a new title to replace the default title that appears on the dashboard.
FilterChoose Dashboard Settings to use the dashboard filter or choose a filter from the drop-down menu. See Creating and Managing Filters for additional information about filters.
Target BuildThis should be set to the build ID you executed the tests and code analysis under. You can use the build specified in the dashboard settings, the latest build, or a specific build from the drop-down menu. Also see Configuring Dashboard Settings.
TypePie widget only. Choose either a Tests, Violations, or Reviews from the drop-down menu to show a pie chart detailing the status by type. Add instances of the widget configured to each type for a complete overview in your dashboard.
Jira ProjectChoose a Jira project from the drop-down menu.
JQL Query

Specify a query to define which work items are presented in the widget. If left blank, the JQL specified in the integration settings will be applied (see Connecting DTP to Jira). Queries defined in this field override the JQL configured in the integration settings.

If a JQL is specified, it will appear in the header of the Requirement Traceability report.

Requirements Widget

The widget shows the number of requirements from the specified Jira project.

Click on the widget to open the Requirement Traceability report.

Test Coverage Widget

This widget shows the percentage of requirements covered by tests against all requirements in the project.

Click the center of the widget to open the main Requirement Traceability report.

The colored-in segment represents the requirements covered by tests. Click on the segment to open the Requirement Traceability report filtered to the With Tests category.

Pie Widget

Unit testing, functional testing, static analysis, and peer reviews are common activities for verifying that requirements have been properly and thoroughly implemented. This widget shows the overall status of the project requirements in the context of those software quality activities. You can add a widget for each type of quality activity (tests, static analysis violations, reviews) to monitor the progress of requirements implementation for the project.

Mouse over a section of the chart to view details about quality activity type status. Click on the widget to open the Requirement Traceability report filtered by that type.

Requirements Implementation Status by Tests

Requirements Implementation Status by Violations

Requirements Implementation by Reviews

Understanding the Requirement Traceability Report

The report lists the JIRA requirements and data associated with them. 

You can perform the following actions:

  • Disable or enable the Show files/reviews option if you want to hide the Files and Reviews columns in the report. The Files and Reviews columns will only contain data if the requirements have been mapped to source files files (see Enabling the Requirements Traceability Report). Disabling the Files and Reviews columns on this screen hides the related tabs in the Requirement Details report.  
  • Click on a link in the Key column to view the Requirement Details report for the requirement.
  • Click on a link in the Summary column or one of the Test columns to view the test-related information associated with the requirement in
  • the Requirement Details report.
  • Click on a link in one of the Files columns to view the static analysis-related information associated with the requirement in the Requirement Details report.
  • Click on a link in one of the Reviews columns to view the change review-related information associated with the requirement inthe Requirement Details report.

Requirement Traceability Report by Type

Clicking on a section of the Requirements - Pie widget opens a version of the report that includes only the quality activity type selected in the widget. You can use the drop-down menus to switch type and status. You can also disable or enable the Show files/reviews option if you want to hide the Files and Reviews columns in the report. The Files and Reviews columns will only contain data if the requirements have been mapped to source files files (see Enabling the Requirements Traceability Report). Disabling the Files and Reviews columns on this screen hides the related tabs in the Requirement Details report

Understanding the Requirement details Report

The Requirement Details report provides additional information about the files and tests associated with the Jira requirement. You can open this report by click on a requirement in the Requirement Traceability report.

The first tab shows the results of the tests that were executed to verify the specific work item.

You can click on the View results in Test Explorer link to view all of the tests associated with the requirement in the Test Explorer

You can also click on individual test names in the table to view each test in the Test Explorer.

The second tab shows the files associated with the specific requirement, as well as the static analysis violation detected in the files. You can click the link the Violations column to view the violations in the Violations Explorer, which provides additional details about the violations.

This tab will only contain data if the requirements have been mapped to source files (see Enabling the Requirements Traceability Report). If you did not map requirements to files, you can hide this tab by disabling the Show files/reviews option on the main traceability report page and reloading the details report.

If the files include any change reviews or review findings, they will be shown in the third tab with links to view them in the Change Explorer.

This tab will only contain data if the requirements have been mapped to source files (see Enabling the Requirements Traceability Report). If you did not map requirements to files, you can hide this tab by disabling the Show files/reviews option on the main traceability report page and reloading the details report.

  • No labels