In this section:
Polarion ALM is a popular browser-based platform for managing requirements. Parasoft DTP integrates with Polarion ALM, providing the following functionality:
This section describes requirements for using DTP with Polarion.
DTP does not ship with the JAR files necessary for fully integrating with Polarion due to issues detected during internal testing. If you choose to integrate with Polarion, contact Parasoft ([email protected]) to obtain the JAR files necessary to enable the integration. Copy the files into the <DTP_INSTALL>/DTP/tomcat/webapps/grs/WEB-INF/lib directory and restart DTP (see Stopping DTP Services and Starting DTP Applications).
The <DTP_INSTALL>/DTP/tomcat/webapps/grs/WEB-INF/lib directory is overwritten during the upgrade process, so the JAR files will need to be re-added after upgrading DTP.
The following requirements are only applicable if you are going to send data to Polarion.
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 Polarion ALM.
Associating a Parasoft project with a Polarion project enables you to create defects from the Violations or Test Explorer views that are linked to the correct project in Polarion. 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 Polarion, but you cannot associate the same DTP project with more than one Polarion project.
Click the trash icon to remove a project association. Deleting the project association does not remove links to defects in Polarion from the explorer view. If a new association is created, existing links between violations and Polarion issues will be reactivated.
You can reconfigure an existing association between DTP and Polarion projects:
You can configure DTP to generate widgets and reports that help you demonstrate traceability between the requirements stored in Polarion 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 work items in Polarion. 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 to Polarion as described in the Connecting DTP to Polarion ALM Server section before deploying the artifact.
The first step is to install the Traceability Pack. The artifact is a collection of configuration files and assets that enable traceability.
Deploy the External System Traceability Report after installing the Traceability Pack.
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.
This artifact sends test data to Polarion 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.
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 Polarion is configured to use default or commonly-used fields and work item types. If you customized your Polarion system, however, then you can configure the following settings to align data in DTP with your custom configuration.
| polarion.workItemType.requirementIds | Specifies a comma-separated list of Polarion work item types that should take the role of requirements in Parasoft. The work items are also used in the Traceability Report. Choose Polarion Administration > Work Items > Types for the IDs in the Polarion UI to access the work item IDs in your Polarion system. Default:
|
|---|---|
| polarion.workItemType.testId | Specifies the Polarion work item type that should take the role of tests in Parasoft. Choose Polarion Administration > Work Items > Types for the IDs in the Polarion UI to access the work item IDs in your Polarion system. Default:
|
| polarion.workItemType.issue | Specifies the type of work item to create in Polarion when creating new issues from the DTP Violation Explorer and Test Explorer. This enables you to associate custom issue trackers you may have configured in Polarion with work items created from DTP. By default, the property is not set. As a result, issue work items created in DTP are associated with issue work items in Polarion. |
| polarion.workItem.Type.task | Specifies the type of work item to create in Polarion when creating new tasks from the DTP Violation Explorer and Test Explorer. This enables you to associate custom task trackers you may have configured in Polarion with work items created from DTP. By default, the property is not set. As a result, task work items created in DTP are associated with task work items in Polarion. |
| polarionIssueUrl | Specifies the URL template for linking work items created in the DTP Violation Explorer and Test Explorer to work items in Polarion. Default:
|
| polarion.hyperlinkRole | Specifies the role of hyperlinks as configured in your Polarion system. The hyperlink role is used when creating work items from the DTP Violations Explorer and Test Explorer. Choose Polarion Administration > Enumerations > hyperlink-role-enum.xml in Polarion to access the hyperlink role. Default:
|
polarion.requirementStatus.verified | Specifies the relationship between the tests sent from DTP and the requirements in Polarion. Choose Polarion Administration > Enumerations > workitem-link-role-enum.xml in Polarion to view the current relationship configurations. Default:
|
polarion.testCase.workItemLinkRole= | Specifies IDs of roles which should be treated as "WorkItem-Test" relation types. See Polarion Administration > Enumerations > workitem-link-role-enum.xml in Polarion to view the current relationship configurations. The values should be a list of IDs separated with ",". When field is empty all role types are accepted. Used in Parasoft C/C++ and SOAtest Requirements View to present Polarion test cases associated with Polarion requirements. Default: polarion.testCase.workItemLinkRole=depends_on,verifies,relates_to |
After configuring the integration with Polarion, developers, testers, and other users can leverage the functionality enabled by the integration.
The Test Explorer and Violations Explorer views enable you to create issues and defects for any test and violation, respectively, regardless of status. Refer to the following sections for details on creating Polarion assets in explorer views:
The following diagram shows how you could implement an automated infrastructure for integrating Parasoft DTP and Parasoft test execution tools into your Polarion ALM environment:
@test or @req annotation. See the C/C++test, dotTEST, or Jtest documentation for details on adding annotations.@test <Polarion unit test case ID> annotation in your tests to associate them with Polarion unit test cases. @req <Polarion software/system requirement ID> annotation in your tests to associate them with Polarion software or system requirements. 
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 Polarion 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 to send results from the DTP database to Polarion. 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:
filterId and buildId parameters and send the data to the Polarion unit test cases or requirements. You should expect the following response:When DTP locates results with an @test <ID>, it will search for unit test cases with a matching ID in Polarion and update the item. No action will be taken if the unit test case IDs do not exist in Polarion.
When DTP locates results with an @req <ID>, it will search for requirements with a matching ID in Polarion and update associated children unit test cases. If no unit test cases exist for the requirement IDs, unit test cases will be created. Unit test cases will also be created if the requirement IDs are not found.
After DTP processes the report and sends results to Polarion, 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"
]
} |
If you are using the Sending Test Data to External System flow to forward unit and functional test results, data will be sent to Polarion 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 Polarion IDs. You can configure the flow, however, to only send data for a specific project.
Double-click the node and specify the following string in the Property field:
event.message.resultsSession.project |
When the flow executes, only test results for the specified DTP project will be sent to Polarion.
After successfully sending the test data to Polarion, you will be able to view results in Polarion.
You can drill down into Polarion reports to view additional details about the tests, including authorship, location, and execution time. Refer to the Polarion documentation for details about understanding reports in Polarion.
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.
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:
| Title | You can enter a new title to replace the default title that appears on the dashboard. |
|---|---|
| Filter | Choose 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 Build | This 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. |
| Type | Pie 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. |
| Project | Choose a Polarion project from the drop-down menu. |
This widget shows the number of requirements from the specified Polarion project.
Click on the widget to open the Requirement Traceability report.
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.
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 the selected type.
The report lists the Polarion project requirements and data associated with them.
You can perform the following actions:
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.
The Requirement Details report provides additional information about the files, static analysis findings, and tests associated with a specific Polarion requirement. You can open this report by clicking on a requirement in the main 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 violations 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 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 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.