In my last blog post I outlined the obstacles we had to master when moving from Subversion to Git. Since then more than one year has passed and several of the assumptions we have once made no longer hold. This post describes what changes we had to make in our development process and build & deployment infrastructure due to migrating to Git and which improvements we gained.

Our mission at CQSE is to help customers improve the quality of their code. Our tool Teamscale checks source code and reports issues such as logical flaws, copy&paste programming and possible performance bottlenecks.

However there is one aspect of code quality that we did not address so far: code security. Code is secure if it can not be used by an attacker to perform unintended, dangerous actions on the host system.

In this post, I will explain how new analyses in Teamscale can efficiently detect vulnerabilities for such attacks and report them to developers.

Am 25. Oktober 2017 fand zum zweiten Mal der CQSE Software Intelligence Workshop statt. Der Workshop lief dieses Jahr unter dem Motto »Software Intelligence bei…«.

Hauptbestandteil des Workshops waren Vorträge unserer Kunden mit Erfahrungsberichten, wie Software Intelligence bei ihnen jeweils konkret zum Einsatz kommt. Wir möchten uns bei den über 100 Teilnehmern herzlich für die wertvollen Diskussionsbeiträge bedanken.

As you probably know, our quality tool Teamscale comes with a lot of checks for your programming language(s) of choice. These checks can, for example, help you to write better code by pointing out logical flaws, copy&paste programming and possible performance bottlenecks.

But did you know that you can easily implement customized checks for your code base? In this post, I’ll show how we use this to improve our own code base by presenting two specific examples.

When we set up the Test Gap Analysis for one of our customers, we have to instrument their application with a code coverage tool which records the lines of code executed during their tests. This coverage information is an important input for the analysis.

For Java, our go-to tool is JaCoCo. It works really well for our use case, is a mature tool with many configuration options and has little performance impact in most scenarios. We have, however, run into several recurring problems with it which can make its use cumbersome.

In this post, I’m going to show you the problems we encountered and present our solution, which makes setting up the Test Gap Analysis for Java applications (and getting code coverage in general) a lot easier.

Since release version 3.4, Teamscale has offered support for Gerrit. Over the last months, we have steadily worked to extend and improve this support even further to cover all conceivable use cases.

In this post, I am going to show you how this support looks like to the Teamscale end user.

In this blog-post I’d like to give a few insights on how someone can inspect code maintainability of code written in Fortran and I will use as an example a popular open source library.

Providing developers with feedback about code quality which is fast, specific and integrated is our mission at CQSE and an important theme behind Teamscale.

In this blog post, I describe how new integration features of Teamscale make such feedback available for ABAP developers and system managers.

In this blog post I’d like to give a few insights on how we do ABAP programming at CQSE, which might be quite different than in most other ABAP development teams.

Test Gap Analysis identifies changed code that was never tested before a release. Often, these code areas - the so called "test gaps" - are way more error prone than the rest of the system. We introduced Test Gap Analysis in many projects and used it on a wide range of different projects: from enterprise information systems to embedded software, from C/C++ to Java, C#, Python and even ABAP. In this post, I want to highlight a few important factors, which I think are good to know before starting with Test Gap Analysis.