Share this page

# Issues

Use the Issues module to track, analyze, and manage defects as well as your code security vulnerabilities.

This topic describes how to submit and manage defects. For details on vulnerabilities, see Track security vulnerabilities.

In this topic:

## Report defects

You can submit defects at all stages of your work.

Work area | How
--- | ---
Backlog module | In any of the backlog grids, select + Defect. The new defect is associated with the feature selected in the tree.
Quality module | On the Defects tab, create a new defect. The new defect is associated with the application module selected in the tree.
During a manual test run | Click the Add Run Defects button and select New defect. If there are no defects assigned to this run, clicking Add Run Defects opens the Add Run Defect dialog box. For details, see Report defects during a run. Note: You can report defects on run steps even when the run is completed and the steps are read-only.
In the Tests tab of a pipeline's latest run | In the Pipelines module: Open the pipeline run and select the Test Runs tab. Select one or more automated test runs. Click the New Defect button . The new defect is linked to the selected runs and contains a link to the Tests page of the relevant pipeline run.

Several fields in the new defect form are automatically populated with values from the run and test. For details, see Auto-populated fields.

Back to top

## Auto-populated fields

When you create a new defect from within any type of run (manual, automated, Gherkin auto, suite), several fields from the run and test are automatically populated, such as the Application module, Environment tags, Milestone, and Sprint.

Version 24.1 and earlier: Auto-populate is supported from within the Manual Runner only.

Included in the auto-populated fields are Backlog items, Requirements, and Feature according to these guidelines:

- Backlog items reflecting all open user stories (where the meta phase is not set to Done) linked to the test run.
- All requirements directly linked to the test.
- A feature linked to the test run, provided that the test run is linked directly or indirectly to a single open feature (where the meta phase is not set to Done).

You can accept the automatically populated values or modify them as needed.

Some of the auto-populated fields are hidden by default. To show them, customize the view. The customized fields appear in the More section. For details, seeForms and templates.

For manual and automated runs, in the Report Defect dialog box, you can also click the Copy steps to description or Copy failure details to description button to populate the defect with additional content. For details, see Plan and run manual tests and Analyze automated test run results.

Note:

- If not set, the Release field of a new defect is automatically populated with the Detected in release value when the defect is saved. This behavior is governed by a predefined business rule that can be deactivated by the space admin. For details, see Design business rules.

- Site admins can turn off automatic population for:

  - Backlog items, Requirements, and Feature fields by setting the site parameter LINK_COVERAGE_ENTITIES_TO_RUN_DEFECT to false.

  - Milestone and Sprint fields by setting the site parameter COPY_SPRINT_AND_MILESTONE_FROM_RUN_TO_DEFECT to false.

For details, see Configuration parameters.

Back to top

## Track and analyze defects

Treat defects like any backlog item:

- Follow defects.
- Track defect progress using widgets in the Dashboard module or the Overview tab.
- Link defects to user stories, requirements, test runs, or other defects on the Relations tab.
- Link defects to their covering tests on the Relations tab. The defects are then listed in the tests' Backlog Coverage field.

Back to top

## Assign test coverage to defects

You can track the quality of your fixed defects by analyzing the status of the tests covering the defects.

One test can cover many defects, and one defect can be covered by many tests.

To define test coverage of a defect:

1. You can define a defect's test coverage in the following ways:

   - On the Relations tab of a defect, link the defect to its covering test.

   - On the Relations tab of a test, link the test to its covered defect.

   The covered defect is listed in the test's Backlog Coverage field.

1. You can view a defect's test coverage in the following ways:

   - In the defect's Test Coverage field. The field represents the tests that cover a defect, grouped by their various statuses.

   - In the defect's document view, on the Tests tab. The tab displays all the tests that cover a defect as a list.

     Tip: You can filter defects according to whether or not they have covering tests. Filter for defects where the Covering tests field is empty to see defects without covering tests.

Back to top

## Copy or move a defect to a different workspace

You can copy or move defects from one workspace to another.

Copying a defect to another workspace is useful, for example, if you are dependent on users in other workspaces to handle parts of your defect. You can create a defect for the other users in their workspace, and then verify the fixes before closing the defect in your workspace.

For details, see Copy and move across workspaces.

Back to top

## Additional defect details

There are a number of ways to specify details on a defect, to help you filter and resolve problems.

Specify environments

When you create a defect, specify the environments in which the issue was detected. This helps developers understand which environments were problematic and where to focus their efforts.

Specify environments in the following ways:

- Select environments predefined by your administrator

- Add Environment tags

To select a predefined environment, click the Customize fields button and display the Detected in environments field. Select one or more environments. For details, see Environments.

To specify additional information about the environments in which you detected an issue, open the Environment tags list, and select the relevant tags. If your particular environment is not represented by any of the existing ones, you can add more environment tags. For details, see Environment tags.

Assign a custom subtype and specify the defect's source

The Custom Subtype and Item origin fields are optional.

- Custom Subtype. You can assign a subtype to a defect to help filter according to your needs. The default categories are Security and Performance.

  Tip: You can track the status of security-related defects using the Security Status dashboard. For details, see Dashboard templates.

- Item origin. If you inject defects from Fortify, SonarQube, or OpenText Professional Performance Engineering, you can set the field to show the defect's source application, and then filter by this field.

Back to top

See also:

- Backlog
- Dashboard
- Track security vulnerabilities
- Filters
- Plan and run manual tests

https://admhelp.microfocus.com Software Delivery Management 8942
Tips to improve your search results... OpenText™ Software Delivery Management Help Center OpenText™ Software Delivery Management Help 26.1 All View Local Help Center View Online Help Center Version: