Wenn ein System wächst, wächst auch die Anzahl automatisierter Tests. Wir sehen immer öfter Test-Suiten, die Stunden oder Tage laufen. Das ist lähmend langsam. Wenn die Ausführung aller Tests zu lange dauert, kann man einen Teil der Tests häufiger ausführen als den Rest. Der Schlüssel ist, diese Teilmenge so zu wählen, dass sie in einem Bruchteil der Zeit einen Großteil der Fehler findet. Im Vortrag stellen wir verschiedene Ansätze hinsichtlich Kosten, Nutzen und Anwendbarkeit und Erfahrungen aus Forschung und Praxiseinsatz vor.

Zielpublikum: Entwickler:innen, Tester:innen, Verantwortliche für Entwicklung und Test
Voraussetzungen: Interesse an Software-Test
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Mit dem Alter und der Größe eines Softwaresystems steigt typischerweise der Bedarf für ausgiebige und qualitativ hochwertige Software-Tests. Zudem werden für mehr Anwendungscode auch mehr Tests benötigt. Damit steigt die Ausführungszeit der Tests.
In der Praxis führt das immer häufiger zu Test-Suiten, die Stunden bis Tage brauchen, um einmal zu laufen. Das bringt eine Reihe von Problemen mit sich. Für die Entwickler bedeutet es, dass sie Feedback für den geänderten Code erst eine lange Zeit, nachdem sie die Änderungen gemacht haben, bekommen. Das macht es deutlich schwieriger, die Fehler im Code zu finden und zu beheben. Außerdem werden moderne Verfahren, wie zum Beispiel Continuous Integration dadurch deutlich erschwert. All das mindert den Wert der Tests ausgerechnet für die Systeme, in denen sie absolut essenziell sind, nämlich große komplexe Software-Systeme.
Eine naheliegende Lösung für das Problem ist es, einen Teil der Tests häufiger auszuführen, als den Rest. Die Herausforderung dabei ist, diese Teilmenge an Tests so zu bestimmen, dass man möglichst viel Zeit einsparen kann, ohne die Fähigkeit der Tests, Fehler zu finden, erheblich zu mindern. Um das zu erreichen, gibt es verschiedene Ansätze, von denen jeder Vor- und Nachteile mit sich bringt.
Ein Ansatz ist die Test-Suite-Minimierung. Dabei werden verschiedene Kriterien verwendet, wie testfallspezifische Coverage [1] und Ausführungszeit, um ein Subset von Tests zu wählen, das in einem Bruchteil der Zeit einen Großteil der Fehler finden soll. [2] Ziel dieses Verfahrens ist es, eine Liste von Tests zu wählen, die jeden Tag oder öfter ausgeführt werden kann, um schnelleres Feedback zu ermöglichen. Die vollständige Test-Suite sollte dennoch in regelmäßigen Abständen ausgeführt werden.
Der zweite Ansatz, den wir betrachten, ist die Test-Impact-Analyse. Dabei werden Testfälle aussortiert, die bei ihrer nächsten Ausführung höchstwahrscheinlich keine Fehler finden. Die Annahme, dass ein Testfall beim nächsten Testlauf keinen Fehler findet, begründen wir durch die Änderungen seit dem letzten Testlauf. Ein Test, der keinen Code abdeckt, der seit dem letzten Mal geändert wurde, wird voraussichtlich auch keinen neuen Fehler finden. Zudem werden die Testfälle so sortiert, dass innerhalb der kürzest möglichen Zeit eine möglichst hohe Code Coverage erreicht wird. [3]
Im Vortrag gehen wir auf die Vor- und Nachteile der beiden Verfahren ein und präsentieren unsere Erfahrungen aus Forschung und Praxis.

Weiterführende Literatur
[1] F. Dreier, Obtaining Coverage per Test Case, Masterarbeit (2017)
[2] R. Noemmer, Conception and Evaluation of Test Suite Minimization Techniques for Regression Testing in Practice, Masterarbeit (2019)
[3] E. Juergens, D. Pagano, Test-Impact-Analyse: Fehler früh erkennen trotz großer, langlaufender Test-Suites, OBJEKTspektrum 06/2018,
[4] J. Rott, R. Niedermayr, E. Juergens, D. Pagano, Ticket Coverage: Putting Test Coverage into Context, Proceedings of the 8th Workshop on Emerging Trends in Software Metrics (2017)
[5] E. Juergens, D. Pagano, Haben wir das Richtige getestet? Erfahrungen mit Test-Gap-Analyse in der Praxis, Whitepaper (2016)
[6] R. Noemmer, R. Haas, An Evaluation of Test Suite Minimization Techniques, International Conference on Software Quality (2020)