Was ist ein Regressionstest?
Ein Regressionstest prüft nach einer Änderung an einer Software, ob bisher funktionierendes Verhalten weiterhin fehlerfrei arbeitet. Der ISTQB-Lehrplan formuliert es nüchtern: Der Regressionstest bestätigt, dass eine Änderung, einschließlich einer bereits getesteten Fehlerbehebung, keine nachteiligen Folgen hat. Diese Folgen können die geänderte Komponente selbst treffen, andere Komponenten desselben Systems oder sogar verbundene Systeme. Auch die Umgebung gehört dazu: Ein Update des Betriebssystems oder der Datenbank kann dieselben Effekte auslösen wie eine Codeänderung.
Der Name sagt schon, worum es geht. Regression heißt Rückschritt: Etwas, das funktioniert hat, funktioniert plötzlich nicht mehr. Solche Fehler entstehen selten dort, wo gerade gearbeitet wurde, sondern in den Seiteneffekten daneben. Genau deshalb reicht es nicht, nur die Änderung selbst zu testen.
Eine Einordnung noch, weil sie oft schiefgeht: Der Regressionstest ist keine eigene Teststufe. Er reiht sich nicht hinter Komponententest, Integrationstest, Systemtest und Abnahmetest ein, sondern läuft quer über alle diese Stufen. Überall dort, wo etwas geändert wurde, gehört er dazu.
Wann ein Regressionstest fällig ist
Fünf Auslöser decken die meisten Fälle ab:
- Nach einer Fehlerbehebung. Der Klassiker. Die Korrektur ist getestet, aber hat sie woanders etwas beschädigt?
- Vor einem Release. Der letzte Beleg, dass die gesammelten Änderungen eines Zyklus das Bestehende nicht angetastet haben.
- Nach einem Refactoring. Das Verhalten soll per Definition gleich bleiben. Ob es das tut, weiß man erst nach dem Test.
- Nach dem Update einer Abhängigkeit. Neue Framework-Version, neue Bibliothek, neuer Datenbanktreiber: fremder Code, gleiche Wirkung.
- Nach Änderungen an Konfiguration oder Umgebung. Auch ohne eine einzige geänderte Codezeile kann sich das Systemverhalten verschieben.
Wie viel davon nötig ist, klärt eine Auswirkungsanalyse: Welche Teile der Software könnte die Änderung berühren? Der ISTQB-Lehrplan empfiehlt sie ausdrücklich, bevor der Umfang des Regressionstests feststeht. Ohne diese Analyse bleiben nur zwei schlechte Optionen: zu viel testen oder zu wenig.
Warum Regressionstests teuer werden
Der Aufwand für Regressionstests hat eine unangenehme Eigenschaft: Er wächst schneller als die Änderungen, die ihn auslösen. Geprüft wird ja gerade auch die Funktionalität, die von einer Änderung gar nicht betroffen sein soll. Der Anteil der auszuführenden Tests übersteigt damit schnell den Anteil der geänderten Software. Eine kleine Korrektur, ein großer Testumfang.
Wie sich das in echt anfühlt, hat mir Silke Reimer im Podcast am Beispiel der IVU beschrieben: rund 25.000 Testfälle, ein kompletter Durchlauf von 6,5 Stunden. Dazu bis zu zehn parallel gepflegte Branches, weil mehrere Releases bei Kunden stehen. Eine einzige Fehlerbehebung wandert im Zweifel durch vier oder fünf Branches und löst jedes Mal die volle Suite aus. Selbst zehn große Maschinen im Dauerbetrieb reichten dafür nicht mehr.
Die scheinbar sparsame Alternative, alles nur einmal pro Nacht zu testen, hat ihren eigenen Preis. Schlägt morgens ein Test fehl, beginnt erst die Suche: Welcher der Commits von gestern war es? Diese Analysezeit taucht in keiner Aufwandsschätzung auf und fällt trotzdem jede Woche an.
Regressionstest und Teststufen
Regressionstest und Teststufen liegen auf zwei verschiedenen Achsen: Teststufen beschreiben, wann und von wem getestet wird, der Regressionstest beschreibt, warum erneut getestet wird. Deshalb gibt es ihn auf jeder Stufe. Die Unit-Suite, die nach jedem Commit läuft, ist ein Regressionstest auf Komponentenebene. Der nächtliche End-to-End-Lauf ist einer auf Systemebene. Und die automatisierten Tests, die abgenommene Inkremente absichern, sind einer auf Abnahmeebene.
Der ISTQB-Lehrplan sagt es direkt: Fehlernachtests und Regressionstests sind auf allen Teststufen erforderlich, wenn dort Fehler behoben oder Änderungen vorgenommen wurden. Wer den Regressionstest als eigene Phase am Projektende einplant, hat das Konzept missverstanden und verschenkt seinen größten Vorteil: die schnelle Rückmeldung nah an der Änderung.
Regressionstest vs. Retest
Regressionstest und Retest prüfen zwei verschiedene Fragen und werden trotzdem ständig verwechselt. Der deutsche ISTQB-Lehrplan sagt Fehlernachtest, im Projektalltag heißt es meist Retest oder Nachtest; gemeint ist dasselbe. Der Fehlernachtest bestätigt, dass ein konkreter, zuvor gefundener Fehler tatsächlich behoben ist. Der Regressionstest bestätigt, dass die Behebung an anderer Stelle nichts beschädigt hat. Beide gehören zusammen, in genau dieser Reihenfolge: erst prüfen, ob der Fehler weg ist, dann prüfen, ob dabei etwas Neues kaputtgegangen ist.
Zwei Details aus dem Lehrplan sind praktisch relevant. Vorzugsweise führt dieselbe Person den Fehlernachtest durch, die den Fehler ursprünglich gefunden hat; sie kennt den Weg dorthin am besten. Und wenn Zeit oder Geld knapp sind, darf sich der Fehlernachtest auf die Testschritte beschränken, die die Fehlerwirkung ausgelöst haben. Beim Regressionstest gibt es diese Abkürzung nicht, denn wo die Nebenwirkung sitzt, weiß vorher niemand.
Regressionstest und Testautomatisierung
Regressionstest und Testautomatisierung werden oft in einem Atemzug genannt, sind aber nicht dasselbe. Ein Regressionstest muss nicht automatisiert sein. Er ist nur der dankbarste Kandidat dafür: Regressionstestsuiten laufen viele Male, die Zahl der Testfälle wächst mit jedem Release, und genau diese Wiederholung trägt die Automatisierung wirtschaftlich. Umso bemerkenswerter ist eine Zahl aus der Softwaretest-Umfrage 2024: 12 Prozent der Teilnehmer automatisieren ihre Regressionstests überhaupt nicht.
Automatisierung ist dabei Mittel, nicht Selbstzweck. Bei der Telematik-App der HUK-Coburg lieferte die erste Testautomatisierung grüne Läufe, denen niemand traute: Während die Automatisierung komplett durchlief, fand der manuelle Regressionstest 20 bis 25 kritische Fehler. Das Team stellte die Automatisierung nach vier Jahren komplett ein und setzte neu an. Heute ist rund ein Drittel der etwa 150 Regressionstestfälle automatisiert, mit klarem Ziel und diesmal mit Vertrauen in die Ergebnisse. Ein grüner Regressionslauf, dem niemand traut, sichert nichts ab.
Wie Testautomatisierung generell aufgesetzt wird, wie die Testautomatisierungspyramide dabei hilft und wo sich Automatisierung lohnt, ist ein eigenes Thema mit einer eigenen Seite. Hier geht es um die Frage davor: Welche Tests müssen nach einer Änderung überhaupt erneut laufen?
Testfallauswahl: Full, Selective und Prioritized Regression Testing
Für diese Frage gibt es drei Strategien:
Full Regression Testing führt bei jeder Änderung die komplette Suite aus. Das ist die sicherste Variante und für kleine Suiten völlig in Ordnung. Ab einer gewissen Größe wird sie unbezahlbar, siehe die 6,5 Stunden oben.
Selective Regression Testing führt nur die Testfälle aus, die von der Änderung tatsächlich betroffen sind. Voraussetzung ist Wissen darüber, welcher Testfall welche Teile der Software nutzt. Genau das ist Testfallselektion.
Prioritized Regression Testing ordnet die Testfälle nach Risiko, Fehlerhistorie oder Nutzungshäufigkeit, damit wahrscheinliche Fehlschläge früh sichtbar werden. Das ergänzt die Selektion, wenn auch die reduzierte Suite noch lange läuft.
Was Selektion leisten kann, zeigt der IVU-Fall aus dem Podcast. Ein nächtlicher Lauf protokolliert, welche Dateien, Klassen und Funktionen jeder Testfall öffnet. Bei jedem Check-in laufen dann nur die Testfälle, die von den geänderten Dateien betroffen sind, vollautomatisch und über die Sprachgrenze zwischen C++ und Java hinweg. Die Selektion spart 50 bis 60 Prozent aller Testfälle ein:
| Vorher | Nachher (im Mittel) | |
|---|---|---|
| Java-Seite | 2,5 Stunden | 1 Stunde, oft 10 bis 15 Minuten |
| C++-Seite (Selektion auf Funktionsebene) | 4 bis 4,5 Stunden | 10 bis 15 Minuten |
| Eingesparte Testfälle | 50 bis 60 Prozent |
Der wichtigste Schritt war allerdings nicht die Technik, sondern die Validierung. Über vier bis sechs Wochen lief die komplette Suite parallel weiter, während protokolliert wurde, was die Selektion ausgewählt hätte. Das Ergebnis: kein einziger übersehener echter Fehlschlag. Erst dieser Beleg hat dem Verfahren das Vertrauen des Teams eingebracht.
Für die Priorisierung liefert Process Mining eine Datengrundlage, die Bauchgefühl ersetzt. Produktionsdaten zeigen, welche Workflows wie oft tatsächlich durchlaufen werden. In einem Fall aus dem Podcast hatte der aufwendigste Workflow über 600 verschiedene Durchläufe, aber die Top 10 deckten rund 80 Prozent aller Produktionsdurchläufe ab. Wer Testfälle für diese zehn hat, deckt das reale Geschehen ab und kann belegen, warum er auf die übrigen 590 verzichtet.
Visuelle Regressionstests
Ein visueller Regressionstest vergleicht Screenshots der Benutzungsoberfläche mit zuvor freigegebenen Referenzbildern und schlägt an, wenn sich das Erscheinungsbild unbeabsichtigt ändert. Er findet Fehler, an denen funktionale Tests vorbeilaufen: ein verrutschtes Layout, ein überdeckter Button, eine unlesbare Schrift auf neuem Hintergrund. Der funktionale Test bleibt grün, die Seite ist trotzdem kaputt.
Werkzeugseitig lohnt ein genauer Blick. Playwright bringt visuelle Regressionstests in der TypeScript-Version direkt im Testrunner mit, inklusive Diff-Images. Die Python-Version braucht dafür externe Bibliotheken, die teilweise nicht mehr aktiv gepflegt werden. Solche Unterschiede entscheiden mit, welche Variante zum eigenen Team passt.
Werkzeuge
Das Werkzeugspektrum ist dasselbe wie beim automatisierten Testen insgesamt, weil Regressionstests auf allen Ebenen laufen: Playwright, Selenium und Cypress für die Benutzungsoberfläche, REST-assured oder Postman auf API-Ebene, dazu die Unit-Test-Frameworks der jeweiligen Sprache. Mit keyword-getriebenen Ansätzen wie dem Robot Framework schreiben auch nicht-technische Tester ihre Regressionstestfälle selbst.
Entscheidend ist weniger das einzelne Werkzeug als die Einbettung. Regressionstests entfalten ihren Wert erst, wenn sie in der CI-Pipeline bei jeder Änderung laufen, nicht als Sonderaktion vor dem Release. Je näher der Test an der Änderung, desto billiger der gefundene Fehler.
Aus der Praxis
Beim Thema Regressionstest bin ich vor allem der, der zuhört. In meinen Podcasts erzählen mir seit Jahren Praktikerinnen und Praktiker, wie sie ihre Testsuiten im Griff behalten, und zwei dieser Gespräche haben meinen Blick auf das Thema geprägt.
Silke Reimer hat in der Folge “Automatische Testfallselektion für Regressionstests” beschrieben, wie die IVU ihre 6,5-Stunden-Suite auf Minuten gebracht hat. Hängen geblieben ist bei mir weniger die Technik als der Umgang mit der Skepsis im Team: wochenlanger Parallelbetrieb, volle Suite gegen Selektion, bis die Zahlen für sich sprachen. Felix Doppel erzählte in “Testautomatisierung von Mobile Apps” die Gegengeschichte von der HUK-Coburg: eine Automatisierung, die grün leuchtete, während die manuellen Regressionstester die kritischen Fehler fanden. Sein Team hatte den Mut, vier Jahre Arbeit einzustellen und neu anzufangen.
Beide Geschichten erzählen im Kern dasselbe. Ein Regressionstest ist so viel wert wie das Vertrauen, das ein Team in ihn hat. Und dieses Vertrauen entsteht nicht durch das Versprechen eines Werkzeugs, sondern durch Belege: einen Parallellauf, nachvollziehbare Zahlen, gefundene Fehler. Wer seinen Regressionstest aufbaut, baut immer beides: die Testfälle und das Vertrauen in sie.