Was ist Regression Testing?

Was ist Regression Testing?

Regression Testing (Regressionstest) bedeutet, bestehende Tests nach einer Änderung erneut auszuführen, um zu bestätigen, dass zuvor funktionierende Funktionen weiterhin funktionieren. Eine Regression ist ein Rückschritt: Etwas, das gestern bestanden hat, schlägt heute fehl. Bugfixes, neue Features, Refactorings, Abhängigkeits-Updates und Konfigurationsänderungen können sie auslösen. Der Regressionstest fängt diese ungewollten Brüche ab, bevor sie Nutzer erreichen.

Eine ausgereifte Regressionssuite wird zum ausführbaren Gedächtnis eines Produkts: Jeder ausgelieferte Fehler hinterlässt einen Test, der ihn reproduziert, sodass derselbe Bug nicht unbemerkt zurückkehrt. Neben dem Load Testing ergänzt er die Pipeline: Funktionale Regressionstests prüfen die Korrektheit, Performance-Regressionstests die Geschwindigkeit.

Warum Regressionen entstehen

• Gemeinsam genutzter Code. Eine Hilfsfunktion oder Datenbankspalte wird von mehr Modulen verwendet, als der Autor ahnt, also wirkt eine "lokale" Änderung weiter.
• Unvollständige Fixes. Die Korrektur deckt den gemeldeten Fall ab, bricht aber einen Randfall oder bringt einen alten Fehler zurück.
• Refactoring. Das Verhalten soll gleich bleiben, doch feine Unterschiede schleichen sich ein, etwa bei Reihenfolge, Null-Werten und Fehlerpfaden.
• Abhängigkeiten und Umgebung. Ein Update von Bibliothek oder Runtime kann Standardwerte ändern, APIs entfernen oder die Performance verschieben.
• Merge-Konflikte. Zwei Änderungen, die einzeln bestehen, können zusammen auf dem Main-Branch brechen.

Was Regression Testing abdeckt

Regression Testing ist keine einzelne Technik, sondern ein Zweck: Jeder Test kann diese Rolle übernehmen, sobald er bereits verifiziertes Verhalten absichert. Typisch sind:

• Zentrale Nutzerabläufe wie Registrierung, Login, Checkout und Suche.
• Geschäftsregeln wie Preise, Steuern, Berechtigungen und Rabatte.
• Bug-Reproduktionen für jeden bereits behobenen Fehler.
• Schnittstellen und APIs, bei denen eine Vertragsänderung externe Nutzer bricht.
• Nicht-funktionales Verhalten wie Antwortzeit, Durchsatz und Fehlerrate unter Last.

Arten von Regression Testing

• Unit-Regression. Schnelle, isolierte Tests einzelner Funktionen; sie bilden die Basis der meisten Suiten.
• Integrationsregression. Prüft, ob Module, Services und Datenbank nach einer Änderung weiter zusammenspielen.
• System- und End-to-End-Regression. Steuert die ganze Anwendung, oft über den Browser, und prüft komplette Nutzerabläufe.
• Visuelle Regression. Vergleicht Screenshots, um ungewollte CSS- oder Layoutänderungen zu finden.
• Performance-Regression. Wiederholt einen Lasttest gegen einen neuen Build und vergleicht Latenz, Durchsatz und Fehlerrate mit einer Baseline.

Regression Testing vs. Retesting

Retesting (Bestätigungstest) führt genau den fehlgeschlagenen Fall erneut aus, um zu prüfen, ob ein Bug behoben ist. Regression Testing führt die umgebende Suite aus, um zu prüfen, ob der Fix etwas anderes gebrochen hat. Retesting ist eng und gezielt, Regression Testing breit und vorbeugend. Gute Teams machen nach jedem Fix beides.

Wann Regressionstests laufen sollten

1. Bei jedem Pull Request. Erst wenn die Suite besteht, wird gemergt.
2. Bei jedem Commit auf den Main-Branch. So fallen Integrationsprobleme gleichzeitiger Änderungen auf.
3. Nach Bugfixes und Refactorings.
4. Vor jedem Release. Ein vollständiger Durchlauf ist die letzte Hürde vor der Produktion. Ein kurzer Smoke-Test nach dem Deployment bestätigt, dass die Grundfunktionen antworten.
5. Nach Zeitplan. Langsame Prüfungen wie Browser- und Performance-Tests laufen oft nachts.

Strategien zur Testauswahl

• Alles erneut testen. Die sicherste Variante, solange die Suite schnell ist.
• Selektive Regression. Nur Tests, die den geänderten Code und seine Abhängigen berühren; schneller, aber mit Restrisiko bei unvollständiger Zuordnung.
• Priorisierte Regression. Riskante und häufig fehlschlagende Tests laufen zuerst.

