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

Die meisten Fehler treten bei langlebiger Software dort auf, wo viel geändert wird. Wer richtig will, muss sicherstellen, dass keine wichtigen Änderungen ungetestet bleiben. Die Test-Gap-Analyse hilft uns ungetestete Änderungen zu finden. Nach einer Einführung in die Test-Gap-Analyse stellen wir im Vortrag die Erfahrungen vor, die wir in den letzten Jahren im Einsatz bei Kunden und in der eigenen Entwicklung gesammelt haben und beantworten u.a. folgende Fragen: Wie lassen sich Hotfix-Tests absichern? Wie kann ich iterationsbegleitend ermitteln, wie gründlich ausgewählte kritische User Stories oder Change Requests getestet wurden? Wie stehen im Release-Test die Testabdeckungen von unterschiedlichen Teststufen (Unit-Test, Integrationstest, Akzeptanztest, User-Trampeltest usw.) zueinander und welche Änderungen wurden von keiner Teststufe geprüft?

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

Wir wissen alle, wie Code idealerweise aussehen sollte: Kurze Methoden, keine kopierten Code-Abschnitte, vollständige Kommentierung, usw. Wir wissen aber auch, dass dieses Idealbild in der Praxis nur selten erreicht werden kann. Wir stellen einen Benchmark vor, der Systeme hinsichtlich verschiedener Qualitätseigenschaften vergleicht. Daraus lässt sich eine Erwartungshaltung ableiten, die hilft zu entscheiden, in welchen Bereichen Handlungsbedarf besteht. Zusätzlich teilen wir unsere Erfahrungen beim Erstellen eines solchen Benchmarks.

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

Wenn ein System wächst, wird auch die Anzahl der automatisierten Tests größer. Das hat zur Folge, dass die Tests länger brauchen. Wir sehen in der Praxis zunehmend öfter Test-Suiten, die mehrere Stunden bis Tage laufen. Dadurch müssen Entwickler immer länger auf Feedback warten. Das erschwert die Lokalisierung der Ursachen von Testfehlschlägen und mindert dadurch den Wert der Tests.

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

Viele Teams müssen immer mehr Funktionalität in immer weniger Zeit testen. Historisch gewachsene Test-Suites stoßen dabei oft an ihre Grenzen, da sie gleichzeitig Zuviel und Zuwenig testen. Zuviel, da sie Tests enthalten, die Kosten erzeugen, aber kaum Mehrwert gegenüber ähnlichen Tests bieten. Zuwenig, da trotzdem wichtige Funktionalität ungetestet bleibt. Im Vortrag stelle ich Analysetechniken vor, um diese Probleme im eigenen System aufzuzeigen. Historienanalyse des Versionskontrollsystems zeigt, wo in der Vergangenheit im System am meisten Fehler aufgetreten sind. Test-Gap-Analyse deckt auf, welche Code-Änderungen noch ungetestet sind. Und Pareto-Test-Analysen identifizieren die Tests, die das schlechteste Kosten-Nutzen-Verhältnis haben.

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

Wir wissen alle, wie Code idealerweise aussehen sollte: Kurze Methoden, keine kopierten Code-Abschnitte, vollständige Kommentierung, usw. Wir wissen aber auch, dass dieses Idealbild in der Praxis nur selten erreicht werden kann. Wir stellen einen Benchmark vor, der Systeme hinsichtlich verschiedener Qualitätseigenschaften vergleicht. Daraus lässt sich eine Erwartungshaltung ableiten, die hilft zu entscheiden, in welchen Bereichen Handlungsbedarf besteht. Zusätzlich teilen wir unsere Erfahrungen beim Erstellen eines solchen Benchmarks.

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

Je älter und größer ein Softwaresystem ist, desto wichtiger ist eine verlässliche, automatisierte Testsuite. Insbesondere, wenn viele Änderungen umgesetzt und kurze Release-Zyklen angestrebt werden. Mit der Größe des Systems wächst jedoch die Testsuite und damit steigt auch deren Ausführungsdauer. Wir sehen bei unseren Kunden immer öfter Testsuites, die mehrere Stunden oder sogar Tage laufen. Langlaufende Testsuites werden aber meist seltener ausgeführt als schnelle, z.B. wöchentlich statt täglich. Dadurch müssen Entwickler länger auf Feedback warten, was es ihnen erschwert, die Ursache für fehlschlagende Tests zu lokalisieren. In zwei Vorträgen stellen wir erst die Grundideen und Forschungsergebnisse vor und dann die Erfahrungen, die wir bei der Bayerischen Versorgungskammer damit gesammelt haben.

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

