Warum Regressionstests heute entscheidend sind

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 Ihr 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 Sie nie angefasst haben – 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 Prü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 Sie erneut ausführen: 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 Sie absichern: 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 Nutzerwege 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 Sie unsichtbaren Brüche ab: ein verlorenes Label, eine noindex-Regel, die mit einer Staging-Konfiguration live ging.

Wo Ihre Testsuite aufhört

Alle obigen Arten testen den Code, den Sie kontrollieren, in dem Moment, in dem Sie ihn ändern. Ihre 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 Ihr Repository, also löst nichts davon Ihre 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 Prüfungen in der Produktion: dieselbe Regressionstest-Disziplin, nur auf die laufende Website gerichtet statt auf den Build. Die Baseline ist das, was Ihre 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 Ihr Repository nie geöffnet haben.

Was fortlaufend zu prüfen ist, der Reihe nach

Beginnen Sie beim Weg des Geldes. Eine End-to-End-Prüfung der Strecke, die 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 sie als Checkout-Monitoring 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änzen Sie 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ützen Sie zuerst, was am lautesten kaputtgeht, und erweitern Sie dann. Eine kleine Menge Prüfungen, die tatsächlich laufen, schlägt eine umfassende Suite, die niemand pflegt – und anders als eine Testsuite behalten Prüfungen in der Produktion ihren Wert auch dann, wenn die Änderung von außerhalb Ihres Repositories kam.

Wenn Sie gar keine Testsuite haben

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

Von dort arbeiten Sie sich nach innen. Wenn eine Produktionsprüfung eine Regression findet, ist genau dieses Verhalten es wert, mit einem Unit- oder Integrationstest festgenagelt zu werden – geschrieben mit dem Fehler vor Augen. Ihre 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.