Viele Teams kombinieren: eine selektive, priorisierte Auswahl pro Pull Request und den vollen Lauf nachts und vor dem Release.

Manuell vs. automatisiert

Regressionstests wiederholen sich ständig und sind deshalb der beste Kandidat für Automatisierung. Manuelles Testen bleibt sinnvoll für exploratives Testen, brandneue Features und Usability-Urteile. Faustregel: Automatisieren Sie jede Prüfung, die sich wiederholen wird.

Regressionssuiten in CI/CD

Eine Regressionssuite gehört in die CI/CD-Pipeline: Bei jedem Push baut die Pipeline die Anwendung und führt die Tests aus, ein Fehlschlag blockiert Merge oder Deployment. Damit das funktioniert, muss die Suite schnell genug sein, damit Entwickler warten, deterministisch, damit Rot immer ein echtes Problem bedeutet, und parallelisiert. Läuft sie eine Stunde oder ist sie unzuverlässig, wird sie ignoriert.

Performance-Regressionstests

Funktionale Tests zeigen, dass Features die richtigen Antworten liefern, sagen aber nichts über Tempo. Ein Build kann alle Tests bestehen und trotzdem die Antwortzeit verdoppeln. Performance-Regressionstests führen deshalb denselben Lasttest gegen Baseline und neuen Build aus und vergleichen p95, p99, Durchsatz und Fehlerrate. Überschreitet ein Wert die vereinbarte Schwelle, scheitert der Build.

Mit k6 lässt sich das über Thresholds wie http_req_duration: ['p(95)<800'] direkt festlegen; ein verletzter Threshold setzt einen Exit-Code ungleich null, und die CI erkennt die Regression automatisch. Ein Lauf aus mehreren Regionen kann zudem Regressionen in geografisch verteilten Pfaden wie DNS, Edge-Caching und Regional-Failover aufdecken; Load Testing mit LoadFocus läuft aus über 25 Cloud-Regionen. Geplantes API-Monitoring (API-Monitoring bei LoadFocus) trägt dieselbe Idee in die Produktion. Ein Praxisbeispiel liefert der Beitrag Performance-Regression mit automatisierten Tests erkennen, den Vergleich zweier Läufe erklärt die Anleitung zum Baseline-Vergleich. Erstes Warnsignal ist meist die Latenz.

Best Practices und Herausforderungen

• Jeder Bug wird ein Test. Fix und reproduzierender Test landen in derselben Änderung.
• Flaky Tests konsequent bekämpfen. Ein Test, der ohne Codeänderung mal besteht und mal nicht, bringt das Team dazu, Fehler zu ignorieren.
• Die Suite schnell halten. Parallelisieren, bei Pull Requests selektiv testen, den vollen Lauf für nachts und vor dem Release aufheben.
• Überflüssige Tests löschen. Redundante und veraltete Tests verlangsamen die Suite.
• Performance einbeziehen. Lastbasierte Prüfungen in der CI fangen schleichende Verlangsamung ab.

Häufige Fragen zu Regression Testing

Was ist das Hauptziel von Regression Testing?

Es soll bestätigen, dass aktuelle Änderungen bestehende, zuvor funktionierende Funktionen nicht gebrochen haben, und unbeabsichtigte Nebenwirkungen von Fixes, Features, Refactorings und Updates vor den Nutzern finden.

Was ist der Unterschied zwischen Regression Testing und Retesting?

Retesting wiederholt den fehlgeschlagenen Fall, um einen Fix zu bestätigen. Regression Testing wiederholt die breitere Suite, um sicherzugehen, dass der Fix nichts anderes gebrochen hat.

Wie oft sollten Regressionstests laufen?

Idealerweise bei jedem Pull Request und jedem Commit auf Main über eine CI/CD-Pipeline, dazu ein vollständiger Lauf vor jedem Release. Aufwendige Prüfungen wie Browser- und Performance-Tests laufen oft nachts.

Lässt sich Regression Testing vollständig automatisieren?

Funktionale, Integrations-, visuelle und Performance-Regression werden fast immer automatisiert. Manuelle Tests bleiben für exploratives Testen und neue Features ohne stabile Automatisierung nützlich.

Was ist Performance-Regressionstesting?

Ein Lasttest wird gegen jeden neuen Build wiederholt und Latenz, Durchsatz und Fehlerrate werden mit einer Baseline verglichen. Verschlechtert sich ein Wert über die Schwelle, scheitert der Build.

Warum werden Regressionstests flaky?

Meist durch Timing-Annahmen, geteilte Testdaten und instabile externe Dienste. Das ist ein Problem, weil zufällig fehlschlagende Tests das Vertrauen in die ganze Suite untergraben.