# 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:
# 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:
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
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:
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:
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:
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:
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
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:
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:
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
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