Getting Personalized Feedback
As opposed to many existing static analyses tools, Teamscale strives to provide immediate feedback for developers. Personal and quick feedback is essential when trying to improve quality.
We have often seen that the absence of it causes quality improvement campaigns to fail. Teamscale employs its analyses commit-based and is, thus, able to provide fine-grained feedback. Feedback which does not overwhelm the developer but instead focuses on his specific needs and use-cases. And feedback which comes quick enough while they are still working on their current task.
Stay Informed Without Leaving Your IDE or Editor
Rather than switching to the browser, developers often prefer to gather all necessary information within their IDE. Teamscale integrates in common development environments such as IntelliJ, Eclipse, Visual Studio, Visual Studio Code, and Qt Creator. With the plug-in, you can inspect the findings directly as markers in the code. To clean up on-the-fly or to inspect newly introduced findings, developers do not have to leave their IDE. Thus, they can avoid distracting context switches.
You can furthermore integrate Teamscale into other IDEs and text editors like Sublime Text, Vim, or XCode via the command-line client for developers (teamscale-dev). This allows developers to use Teamscale in environments for which no dedicated plug-in exists yet.
Get Feedback in Pull and Merge Requests
If you're already using a code collaboration platform like GitHub, GitLab, SCM-Manager, Bitbucket, Gitea or Azure DevOps, you can also push code quality information to developers there. Developers can use this information to see at a glance whether their merge request is clean (i.e. no newly introduced findings) and can be merged or whether they should have a second look at the findings reported by Teamscale before merging. The integrations into these tools can either insert a findings badge into each pull/merge request that shows the resolved and new findings, can vote on pull/merge requests (think: thumbs up or thumbs down) or can even add detailed inline comments for every new finding in the code collaboration platform's diff view.
How to Address These Comments?
In general, most Teamscale comments should be pretty easy and straightforward to fix. We suggest to look at each comment one by one and at least consider fixing it. Typically, the developer will decide together with their reviewer whether a certain finding can be ignored.
Does This Mean Every Finding Needs to be Resolved?
No! Teamscale is just a tool. Negotiate with your reviewer which findings should be fixed and which are okay to leave in. There is an icon in the beginning of the Teamscale comment which indicates the severity of a finding:
- marks less severe findings - at least think about fixing it
- marks more severe findings - think twice whether this can be ignored
Should I Tolerate the Findings That I Don't Resolve?
Teamscale allows you to flag findings as both "false positive" and "toleration":
- False positive means: There is an error in the analysis. The highlighted code doesn't do what the finding claims it does.
- Toleration means: The finding is technically correct, i.e. there is no error with the analysis. However, in this specific case, I think the code is fine as is and I don't think I'll refactor it.
Teamscale will ignore flagged findings going forward such that they will never show up again anywhere. However, Teamscale in the context of pull and merge requests, Teamscale will already only comment new findings, meaning that the main effect of flagging a finding is that it won't show up among the blue findings again. So overall our advice would be: You can tolerate findings that you don't want to fix, but you don't have to.
To flag a finding navigate to the findings detail view by opening the finding itself in Teamscale. This can be done either by clicking the link in the comment or by locating the finding in your change request in the Teamscale web UI.
Analyze Code and Test Quality in Jira
With our Jira integration you can also visualize code and test quality information on your Jira issues. This allows you to see at a glance, whether an issue is really finished (i.e. code and tests for this issue have no obvious problems). Developers can see a findings badge that shows new and resolved findings for the code changes they made for the issue. Testers can see, how many of these code changes have not yet been executed in the tests (so-called Test Gaps)
Receive Emails about Changes
Furthermore, you can configure Teamscale to notify you via e-mail. It remains up to you, about what kind of changes you want to be alerted.
To configure your notifications, click on your user symbol in the upper right corner of the browser and select Preferences in the drop down menu.
You can add rules to be notified when a certain type of finding is added, when a metric threshold is violated or when you are related to a task. 
Edit Notification Rules for Findings
The image shows an example of the configuration dialog to add a notification rule for findings. You can configure the projects on which the rules apply as well as committers and events triggering the rule. You can also explicitly sate to not trigger the rule if, e.g., the finding category or the finding group equal your specified string. To look up how your categories are named and which groups you are using, please refer to your analysis profile.
Inspect the Impact of a Single Change in Teamscale
Developers can use Teamscale in several different ways to get feedback: In the activity perspective of the Web UI, they can inform themselves about the impact of their recent commits. If developers want to avoid context switches, they can stay in their IDEs and use Teamscale's integration. Or, they can turn on the email service and receive notifications when something noteworthy happens.
In the activity perspective, developers can browse the commit history of the underlying version control system:
Developer Feedback in the Activity Perspective
They can directly glance at the most recent commits at the top of the stream or use the filter mechanism in the sidebar to view only those changes that were committed by himself, for example. The commit stream provides the technical information about the commit itself (author, message, date and related issue) but also its impact on the system's quality: It shows how many findings were added by this commit (red), how many were removed (green) and how many still remain in code that was modified by this commit.
By clicking on the commit, developers gets more detailed feedback:
Feedback in Commit Details
They can inspect which findings in which file were added or removed and also which impact their commit had on various metrics. They can then either click on the findings message to navigate to the finding's detail page providing more information about the type of the finding and why it is relevant or click on the finding location to directly jump into the source code.
Inspecting the impact of your change in the browser, however, requires the developer to actively pull this information. Teamscale also provides push-notification services in your IDE and via email.