...
The Test Explorer provides detailed information about unit and functional tests, such as test traces, history of runs, and coverage information. Click on a unit or functional test widget from the Report Center dashboard to access the Test Explorer (see Widgets). You can also access the test explorer from the Coverage Explorer (see Coverage Explorer#Viewing Test Information). The test explorer is divided into four panels:
- Search panel ; see - see Using the Search Panel.
- Search results table ; - see Viewing Search Results.
- Source panel ; - see Viewing Source Code.
- Actions panel ; - see Resolving Test Failures.
Using the Search Panel
The most common workflow is to open the Test Explorer by clicking on a test-related widget in your DTP dashboard, which will populate based on the parameters configured in the widget. You can also modify the search parameters to hone home in on specific parameters.
...
Filter Target Build | A filter and build ID are the minimum criteria for searching tests. By default, the latest build selected when you change the filter, but you can choose a different build from the drop-down menu. See the following sections for additional information:
|
|---|---|
Baseline Build State | A baseline build is any historical build used for comparison with another build. Choose a baseline build from the drop-down menu to search for tests reported from the baseline build to the build selected with the filter. You can search for tests with the following states:
|
| Status | You can search for tests based on the following statuses:
|
| Coverage Image | If one or more coverage images have been configured for the filter, you can choose an image from the drop-down menu to search for tests that have coverage associated with the tests. A coverage image is a unique identifier used to aggregate coverage data from runs with the same build ID. See DTP Concepts for additional information about coverage images. |
| Analysis Type | You can choose one or more of the following test types to include in the search:
|
| Test Environment | You can specify a test environment tag to search for tests that were executed in a specify environment (also see Viewing Tests Executed in Different Environments). Refer to the test execution tool documentation for details about configuring test environment tags. |
| Priority | You can choose one or more of the following priority levels to include in the search:
You can use the REST API to customize priorities. |
Include File Pattern Exclude File Pattern | You can specify Ant-style patterns to narrow or broaden the scope of your search. See Using File Patterns in DTP for more information about configuring file patterns. |
| Risk/Impact | You can search by one or more risk/impact values. Risk/impact is the extent to which a test impacts the business. Risk/impact can be customized through the REST API. |
| Reference Number | You can constrict your search to a specific reference number. Reference numbers can be added manually or automated through the REST API. |
| Author | You can search by one or more code authors. Authorship is determined from the settings in the code analysis tool. |
| Action | You can search by one or more assigned actions. Actions can be customized through the REST API. |
| Assignee | You can search by one or more assignees. |
| Artifact | If DTP is integrated with a third-party ALM system and you have deployed the Traceability Pack your environment, you will be able to access a traceability report that links tests sent to DTP with work items tracked in the ALM system. Clicking on a link to the Test Explorer from the traceability report will include the artifact (work item) ID as a search parameter. The ID only appears for informational purposes. The field will not appear unless the specific traceability path has been taken. You can clear the ID in this field, but you can not cannot use it to search for tests based on artifact ID. See Integrating with ALM ToolsExternal Systems and Traceability Pack for details. |
| Limit | Specify a limit to the number of tests returned by the search. |
...
- Click on a row to view additional information in the actions panel; see Resolving Test Failures.
- Click on a column header to sort results.
- Click and drag a column header to the area labeled Drag a column header and drop it here to group by that column to create grouped views of the search results. By default, the table is grouped by test file name.
...
Click on the Prioritization tab to access several actions to help you remediate unit and functional test failures.
You can perform the following actions:
- Add comments.
- Assign a user by entering a user name username in the the Assigned To field.
- Set the priority by choosing an option from the Priority drop-down menu.
- Define an action for the assignee by choosing an option from the Action drop-down menu.
- Actions are strings of metadata that you can use to define how you choose to remediate test failures. DTP ships with set of predefined actions: None, Fix, Reassign, Review, Suppress, and Other. You can edit or remove the predefined action types (except for the None type) using the API. For details on configuring actions, choose go to Help > API Documentation from the Help drop-down menu in the Report Center navigation bar.
- Associate a business risk or impact to the test by choosing an option in the Risk/Impact drop-down menu.
- Assign a due data by entering a date in the Due Date field or by using the date picker.
- Assign a reference number to the test be entering a value in the Reference # field.
Click Apply to save the test metadata.
...
| Info | ||
|---|---|---|
| ||
Users must have permissions to set unit and functional test metadata (prioritize), as well as view sources. Permission can be granted for all tests or limited to tests owned by the user. The following table describes a project membership scenario and how permissions may be assigned (see Built-in Permissions and Groups for additional information): |
| Excerpt Include+ | ||||
|---|---|---|---|---|
| scrollEditorUrl | /display/DTPDEVEL/.Violations+Explorer+v2020.1 | scrollEditorDisplayTitle | Violations Explorer||
|
| Anchor | ||||
|---|---|---|---|---|
|
...
The integration enables you to create issues in the connected ALM system from tests in the Prioritization panel.
- Select a test in the search results area and click the Prioritization tab in the actions panel.
- Click the Create button and specify information about the work item you are creating:
Scroll Table Layout sortDirection ASC repeatTableHeaders default widths 40%,60% sortByColumn 1 sortEnabled false cellHighlighting true Project The name of the ALM project in which the new issue will be created appears in the Project field. The association between a DTP project and the external ALM project is defined by your DTP administrator. See the following sections for details:
Type Choose the type of item to create from the drop-down menu. Terminology varies across ALMs, but DTP supports the following types of work items by default:
- For codeBeamer and Azure DevOps, Jira, choose or Codebeamer, choose Bug or Task.
- For Jama Connect, choose Defect.
- For Polarion ALM, choose Issue or Task.
Title/Summary By default, the test name is prepended with "Review Test" and used as the summary, but you can make any necessary changes. Description This field populates the description field in the third-party system. It will include a link back to DTP based on the Display URL field setting in the External Application configuration page. - Click Create.
An issue will be created in your external system that links back to the test in DTP. Additionally, a link to the issue will appear in the Prioritization tab, create a bi-directional path between DTP and your external system.
Unlinking a Created Issue
Once an issue has been created, it will be linked to the violation. You can unlink the issue from the violation by clicking the "X" icon beside it.
Only the link will be removed; the issue in the third-party system will not be affected.
Modification History Tab
Click on the Modification History tab to show when test metadata was updated.
...
Click on the Test History tab to show when tests were ran run and the status of each run. You can click on a column header to sort the contents of the table.
...
The failed test is highlighted in the source panel. The messages associated with the test failure appear in the Traces tab.
Click the Show Traffic button for the desired message to view the data requested during the test and the application’s response.
...
Click on a disclosure triangle to navigate the tree. When When an item is loaded that does not have any siblings, its children are automatically loaded and displayed. This behavior will cascade until the tree reaches a branch with multiple items at the same level (a decision point) or until the branch cannot be expanded any further. The coverage tree panel will panel will not automatically expand nodes again if it has been previously expanded and collapsed unless the search criteria has changed, or the page has been reloaded.
- Click on file nodes to view it in the source code panel; see . See Viewing Source Code for more information.
Details Tab
Click the Details tab to view information about the test.
...
Clicking on links in the Traces tab also loads sources into the sources panel. Lines of code where the fail failure occurred are flagged so you can easily find the test in the trace stack.
...