# Findings Perspective

The main use case of the Findings perspective is to inspect the findings of a system. Several filter mechanisms help to reduce the set of findings to a manageable size. For each finding, detailed information about its introduction (and removal) are available.

# Findings Overview Table

When opening the Findings perspective, the Findings Overview View shows a table with all findings for a Teamscale project. For each finding, the table provides information about the finding’s message, the finding location, the finding group as well as the introduction date:

Findings Overview Table

# Action: Navigating All Findings

For grown software systems, the table of the Findings Overview View usually contains a very large number of findings. To better inspect and navigate them, the sidebar provides several different filter mechanisms and navigation helpers:

Image: finding_perspective_side_bar

First, with the Quality Goal Settings , you can configure the underlying quality goal of the project. If a quality goal is set, only findings relevant to the quality goal will be shown in the table. The table will then be annotated, e.g., with [since Dec 06 2016 00:00]. Configuring the quality goal as well as its implication is described here. The Quality Goal Settings also provide the opportunity to manage the baselines which will be explained in a later action.

Second, the Finding Filter Settings give you the opportunity to use an arbitrary regular expression. Hitting »Enter« will apply the regular expression to the finding's message as well as to its location. The table then shows only findings matching the regular expression. For example, entering »test« will show findings with the message »Avoid ignoring JUnit tests«.

Third, Show Assessments offers to filter findings based on the finding severity. You can either show only red findings, only yellow findings or both. Under Tasks , you can configure to exclude findings which have been added to a task already.

Fourth, the rest of the sidebar can be used to filter based on finding category and finding group. After configuring the check boxes, you have to use the Apply button to apply the filters to the table.

Furthermore, the content of the table can filtered based on a path. By clicking on Choose folder... in the table header, you can select sub folders of your project in a dialog opening up . After the selection, the table will show only findings from the specific subfolder. If you are working with an architecture definition, you can also select the architecture and pick a component or subcomponent. Then only findings in files will be shown that map to the selected component.

Additionally, the table can be sorted by the values of all four columns. Clicking on the header of one column will sort in descending order, i. e. showing the newest introduction dates or messages starting with »A« first. Clicking the column header again will reverse the order.

# Tolerated Findings View

Additionally, the table provides a link in its header to the tolerated findings. Clicking on the Tolerated tab will open the Tolerated Findings View:

Tolerated Findings View

The view is designed in analogy to the Findings Overview View. The table additionally shows the Toleration Date which denotes the date of setting this finding as tolerated, and the Toleration Rationale which gives a reason for tolerating this finding. In case branch support was enabled for the underlying project, a finding is tolerated only for the current branch. If the branch which contains the tolerated finding is merged, the toleration is transferred to the other branch. With the additional field Tolerated Rationale provided in the sidebar of this perspective, the tolerated findings can be filtered by their rationale.

# False Positive Findings View

Similar to the Tolerated Findings View, the table provides a link in its header to the false positive findings. Choosing the False Positives tab will open the False Positive Findings View:

Image: findings-false-positive

The table additionally shows the False Positive Date which denotes the date of setting this finding as false positive, and the False Positive Rationale which gives a reason for tolerating this finding. In case branch support was enabled for the underlying project, a finding is set as false positive only for the current branch. If the branch which contains the false positive finding is merged, the setting as false positive is transferred to the other branch. With the additional field False Positive Rationale provided in the sidebar of this perspective, the false positive findings can be filtered by their rationale.

# Action: Inspecting a Finding

The table provides several possibilities to obtain more information about a single finding. For example, clicking on the finding location will open the Code Detail View and show the source code file containing the finding. Clicking on the finding's message opens up the Finding Detail View.

# Findings Detail View

This view provides you detailed information about a single finding:

Image: findings-detail-view

It shows you the finding's message again as well as more detailed information about the impact of this type of finding on code quality. On the right, you can flag the finding as tolerated finding or false positive finding.

The Details provide you more information about the finding. You can view, e.g., its property values or add it to a task which is described in the following in a separate action. Often, you might be curious how a certain finding was introduced. Clicking on the blue date will open up the Findings Introduction View.

# Findings Introduction View

This view shows you how a certain finding was introduced. It comprises a comparison view of the last revision before the finding was introduced on the left an the introducing revision on the right:

Image: findings-intro-diff

In green, lines are shown which were added. Blue denotes changes to existing lines and red indicates removed lines (not shown in the picture).

Back in the Findings Detail View, you can also use the Diff to... button and manually choose an arbitrary revision to compare against. This will show you the differences between the revision in which the finding was introduced and the revision you have just chosen.

# Action: Creating a Baseline

As described in General UI Features, Teamscale provides the concept of quality goals to manage potentially large amounts of findings. Quality goals preserving and improving involve defining a baseline - a point in time after which a finding is considered to be new.

To create a new baseline, the sidebar in the Findings perspective offers to Manage baselines under the heading Quality Goal Settings. The link opens the Baseline Management View.

# Baseline Management View

This view serves to manage baselines:

Image: findings-baseline-management

It contains a table listing all existing baselines. Initially, this table will be empty.

With the symbol, you can add a new baseline which will open up the Edit Baseline Dialog as depicted here:

Creating Baseline

You can create a baseline with a name and a date and a description to it. The same dialog will open up when you use the icon in the table to edit an existing baseline.

# Action: Add Finding to Task

Alternatively, you can navigate to the Findings Detail View and use the button Add to task to add a single finding to a task. This will open the same dialog. In the dialog, you can either create a new task or add the findings to an existing task.

Adding A Finding To Task