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.
Inside a story or test (after the test ran) | On the Details tab of a user story, quality story, or test, click Report defect . The defect is associated with the current item's feature.
During a manual test run | Click Test Defects > Add new defect . If there are no defects assigned to this run, clicking Test Defects opens the Add Run Defect dialog box. For details, see Report defects during a run.
In the Tests tab of a pipeline's latest run | In the Pipelines module: Open the pipeline run and select the Tests tab. Select one or more automated test runs. Click Report defect . 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, see Forms 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 Run manual and Gherkin 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, do one of the following:

- 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.

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 items to another workspace.

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.

Environment

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

You can specify environments in the following ways:

- Select environments predefined by your administrator

- Add Environment tags

To select a predefined environment, click the Choose Columns button to 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, expand the Environment tags dropdown, 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.

Custom Subtype and Item origin

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.

- Item origin. If you inject defects from Fortify, SonarQube, or LoadRunner, you can set the Origin 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
- Run manual and Gherkin tests

https://admhelp.microfocus.com ALM Octane 8942
Tips to improve your search results... ALM Octane Help Center ALM Octane Help 23.4-24.3 All View Local Help Center View Online Help Center Version: