Warum Regressionstests entscheidend sind – heute mehr denn je

Was Regressionstests wirklich sind

Ein Regressionstest prüft nach einer Änderung erneut ein Verhalten, das bereits funktioniert hat. Er ist das Gegenteil eines Tests für eine neue Funktion: Niemand hat darum gebeten, dass sich der Checkout ändert – verhält er sich nach dem heutigen Release anders, ist genau dieser Unterschied der Befund.

Er ist auch nicht dasselbe wie ein Nachtest. Ein Nachtest bestätigt, dass ein bestimmter Fehler behoben ist. Der Regressionstest stellt die größere Frage, die diese Behebung aufwirft: Was hat die Änderung sonst noch berührt? Eine einzeilige Korrektur an einer Versandregel kann eine Summe verschieben, eine Template-Änderung ein Formularfeld entfernen, ein Dependency-Update die Interpretation eines Datums verändern.

Auslöser ist jede Änderung, nicht nur dein eigener Code: ein Plugin- oder Paket-Update, eine Konfigurations- oder Umgebungsänderung, ein CDN- oder DNS-Wechsel, ein Drittanbieter-Skript, das sich selbst aktualisiert, im CMS bearbeitete Inhalte. Jede davon kann Verhalten verändern, das du nie angefasst hast – deshalb sind Regressionstests eine fortlaufende Gewohnheit und kein Ereignis am Release-Tag.

Warum sie heute wichtiger sind

Generative KI hat die Ökonomie des Programmierens verändert. Ein Feature, das einen Tag brauchte, braucht eine Stunde; ein Refactoring, für das nie Zeit war, passiert nebenbei. Unverändert ist die Anforderung, dass das Ergebnis korrekt sein muss – und der Fehlermodus eines KI-Assistenten gleicht dem eines Menschen nicht. Er zögert nicht, bleibt nicht stecken, hinterlässt kein TODO. Er liefert etwas Plausibles, Vollständiges und Flüssiges, ob es nun stimmt oder nicht.

Das zeigt sich sehr konkret. Modelle erfinden Dinge, die es nicht gibt: Eine Untersuchung zu Paket-Halluzinationen fand, dass rund jedes fünfte von codegenerierenden Modellen empfohlene Paket nicht existierte – zugleich ein Fehler und ein Lieferketten-Risiko, denn ein Angreifer kann den erfundenen Namen registrieren. Sie schreiben außerdem mehr um als gefragt: GitClears Analyse hunderter Millionen geänderter Zeilen beschreibt steigende Duplizierung und sinkendes Refactoring – die Signatur von Code, der hinzugefügt statt neu geordnet wird.

Gefährlich ist die Wahrnehmungslücke. In einer randomisierten Studie von METR waren erfahrene Open-Source-Entwickler in ihren eigenen Repositories mit KI-Unterstützung messbar langsamer – während sie glaubten, deutlich schneller gewesen zu sein. Genau dann, wenn es sich schnell anfühlt, wird die Überprüfung übersprungen, und Googles DORA-Forschung bringt steigende KI-Nutzung mit sinkender Auslieferungsstabilität in Verbindung. Tempo ohne Sicherheitsnetz ist der Weg, auf dem eine stille Regression bei Kunden landet.

Hinzu kommt ein Effekt zweiter Ordnung: Immer mehr Code im Repository hat niemand im Team von Hand geschrieben, und er wird in größeren Diffs geprüft, als irgendwer aufmerksam liest. Institutionelles Gedächtnis – „Vorsicht, diese Funktion trägt das halbe System“ – dünnt aus. Automatisierte Regressionstests sind das, was dieses Gedächtnis ersetzt.

Die Arten von Regressionstests

Regressionstest ist nicht eine einzige Technik. Die klassischen Arten beschreiben, wie viel du erneut ausführst: Unit-Regression wiederholt nur die Tests rund um die geänderte Einheit, isoliert. Partielle (selektive) Regression wiederholt die geänderte Einheit plus alles, was davon abhängt, ausgewählt per Impact-Analyse – der übliche Standard, weil das schnell genug für jeden Commit ist. Vollständige Regression wiederholt alles und bleibt großen oder riskanten Änderungen vorbehalten: einem Framework-Upgrade, einer Plattform-Migration, einem langlebigen Branch, der endlich gemergt wird. Retest-all ist die Brachialvariante: die gesamte Suite laufen lassen, Änderung hin oder her, meist nach Zeitplan statt pro Commit.

Zwei weitere beschreiben, welche Art von Änderung du absicherst: Korrektive Regression wiederholt bestehende Tests unverändert, weil sich der Code geändert hat, die Spezifikation aber nicht. Progressive Regression passt zuerst die Tests an, weil sich die Spezifikation selbst bewegt hat – neues Verhalten ist erwünscht, und es geht darum zu bestätigen, dass sich außerhalb davon nichts mitbewegt hat.

Dann gibt es die Schichten, und die zählen mehr als die Etiketten. Funktionale und End-to-End-Regression fährt echte Nutzerabläufe ab – in den Warenkorb legen, zur Kasse gehen, bezahlen, die Bestätigung erhalten – und ist die einzige Schicht, die beweist, dass das Geschäft noch läuft. API- und Contract-Regression fixiert die Form einer Antwort, damit ein Feld, das still seinen Typ wechselt, auffällt, bevor Konsumenten brechen. Visuelle Regression vergleicht gerenderte Pixel mit einer freigegebenen Baseline und findet, was eine DOM-Assertion nie sieht: ein zusammenbrechendes Layout, eine fehlschlagende Schrift, ein verschwundenes Bild. Struktur-Drift arbeitet eine Ebene tiefer am DOM und findet, was Pixel übersehen – etwa ein Tracking-Skript oder ein Formularfeld, das verschwunden ist, ohne das Bild zu verändern. Performance-Regression vergleicht Zeiten mit einer Baseline, denn eine Seite, die noch funktioniert, aber jetzt vier Sekunden braucht, ist eine echte Regression. Daten- und Schema-Regression prüft Migrationen und Auswertungen erneut gegen bekannte Eingaben. Barrierefreiheits- und SEO-Regression fangen die für dich unsichtbaren Brüche ab: ein verlorenes Label, eine noindex-Regel, die mit einer Staging-Konfiguration live ging.

Wo deine Testsuite aufhört

Alle obigen Arten testen den Code, den du kontrollierst, in dem Moment, in dem du ihn änderst. Deine Live-Website besteht aus weit mehr: automatischen Plugin- und Paket-Updates, einem Theme-Update, einem Zahlungsanbieter, der sein Embed ändert, einem Drittanbieter-Skript, das sich nachts selbst aktualisiert, einer CDN-Regel, einem PHP- oder Node-Versionssprung des Hosters, in Eile bearbeiteten Inhalten.

Nichts davon berührt dein Repository, also löst nichts davon deine Tests aus – und all das hat schon produktive Websites zerstört. Der häufigste Fehler, den wir sehen, ist überhaupt kein schlechtes Deployment: Es ist ein WordPress- oder WooCommerce-Plugin, das sich um drei Uhr nachts selbst aktualisiert und den Checkout verändert, auf einer Website, deren Code in dieser Woche unverändert blieb. Eine grüne CI-Pipeline schweigt zu jedem einzelnen dieser Fälle.

Genau diese Lücke füllen fortlaufende Tests in der Produktion: dieselbe Regressionstest-Disziplin, nur auf die laufende Website gerichtet statt auf den Build. Die Baseline ist das, was deine Website gestern getan hat; der Befund ist das, was sich heute geändert hat – ganz gleich, wer es geändert hat, einschließlich der Menschen und Roboter, die dein Repository nie geöffnet haben.

Was fortlaufend zu prüfen ist, der Reihe nach

Beginne beim Weg des Geldes. Ein End-to-End-Test des Ablaufs, der die Rechnungen bezahlt – in den Warenkorb, zur Kasse, Bestellung ausgelöst, Bestätigungsmail erhalten – ist mehr wert als hundert Unit-Tests, weil dies der eine Ausfall ist, der pro Stunde Geld kostet. Relvato fährt ihn als Checkout-Monitor gegen den echten Shop, nach Zeitplan und nach jedem Update.

Dann die beiden Darstellungsschichten, die unterschiedliche Hälften eines kaputten Deployments finden: visuelle Regression für das Aussehen der Seite und Struktur-Drift für ihren Aufbau. Ergänze Core Web Vitals, damit eine Tempo-Regression als das behandelt wird, was sie ist, und einen Exposure-Scan, damit ein Schlüssel oder ein Backup, das in einem Build auftaucht, am selben Tag gefunden wird – und nicht von jemand anderem.

Das Ordnungsprinzip ist einfach: Schütze zuerst, was am lautesten kaputtgeht, und erweitere dann. Eine kleine Menge Tests, die tatsächlich laufen, schlägt eine umfassende Suite, die niemand pflegt – und anders als eine Testsuite behalten Tests in der Produktion ihren Wert auch dann, wenn die Änderung von außerhalb deines Repositories kam.

Wenn du gar keine Testsuite hast

Viele Websites, die echtes Geld verdienen, haben keine automatisierten Tests, und der Rat „schreib zuerst eine Testsuite“ sorgt dafür, dass das ein weiteres Jahr so bleibt. Es gibt eine Abkürzung: Fang außen an. Eine Handvoll Monitore in der Produktion kann heute laufen, ohne deinen Code anzufassen, und sie melden innerhalb von Minuten nach einer schlechten Änderung, dass etwas, worauf Kunden angewiesen sind, nicht mehr funktioniert.

Von dort arbeitest du dich nach innen. Wenn ein Monitor in der Produktion eine Regression findet, ist genau dieses Verhalten es wert, mit einem Unit- oder Integrationstest festgenagelt zu werden – geschrieben mit dem Fehler vor Augen. Deine Suite wächst dann aus echten Vorfällen statt aus Vermutungen darüber, was kaputtgehen könnte, und das ist zugleich der günstigste Weg, sie aufzubauen.

Die unbequeme Wahrheit der KI-Ära lautet: Code zu erzeugen ist nicht mehr der Engpass – zu wissen, ob er funktioniert, schon. Regressionstests sind der Weg, das absichtlich herauszufinden, statt es von einem Kunden zu erfahren.