Dr. Elmar Jürgens & Dr. Elmar Jürgens

This post is about student internships at CQSE. If you are studying computer science and are looking for a job specifically designed to help you get the most out of your studies, read on.



Dr. Benjamin Hummel & Dr. Benjamin Hummel

Have you ever used static analysis tools? Then you probably know how they tend to flood you with so many analysis results findings), that you don’t know where to even start reading and resolving them. Instead of turning these tools off again, read on for some strategies for dealing with the findings flood.


Dr. Nils Göde & Dr. Nils Göde

As you probably know, you should keep the methods (functions, procedures, …)

in your code short and have each of them do only one thing. While hardly anyone

opposes this rule, we still find a large number of long methods in the code

bases we analyze.


Dr. Florian Deißenböck & Dr. Florian Deißenböck

Almost everybody agrees that having a consistent setup for compiler errors,

warnings and the code formatter across all team members is crucial. However,

many development projects still fail to achieve this. Surprisingly, the main

reason for this seems to be that most developers are not aware that this can be

easily enforced with Eclipse and use cumbersome »How to setup your

workspace« descriptions in the developer wiki instead. In most cases these

descriptions are outdated or generally ignored. As this is an issue that I have

repeatedly discussed with our customers (and recently at the

BITKOM Workshop in Frankfurt) I explain how

enforcing a consistent setup for compiler errors, warnings and the code

formatter works with Eclipse.


Fabian Streitel & Fabian Streitel

Testing is an integral part of a software product’s life-cycle. Some people prefer

executing their tests continuously while they develop, others have a separate

testing phase before each release. The goal, however, is always the same:

finding bugs. The more, the better.


Unfortunately, the time available for testing and for writing new tests is limited. At some point, you

have to get on with development, ship your software and be confident it contains

no serious flaws. Often, more tests exist than can be run in the

available time span. This is especially true if your tests are executed manually,

as is the case for many of our customers.

Then the question becomes: which tests do I select to find the

most bugs before the release?


Research has…


Fabian Streitel & Fabian Streitel

One of the services we offer is called Test Gap Analysis, which helps to identify changes in your code that have not been covered by your tests since the last release.

I have been working on Test Gap Analysis for the last few months and never had to worry about performance problems, until recently, when we hit a performance problem. Surprisingly, the implementation of Java's String#replace method was the culprit!


Dr. Daniela Steidl & Dr. Daniela Steidl

The recent blog post ‘Improving Software Quality’ by my colleague Martin showed how we can improve software quality besides just installing tools: We believe that a continuous quality control process is necessary to have a long-term, measurable impact. However, does this quality control actually have an long-term impact in practice? Or are feature and change requests still receiving more priorities than cleaning up code that was written in a hurry and under time pressure?

With our long-term partner Munich Re, we gathered enough data to show in a large-scale industry case study that quality control can improve the code quality even while the system is still under active development. Our results were accepted to be published as a conference paper at the…


Dr. Daniela Steidl & Dr. Daniela Steidl

Teamscale is our tool for continuous software quality control. It provides feedback about quality problems in real-time, allowing you to keep your software free of technical debt. To give you a better idea, how certain core features of Teamscale work in practice, we created a couple of short video clips that demonstrate Teamscale in action.


Dr. Benjamin Hummel & Dr. Benjamin Hummel

In the previous


we introduced the notion of code clones and discussed, whether and

under which circumstances cloning in your code base can be a problem

for development and maintenance. In this post, I will introduce ways

and tools to deal with code clones in your code base. After reading

this, you should be able to select and apply a detection tool to

inspect the clones in your own code base.


Dr. Benjamin Hummel & Dr. Benjamin Hummel

One well known principle in software engineering states don’t repeat

yourself, also known as the DRY principle. A very obvious violation of

DRY is the application of copy/paste to create duplicates of large

portions of source code within the same code base. These duplicate

pieces of code, also known as code clones, have been subject to lots

of research in the last two decades. In this two-part post I want to

summarize those parts of the current knowledge that I find most

relevant to the practitioner, especially the impact of clones on

software development and how to deal with them in terms of tools and



Interested in our blog? Subscribe!

Get a short notification when we blog about software quality, speak on conferences or publish our CQSE Spotlight.

By submitting your data you confirm that you agree to our privacy policy.