Passen Architektur einer Anwendung und Kommunikationsstrukturen ihres Entwicklungsteams nicht zueinander, führt das zu Problemen. Sowohl die Architektur, als auch die Teamorganisation entwickeln sich jedoch oft unabhängig voneinander weiter. Wie können wir früh merken, wenn Probleme auftreten, um rechtzeitig reagieren zu können? Im Vortrag stelle ich moderne Analysetechniken vor, die uns hierbei unterstützen. Die Analysen beziehen dabei eine Vielzahl von Daten ein, die wir in der Software-Entwicklung produzieren: Von Code, über Versionshistorien, bis hin zu Traces und Ausführungsinformationen aus Test- und Produktionssystemen. Dadurch erlauben sie faktenbasierte Entscheidungen in einem Umfeld, in dem gerade in Krisensituationen sonst oft emotionsgeladene Diskussionen geführt werden.

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

Viele Teams müssen immer mehr Funktionalität in immer weniger Zeit testen. Historisch gewachsene Test-Suites stoßen dabei oft an ihre Grenzen, da sie gleichzeitig Zuviel und Zuwenig testen. Zuviel, da sie Tests enthalten, die Kosten erzeugen, aber kaum Mehrwert gegenüber ähnlichen Tests bieten. Zuwenig, da trotzdem wichtige Funktionalität ungetestet bleibt. Im Vortrag stelle ich Analysetechniken vor, um diese Probleme im eigenen System aufzuzeigen. Historienanalyse des Versionskontrollsystems zeigt, wo in der Vergangenheit im System am meisten Fehler aufgetreten sind. Test-Gap-Analyse deckt auf, welche Code-Änderungen noch ungetestet sind. Und Pareto-Test-Analysen identifizieren die Tests, die das schlechteste Kosten-Nutzen-Verhältnis haben.

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

Software-Qualitätssicherung ist eine Feedback-Schleife: Entwickler arbeiten an einem Software-System, und dieses System durchläuft eine Qualitätsbewertung, deren Ergebnisse dann wiederum die Entwickler bei ihrer Arbeit unterstützt. Häufig funktionieren Quality-Gates in der Praxis nicht wie gewünscht: Ihr Feedback kommt oft viel zu spät im Entwicklungsprozess, sodass der Schmerz dann zu groß ist, um wegen scheinbar wenig kritischer Qualitätsprobleme das ganze System zurück in die Entwicklung zu schieben. Außerdem bewerten Quality-Gates oft das System als Ganzes, statt konkrete Änderungen, sodass es für den einzelnen Entwickler schwer ist, auf das Feedback zu reagieren. In den letzten Jahren gab es allerdings einige Entwicklungen, die 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.

Wenn ein System wächst, wird auch die Anzahl der automatisierten Tests größer. Das hat zur Folge, dass die Tests länger brauchen. Wir sehen in der Praxis zunehmend öfter Test-Suiten, die mehrere Stunden bis Tage laufen. Dadurch müssen Entwickler immer länger auf Feedback warten. Das erschwert die Lokalisierung der Ursachen von Testfehlschlägen und mindert dadurch den Wert der Tests.

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

Wir wissen alle, wie Code idealerweise aussehen sollte: Kurze Methoden, keine kopierten Code-Abschnitte, vollständige Kommentierung, usw. Wir wissen aber auch, dass dieses Idealbild in der Praxis nur selten erreicht werden kann. Wir stellen einen Benchmark vor, der Systeme hinsichtlich verschiedener Qualitätseigenschaften vergleicht. Daraus lässt sich eine Erwartungshaltung ableiten, die hilft zu entscheiden, in welchen Bereichen Handlungsbedarf besteht. Zusätzlich teilen wir unsere Erfahrungen beim Erstellen eines solchen Benchmarks.

-- 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 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.