# Improving Software Quality
Teamscale can do much more than the average static code analyzer. Here is a quick overview:
# Improving Code Quality using Quality Goals
Teamscale's default configuration offers you commonly used and actionable metrics with respect to
- the structure of your code (file sizes, method lengths and nesting depths),
- redundancy caused by copy & paste programming,
- documentation in term of source code comments,
- violations of coding conventions, and
- bug patterns (e.g., derived from data flow analysis)
But it can be also easily extended using custom checks specifically tailored for your needs.
After choosing appropriate metrics, improving code quality requires a realistic goal, a quality goal. Otherwise, your developers are more frustrated than before. Depending on your project's history, the goal can vary. If you just started to develop a new system on the green-field, the overall goal of zero findings might still be feasible. However, for grown-software, we strongly recommend to accept the current quality status as it is and just start from there. Either choose the goal to keep the status quo and at least not make it worse (i. e. not introducing new findings). Or take it one step further and try to improve code that you are working on anyway (i. e. remove findings in code that is currently modified due to a feature change request).
# Quality Goals
Teamscale helps you to reinforce your quality goal. As many existing tools operate in batch mode, they analyze the entire system at once. While this is lengthy in time, it also omits the ability to provide accurate information which finding is new or in modified code. Teamscale, however, analyzes every single commit to your repository . Hence, it knows exactly when a specific finding was newly introduced to the system. Consequently, Teamscale can directly reveal violations of your quality goal, for example, if a developer just created a new finding or if a developer missed the chance to remove a finding in code you touched recently.
# Why Fast Feedback is Essential
Most importantly, developers do not have to wait a day but can fix the problems immediately while they are still working on the subject: Teamscale provides the developer feedback within seconds after a commit. It specifically informs the developer about the impact of his change with respect to quality. Even personal notification services can be configured. Personal feedback is crucial to reduce the information flood and to focus on the essentials. It helps to focus only on new problems regardless of the past and to visualize small first steps of success.
In almost all software projects, feature pressure and time constraints are dominating every-day decisions. As a response, many teams have created the role of a quality engineer to ensure that quality improvements do not fall off the table. Teamscale also addresses the quality engineer's need to monitor the quality trend, to understand outliers of a specific metric and to report to management. Improving quality without management support is like Icarus striving for the sun. Hence, when management is providing resources, creating transparency about its usage is beneficial for both sides. Often, a clearly defined quality control process as in this example:
# Code Quality Control Process
Such a process increases satisfaction of all stakeholders and leads to long-term success .
In this process, software intelligence creates transparency and positive quality-awareness. It supports the developer in his daily work and makes the project manager aware of the current quality status and the usage of provided resources. Based on this level of information, he can steer his project more confidently without risking that feature pressure imposes uncontrollable impact on the code quality.
# Ensuring Test Quality
In contrast to code quality, test quality is often directly visible to the user –- namely, if the software does not work as it should. For long-lived software, most bugs are introduced by changes to existing code or by writing new code. Hence, test managers focus on testing what has changed recently. Nevertheless, untested changes are often released, causing field bugs and potential hot-fixes. Our study has shown that approximately half of the changes are not tested once before being released . Why is that?
Software errors can have very different root causes. That’s why there is usually no single test level, but a pyramid of tests ranging from low-evel unit tests to integration tests and high-level system tests. Each type of test targets to find different types of bugs. Unit tests are often written by the developers themselves. They usually know what changed and what unit tests cover. But testers responsible for integration or system testing often do not know if their test runs cover the actual code changes: Testers are usually driven by change requests resulting from adapting requirements. But the information which code regions were in fact affected by a designated change request is usually not available for them.
# Test Quality Control Process
Teamscale closes this gap by combining information that is already there: Being connected to the version control system, Teamscale knows exactly which parts of the code changed since the last test run. As it also integrates with test coverage tools, Teamscale also knows which code was executed during the last test. Combining both sources, Teamscale reveals recent changes that have not been tested so far and can provide feedback to the test manager. Based on these existing gaps in the test execution, the test manager can decide which test cases to select for the next test run. This form of software intelligence combines information from the development and testing process that is already there. But many companies have not been able to combine the information due to missing tool support. With Teamscale, the information can be easily combined.
# Managing Architecture Quality
In addition to code and test quality, Teamscale also helps to manage your architecture quality. Many teams have at least an informal understanding what the architecture of their system - in terms of component diagrams - roughly looks like. But only few have it documented and even fewer have a conforming code base.
Teamscale helps you first to model the architecture. With an easy graphical user interface, you can specify components and wanted dependencies. In a second step, Teamscale continuously checks whether your current code base conforms to your specifications. It will notify the developer of unwanted dependencies immediately after a commit. After inspection, it is then up to the developer to clean up the code (if the dependency is, in fact, unwanted) or to adapt your specification (if you can live with the new dependency):
# Architecture Quality Control Process
Teamscale supports you to avoid a commonly seen loss of architecture knowledge  and to keep your implementation conform to the intended architecture.
# Analyzing Feature Usage
During any quality assurance process, managers and developers prefer focusing on those parts of the system that users often use. Nobody wants to waste money on code that is not even executed by the user. Even though this code has already been written, it still creates overhead costs for maintenance that should not be underestimated .
On the one hand, Teamscale integrates the information from a usage profiler in the system's production environment. On the other hand, it analyzes the development process. Combining both information sources provides valuable input for managing the costs of software maintenance. It supports developers and managers in their decision to delete code that is never executed. It also helps them to make sure only those features are extended that are in fact used.
# Analysis Process of Feature Usage
# Further Reading:
- Continuous Software Quality Control in Practice
D. Steidl, F. Deissenboeck, M. Poehlmann, R. Heinke, and B. Uhink-Mergenthaler, In: Proceedings of the IEEE International Conference on Software Maintenance and Evolution (ICSME). 2014
- Did We Test Our Changes? Assessing Alignment between Tests and Development in Practice
S. Eder, B. Hauptmann, M. Junker, E. Juergens, R. Vaas, and K-H. Prommer.
- The loss of architectural knowledge during system evolution: An industrial case study
M. Feilkas, D. Ratiu, and E. Jürgens, In: Proceedings of the 17th IEEE International Conference on Program Comprehension (ICPC’09). 2009
- How much does unused code matter for maintenance?
S. Eder, M. Junker, E. Jürgens, B. Hauptmann, R. Vaas, and K.-H. Prommer, In: Proceedings of the 34th International Conference on Software Engineering (ICSE 12). 2012