Many Teams must test more and more functionality in less and less time. We can only cope with this as testers, if we become both more efficient and effective by using modern analyses on our own data.

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

Ein gute Continuous Integration läuft weniger als 10min -- etwa die Zeit, um einen neuen Kaffee zu holen. Oft sprengt die Laufzeit der (automatisierten) Tests jedoch diesen Rahmen. Ein Lösungsansatz ist, eine Teilmenge der Tests für schnelles Feedback direkt auszuführen und die übrigen Tests in nachgelagerte Test-Builds (z.B. nightly) auszulagern, die auch länger brauchen dürfen. Die Test-Impact-Analyse verfolgt genau diese Idee.

-- 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. Immer mehr Funktionalität, weil erfolgreiche Software wächst, und damit von Release zu Release mehr und mehr Features getestet werden müssen. Paradoxerweise erhalten wir dafür aber immer weniger Zeit, da Release-Zyklen kürzer werden. Dadurch steigt in vielen Teams der Druck. Ich bin davon überzeugt, dass wir das nur schaffen, wenn wir uns passend zum Konferenzmotto „Reinventing Quality“ als Disziplin weiterentwickeln und dabei gleichzeitig effektiver und effizienter werden.

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

Durch immer kürzere Release-Zyklen erfolgen Test und Entwicklung immer häufiger parallel. In der Praxis führt das sowohl zu Test-Lücken, wenn geänderter Code ungetestet ausgeliefert wird, als auch zu nutzlosen Tests von Bereichen, die sich nicht verändert haben und daher keine neuen Fehler enthalten können. In diesem Solution-Workshop stellen wir Change-Driven Testing vor, um Test und Entwicklung präziser aufeinander abzustimmen und diese Probleme zu vermeiden.

Copy & Paste-Programmierung ist seit Jahrzehnten als Code-Smell verschrien. Das hat nicht verhindert, dass in quasi allen größeren Systemen viele durch Copy & Paste entstandene Klone vorkommen. In einigen Systemen kommt mehr als die Hälfte aller Zeilen in Kopie an anderen Stellen auch vor. Das schafft in der Weiterentwicklung viele Probleme. Clone Detection, also statische Code-Analyse, die solche Duplikate automatisiert erkennen kann, ist inzwischen in einigen IDEs enthalten. Allerdings zeigt die Erfahrung, dass es niemandem nützt, eine Liste mit 100.000 Klonen zu erzeugen. Die Herausforderung ist nicht das Finden, sondern Clone-Management: der sinnvolle Umgamg mit existierenden Klonen.

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 es richtig machen will, muss sicherstellen, dass keine wichtigen Änderungen ungetestet bleiben. Die Test-Gap-Analyse hilft uns ungetestete Änderungen zu finden.

Mit einem Software-System wächst auch die Anzahl automatisierter Tests. Wir sehen immer öfter Test-Suites, die Stunden oder Tage laufen. Das ist lähmend langsam. Um trotzdem sehr schnelles Feedback für die meisten neuen Fehler zu bekommen, kann man einen Teil der Tests häufiger ausführen. Wenn diese Teilmenge gut gewählt ist, findet sie einen Großteil der Fehler in sehr kurzer Zeit.

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

Quellcode zu kopieren und an anderer Stelle wieder einzufügen ist eine gängige Vorgehensweise in der Softwareentwicklung, die jedoch gravierende Nachteile haben kann. Erfahren Sie mehr über von Code-Klonen verursachte Probleme und wie Sie die Risiken duplizierten Codes für Ihr System reduzieren können.

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

Um langfristig erfolgreich zu sein, müssen Softwaresysteme fortlaufend angepasst und weiterentwickelt werden. Qualität kommt dabei oft zu kurz, obwohl sie für die Zukunftssicherheit des Systems entscheidend ist. Wird die Migration in die Cloud funktionieren? Ist die Architektur für die Anbindung einer mobilen App gerüstet? Müssen Teile neu geschrieben werden? Oder gar das ganze System? Ein Softwareaudit hilft bei der Beantwortung dieser Fragen, indem es Transparenz bzgl. des aktuellen Qualitätsstands schafft. Damit wird es möglich, ein strukturiertes Vorgehen für die Zukunft abzuleiten.

Most errors in long-lived software occur in code areas that change a lot. To do things right, you have to make sure that no important changes go live untested. Test Gap analysis helps us to find untested changes.

As software systems grow, so does the number of their automated tests. As a result, we increasingly often encounter test suites that run hours or days, which is painfully slow. To get fast feedback about new bugs despite slow tests, we can run a subset of all tests more frequently. If this subset is chosen well, these tests identify most bugs very quickly.

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

In den letzten Jahrzehnten wurden viele Werkzeuge zur statischen Analyse entwickelt. Passend konfiguriert schaffen diese Transparenz über technische Schulden und Qualitätsdefizite. Allerdings verbessert ein solches Werkzeug nicht eine einzige Codezeile. Deshalb hat eine bloße Einführung von statischer Analyse häufig keinen oder nur einen kurzfristigen Effekt. Dieser Vortrag stellt Praxiserfahrungen aus der Einführung von statischen Analysewerkzeugen vor, die wir in den letzten Jahren in dutzenden Kundenprojekten gemacht haben – unter anderem bei der Munich Re.

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

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

Mit einem Software-System wächst auch die Anzahl automatisierter Tests. Wir sehen immer öfter Test-Suites, die Stunden oder Tage laufen. Das ist lähmend langsam. Um trotzdem sehr schnelles Feedback für die meisten neuen Fehler zu bekommen, kann man einen Teil der Tests häufiger ausführen. Wenn diese Teilmenge gut gewählt ist, findet sie einen Großteil der Fehler in sehr kurzer Zeit.

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

Many test suites test both too much and too little. Too much, since some tests are redundant (but still expensive to execute and maintain). Too little, since important functionality remains untested. In this talk, I present test intelligence analyses that harness data from the development process to help you optimize your Robot Framework tests.

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.

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

Softwareentwicklung soll möglichst schnell vonstattengehen und gleichzeitig auch qualitativ möglichst hochwertige Software produzieren. Code Reviews sind schon lange ein ausgereiftes Konzept zur Qualitätssicherung im Softwareentwicklungsprozess. Trotzdem beobachten wir, dass sie oft nicht eingesetzt werden, da sie als zu zeitaufwendig oder irrelevant gelten. Aber sind sie das wirklich? Was leisten Code Reviews? Welche Probleme decken sie auf? Wir haben mehr als 16 Jahre Code-Review-Historie aus der Entwicklung unseres Produkts Teamscale unter die Lupe genommen. In diesem Vortrag teilen wir unsere Erkenntnisse aus dieser Analyse.

Je älter und größer Softwaresysteme sind, desto wichtiger ist eine verlässliche, automatisierte Testsuite. Da die Suite (und deren Ausführungsdauer) jedoch mit wächst, kommt ihr Feedback immer später, was das Lokalisieren von Fehlern erschwert. Eine wirksame Lösung ist, eine Teilmenge der Tests häufiger auszuführen. Zur Auswahl einer solchen Teilmenge haben wir Pareto-Testing und die Test-Impact-Analyse entwickelt. Im Vortrag stellen wir beide Ansätze vor und berichten vom Einsatz bei der Bayerischen Versorgungskammer, wo wir sie auf der großen automatisierten Testsuite eines komplexen Softwaresystems angewendet und verglichen haben.