-- 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. Seit 2012 setzen wir deshalb mit unseren Kunden Test-Gap-Analyse ein, wodurch unsere ungetesteten Änderungen bereits während der Entwicklung vollautomatisch identifiziert werden. Im Vortrag stellen wir kurz die Grundlagen der Test-Gap-Analyse und die benötigten Datenquellen vor. Anschließend diskutieren wir verschiedene Einsatzszenarien, unterschiedliche Herausforderungen bei der Einführung und den quantitativ gemessenen Nutzen für unsere Kunden.

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

Wir testen, um neue Fehler rechtzeitig zu finden. Aber mit welcher Wahrscheinlichkeit finden meine Tests eigentlich neue Fehler?

In diesem Vortrag stelle ich verschiedene Ansätze vor, um diese Frage zu beantworten: Von Code-Coverage bis hin zu Mutation-Testing. Ich zeige alle Techniken an einem durchgängigen Beispiel aus der Praxis und gehe dabei auf die Grundidee der jeweiligen Technik, deren Aussagekraft und deren Grenze ein. Komplexere Analysetechniken erkaufen sich eine höhere Aussagekraft mit höherem Aufwand und einer abnehmenden Anwendbarkeit in der Praxis. Daher müssen die Techniken in den jeweiligen Kontext eingeordnet werden, in dem ihre Anwendung Sinn macht. Im Vortrag gebe ich einen konkreten Leitfaden für den Einsatz in Projekten.

Ich stelle im Vortrag sowohl traditionelle Techniken, als auch neue Forschungsergebnisse, die im Rahmen einer Promotion in unserer Gruppe entstanden sind, vor.

Die typischen Beispiele für technische Schulden sind uns allen bekannt. Trotzdem werden sie in den meisten Projekten nicht ausreichend adressiert. Ein Grund dafür ist, dass die Kosten, um Qualitätsprobleme zu beheben, viel einfacher zu quantifizieren sind, als der Nutzen.

Im Vortrag stellen wir verschiedene Ansätze vor, um Konsequenzen technischer Schulden zu quantifizieren und zu visualisieren. Die Kostenmodelle stammen aus der Forschung, die Beispiele aus realen Kundenprojekten.

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

Wer Qualitätsanalysen einführen möchte oder Ressourcen für den Abbau technischer Schulden einfordert, muss oft eine Kosten-Nutzen-Rechnung liefern. Da sich der Nutzen aus vermiedenen Problemen ergibt, die ja per Definition nicht aufgetreten sind, ist eine seriöse Quantifizierung schwierig. Die Munich Re setzt Qualitätsanalysen seit über 10 Jahren erfolgreich ein. Daher existiert eine breite Datenbasis von Qualitätskennzahlen vor und nach der Einführung der Analysen. Im Vortrag präsentieren wir Kosten-Nutzen-Rechnungen auf Basis dieser Daten, sowohl für statische Analysen als auch für die Test-Gap-Analyse.

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

Quality Gates, wie sie in vielen Software-Entwicklungsprozessen definiert sind, funktionieren in der Praxis meist nicht wie gewünscht, da sie zu schwergewichtig sind und ihr Feedback viel zu spät kommt.

In diesem Vortrag zeige ich auf, wie jüngere Entwicklungen im Bereich Code-Collaboration-Platforms (GitHub, Bitbucket, GitLab und Co.) es erlauben, eine viel schlankere und wirksamere Form von Quality Gates zu etablieren.

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

Machine Learning hat uns im privaten Bereich längst erreicht: Amazon schlägt mir Produkte vor, Netflix Filme. Oft treffen sie dabei sogar meinen Geschmack. Warum gibt es keine Software, die mir fundiert vorschlägt, was ich testen soll? Es gibt mehrere Ansätze in der Forschung, die das versprechen. Defect Prediction setzt beispielsweise Machine Learning auf historischen Fehlerdaten ein, um vorherzusagen, wo in meinem System mit hoher Wahrscheinlichkeit noch Fehler enthalten sein könnten. Inverse Defect Prediction identifiziert Bereiche, die vermutlich viel weniger Fehler enthalten, und eher ignoriert werden können. Aber wie gut funktioniert das wirklich in der Praxis?

Wir haben verschiedene dieser Ansätze selbst implementiert und eingesetzt. In diesem Vortrag stelle ich die Ergebnisse und Erfahrungen aus Forschung und Praxis vor --- sowohl die nützlichen als auch die Fehlschläge.

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

In dieser Folge des "Genau mein Agil - Podcast" geht es Qualität und Qualitätssicherung im Agilen Umfeld. Hierzu spricht Philipp Diebold mit Sven Amann über das Verständnis von Qualität und Qualitätssicherung im Rahmen von Agiler (Software) Entwicklung. Wie wendet man gute Qualitätssicherung in einem solchen Umfeld an? Ist Qualitätssicherung in der Agilen Entwicklung schon automatisch integriert? Mit diesen und weiteren Fragen beschäftigen wir beide uns in der aktuellen Folge.

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

Jede*r von euch sollte ein Netzwerk haben und pflegen. Damit meine ich nicht, dass ihr auf Netzwerk Events Cocktails schlürfen oder die Zahl eurer „Freunde“ auf Facebook und eurer Follower auf Twitter, Insta & Co maximieren sollt. Das ist Quatsch in bringt euch nicht weiter. Euer Netzwerk besteht aus persönlichen, langfristigen Beziehungen.

We want our tests to discover new bugs quickly. But with which likelihood do my tests actually discover new bugs in my code base? And which code is pseudo-tested in the sense that it gets executed by tests, but in which novel, severe bugs will most likely not be discovered?

In this talk, I present different approaches to answer this question. From code coverage, to mutation testing to novel approaches in between from new research (partly from our group). I demonstrate all approaches using the same real world project and depict the strengths and limitations of each.

Wir streben alle nach möglichst hoher Qualität unseres Codes, wissen aber gleichzeitig dass eine gewisse Zahl an Qualitätsproblemen immer anwesend ist. Statt auf absolute Perfektion zu zielen, ist es oft viel sinnvoller zu schauen, ob man mit seinen Problemen im erwartbaren Bereich, oder deutlich darüber oder darunter liegt. Daraus lässt sich z.B. Handlungsbedarf ableiten und die Notwendigkeit zur Modernisierung argumentieren.