A CQSE presentation on software quality
Talks

We give talks about software quality at industrial conferences and internal workshops of our customers regularly. Depending on your requirements, we can give talks in English or German

Announcements
Be notified about our next talks

Subscribe to our newsletter and you'll be the first to know when a new talk has been scheduled.

Get a quick notification when we blog about software quality, speak on conferences or publish our CQSE Spotlight.
Once every 6 weeks, you'll get a nice summary of Teamscale's latest features.

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

Invited Talks

We are happy to come visit you in your office for an internal conference or a workshop. Our list of topics includes quality analyses, quality control, but also test control or introducing peer reviews. You are also welcome to pick a topic of your choice.

Request Invited Talk
Past Talks

Die typischen Beispiele für technische Schulden sind uns allen bekannt. Trotzdem werden diese in den meisten Projekten nicht ausreichend adressiert, da es nicht gelungen ist, die Entscheidungsträger von ihrer Relevanz zu überzeugen.

Ich sammele seit 15 Jahren in Forschung und Praxis Erfahrungen, wie sich technische Schulden effektiv interpretieren und kommunizieren lassen. In diesem Vortrag stelle ich anhand von Kundenprojekten die Analysen, Visualisierungen und Kostenmodelle vor, die hierfür am besten funktionieren.

 

Read more...

Viele historisch gewachsene Systeme sammeln über die Jahre Code an, den niemand mehr braucht und der deshalb nutzlos ist. Ein Grund dafür ist beispielsweise, dass bereits implementierte Anforderungen obsolet werden und der Code, der diese Anforderungen implementiert, in der Codebasis verbleibt. Da meist unbekannt ist, welcher Code nutzlos ist, verursacht er oft Kosten ohne Wert zu stiften. In diesem Vortrag stellen wir drei statische und dynamische Analyseansätze vor, die wir in den letzten Jahren bei der Analyse von Kundensystemen und im Rahmen von Forschungsarbeiten entwickelt haben. Schließlich beschreiben wir konkrete Handlungsoptionen zum Umgang mit nutzlosem Code bei Migration und Wartung.

Read more...

Es gibt grundsätzlich zwei Arten, um Funktionalität wiederzuverwenden: Systematisch und Ad-Hoc. Systematische Wiederverwendung steht im Lehrbuch und umfasst die Erstellung von wiederverwendbaren Artefakten (Klassen, Komponenten, Services, usw.) die an einer Stelle im Code gepflegt, und von vielen Stellen genutzt werden. Ad-Hoc-Wiederverwendung steht nicht im Lehrbuch, kennt aber trotzdem jeder: Quelltext wird einfach überall dorthin kopiert, wo die Funktionalität benötigt wird.

In dieser Keynote möchte ich unterschiedliche Fälle von Ad-Hoc-Reuse aus verschiedenen Bereichen der Praxis vorstellen (u.a. eingebettete Software und betriebliche Informationssysteme). Ich werde jeweils auf die Ursachen eingehen und vorstellen wie die Organisation damit umgegangen ist: Von Fällen, in denen ad-hoc in systematische Wiederverwendung überführt wurde, bis zu Beispielen, in denen Ad-Hoc Wiederverwendung beibehalten, aber kontrolliert gewartet wird.

Read more...

-- Since this post accompanies a talk in German, it is written in German, too.

 

Durch Clone-Detection aufgedeckte Codeduplikate in Testcode sind schwieriger zu bewerten als solche in Produktivcode, und in der Praxis werden sie häufig ignoriert. In der Folge bleiben redundante Codeabschnitte in Testcode erhalten. Diese führen zu War-tungsproblemen, und es besteht die Gefahr ungewollt inkonsistenter Änderungen. In diesem Vortrag wird hinterfragt, ob die Kombination von Ergebnissen einer Clone Detection mit testspezifischer Code Coverage helfen kann, Klonfunde in Testcode automatisch zubewerten.

 

 

Read more...

In software projects with growing functionality, the number of tests increases fast which results in long execution times for the whole test suite. As a consequence, it is not possible to always execute the wholetest suite after each commit so that feedback time todevelopers increases. With long test feedback times, the effort for an early fix rises and developers can behindered in productive work. One solution to reduce feedback times is test case prioritization. Although test prioritization strategies have been extensively studied, they are rarely used in practice and their benefits are widely unknown.

 

 

Read more...

-- Since this post accompanies a talk in German, it is written in German, too.

Durch Tests möchten wir Fehler finden, bevor diese in Produktion gelangen. Leider gelingt das nicht immer. Studien zeigen, dass die meisten Feldfehler dort auftreten, wo viel geändert, aber wenig getestet wurde. Seit 2012 setzen wir deshalb mit unseren Kunden Test-Gap-Analyse ein, wodurch solche ungetesteten Änderungen bereits während der Entwicklung vollautomatisch identifiziert werden, damit Entwickler und Tester frühzeitig und kontinuierlich reagieren können.

Read more...

Im Test möchten wir Fehler finden, bevor diese in Produktion gelangen. Trotzdem gelingt dies nicht immer zu 100 Prozent. Dr. Stefan Staudt (TRUMPF Werkzeugmaschinen) gibt einen Einblick in die Hintergründe zur Einführung der Test-Gap-Analyse bei TRUMPF und berichtet von Erfahrungen bei deren Einsatz insbesondere auch im Hinblick auf die Instrumentierung von C++-Anwendungen, um die Testausführung zu messen.

Read more...

Grown software systems often contain code that is not necessary anymore. To study the feasibility and usefulness of our approach, we conducted a study involving 14 open-source and closed-source software systems.

Read more...

Many software development processes rely on quality gates. However, these quality gates often do not work as expected since they are heavyweight and provide feedback too late. As a result, quality gates fail to assure quality and cannot stop the quality erosion of software. In this talk, I explain how recent developments in the area of code collaboration platforms (Github, Gitlab, Bitbucket, …) support a more lightweight and more effective type of quality gates: These “quality doors” enable ultra short feedback cycles to an extent that would have been inconceivable a few years ago.

 

 

Read more...

-- Since this post accompanies a talk in German, it is written in German, too.

 

Bei langlebiger Software treten die meisten Fehler dort auf, wo viel geändert wird. Wenn wir richtig testen wollen, müssen wir daher sicherstellen, dass keine wichtigen Änderungen ungetestet bleiben. Hierbei hilft uns Test-Gap-Analyse, ein Analyseverfahren, das ungetestete Änderungen vollautomatisch ermittelt. In diesem Vortrag zeigen wir den Einsatz der Test-Gap-Analyse mit unserem Analysewerkzeug Teamscale. Wir zeigen einerseits, wie Test-Gaps auf Gesamtsystemebene betrachtet werden könnten, um beispielsweise die Testqualität über alle Teststufen für ein Software-Release zu bewerten. Außerdem demonstrieren wir, wie sich Test-Gaps auf die Ebene einzelner Issues herunterbrechen lassen,

 

Read more...