Gestern lief’s doch noch. Muss ich heute schon wieder alles testen?

Je älter und größer ein Softwaresystem ist, desto wichtiger ist eine verlässliche, automatisierte Testsuite. Insbesondere, wenn ich unter Zeitdruck viele Änderungen umsetze und kurze Release-Zyklen habe. Erfolgreiche Software wächst von Release zu Release und damit auch die Anzahl automatisierter Tests. Wir sehen immer öfter Test-Suites, die Tage oder Wochen 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. Der Knackpunkt ist, die “richtigen” Tests auszuwählen. Vor 5 Jahren habe ich hier auf dem Java Forum schon einmal zu diesem Thema präsentiert und mit Test-Impact-Analyse ein solches Verfahren zur Testauswahl vorgestellt. Zu meiner Freude wurde der Vortrag mit dem Best Presentation Award ausgezeichnet, was mich in der Vermutung bestärkt hat, dass zu langsame Tests eine Herausforderung sind, die viele Teams teilen. Mein Eindruck ist sogar, dass die Herausforderung heute noch viel größer ist als damals. In den letzten 5 Jahren konnten wir viel Erfahrung mit Test-Impact-Analyse und anderen Selektionsverfahren sammeln – in der Forschung, bei uns selbst und bei Kunden. Dabei sind wir einerseits auf Grenzen einiger Ansätze gestoßen, andererseits auf einfache, pragmatische Ansätze, die in der Praxis gut funktionieren und sich inzwischen vielfach bewährt haben. Im Vortrag möchte ich einen Überblick über existierende Ansätze geben, Vor- und Nachteile beleuchten und konkrete Empfehlungen vorstellen, wann welcher Ansatz der richtige ist. Und zwar für alle Arten von Tests, von Unit- über System- bis hin zu manuellen Tests.