Regressionstest (englisch Regression Testing) prüft, ob eine Änderung an der Software bereits vorhandene Funktionen beschädigt hat. Regression bedeutet Rückfall: Ein Fehler, der eigentlich behoben war, taucht durch eine Codeänderung wieder auf — genau das soll der Regressionstest verhindern.
Wann Regressionstests laufen
- Nach jedem Bugfix, um sicherzustellen, dass die Korrektur nichts anderes zerstört hat.
- Nach Refactoring: Umstrukturierung darf das Verhalten nicht ändern — Refactoring ohne Regressionstests ist riskant, denn erst wenn die Tests nach dem Umbau wieder grün sind, war die Umstrukturierung erfolgreich.
- Nach neuen Features, weil neue Codepfade bestehende Logik beeinflussen können.
- Automatisiert in der CI/CD-Pipeline bei jedem Commit (Retest der betroffenen Bereiche) oder als vollständige Suite vor einem Release.
Selektiv oder komplett
Bei großen Systemen ist die komplette Suite oft zu langsam. Dann wählt man selektive Regressionstests: Alle Tests, die von der Änderung betroffene Module und deren Schnittstellen abdecken. Ergänzend sichern Smoke-Tests die kritischsten Kernabläufe ab. Eine hohe Unit-Test-Abdeckung hält den Regressionstest-Aufwand klein, weil Fehler dort sofort und präzise lokalisiert werden.
Abgrenzung
Ein Retest wiederholt genau den Testfall, der den ursprünglichen Fehler fand — der Regressionstest geht darüber hinaus und prüft das gesamte Umfeld. Das Zusammenspiel neuer und alter Module testet der Integrationstest.
Verwandte Grundlagen: Testen (Überblick), Versionierung, Bug, CI/CD.