Regressionstest: Definition, Prozess, Tools & KI-Trends 2026

Ein Regressionstest wiederholt bestehende Testfälle nach einer Änderung. So zeigt sich, ob neuer Code, ein Update oder eine neue Umgebung etwas beschädigt hat, das vorher funktioniert hat.

{{summary}}

Dein Team spielt ein Update aus, alles sieht gut aus. Zwei Stunden später kommen die ersten Beschwerden: Der Warenkorb berechnet keine Rabatte mehr. Der neue Code hat eine alte Funktion mitgerissen, die niemand angefasst hat. Solche Kettenreaktionen fängt ein Regressionstest ab, bevor sie live gehen.

Was ist ein Regressionstest?

Ein Regressionstest ist die Wiederholung bereits bestandener Testfälle nach einer Änderung an der Software. Er prüft, ob alles, was vorher funktioniert hat, weiterhin funktioniert. Auslöser ist jede Anpassung am Code, an der Konfiguration oder an der Infrastruktur. Die Tests laufen automatisiert oder manuell, je nach Testfall und Aufwand.

Der Begriff kommt von „Regression“, also Rückschritt: Eine Funktion fällt hinter einen Stand zurück, den sie schon einmal erreicht hatte. „Regressionstest“ beschreibt damit, warum ein Test läuft. Was er prüft und auf welcher Ebene, lässt der Begriff offen.

Wann brauchst du einen Regressionstest?

Immer dann, wenn sich etwas am Code oder an der Umgebung ändert. Diese sechs Situationen sind typisch:

• Neue Funktion: Verträgt sich der neue Code mit dem bestehenden?
• Geänderte Funktion: Löst die Anpassung an anderer Stelle Fehler aus?
• Behobener Fehler: Hält der Fix, ohne neue Probleme zu schaffen?
• Optimierter Quellcode: Hat die Performance-Optimierung Nebenwirkungen?
• Aktualisierte Bibliotheken: Bricht das Update einer Fremdbibliothek etwas, das vorher lief?
• Neue Umgebung: Läuft alles nach einem Datenbank-, Framework- oder CMS-Update?

In mehreren unserer Projekte aktualisiert ein Werkzeug die Fremdbibliotheken automatisch und laufend. Jedes dieser Updates stößt einen Regressionslauf an. Im Alltag ist das einer der häufigsten Anlässe. Die größten Läufe lösen Plattform-Upgrades aus, etwa der Wechsel auf eine neue Major-Version des CMS. Dann ändert sich viel Code auf einmal, und die Suite muss zeigen, dass Formulare, Suche und Schnittstellen weiterlaufen.

Regressionstest-Beispiel im Unternehmenseinsatz

Nehmen wir einen international tätigen B2B-Hersteller, der sein Shop-System aktualisiert. Damit das Update den Einkauf nicht stört, prüfen Regressionstests die kritischen Abläufe. Funktioniert der Warenkorb noch? Laufen Benutzerkonto und Bestellprozess sauber? Verträgt sich das neue Zahlungsgateway mit der Bestandssoftware? Bleiben Lagerbestände und Benachrichtigungen synchron?

Dazu kommt die Kompatibilität mit verschiedenen Geräten und Browsern. Hier spielen automatisierte Regressionstests ihre Stärke aus. Sie spielen viele Szenarien schnell durch, von der Darstellung auf unterschiedlichen Bildschirmgrößen bis zu komplexen Zahlungsvorgängen. So sinkt das Risiko, dass ein Update mehr Probleme schafft, als es löst. Die User Experience bleibt stabil.

Regressionstest vs. Re-Test, Smoke-Test und Integrationstest

Re-Test, Smoke-Test, Integrationstest und Regressionstest laufen oft kurz nacheinander. Deshalb werden sie gern verwechselt. Die vier Begriffe beantworten aber verschiedene Fragen: Integrationstest beschreibt eine Ebene, Re-Test und Regressionstest einen Anlass, Smoke-Test einen Umfang. Ein Test kann deshalb mehreres zugleich sein.

Ein Vergleich aus dem Haushalt: Rauchmelder, Wasseruhr und Türschloss sind verschiedene Geräte. Die jährliche Wartung ist kein viertes Gerät. Sie ist der Anlass, alle drei zu prüfen. So verhält sich der Regressionstest zu den Testebenen. Ein Integrationstest wird zum Regressionstest, sobald er nach einer Änderung erneut läuft.

Ein Re-Test prüft, ob ein behobener Fehler wirklich weg ist. Gute Entwicklungsteams beginnen jede Fehlerbehebung mit einem automatischen Test, der den Fehler nachstellt. Dieser Test ist zuerst rot. Nach der Behebung wird er grün und bleibt dauerhaft in der Suite. Aus dem Re-Test wird so ein Regressionstest, und derselbe Fehler kann nicht unbemerkt zurückkommen.

Der Smoke-Test ist der Schnellcheck vorab. Er zeigt in wenigen Minuten, ob die kritischen Funktionen laufen. Findet er einen Fehler, lohnt der lange Regressionslauf gar nicht erst. Besteht er, geht der Regressionstest deutlich breiter und tiefer.

Regressionstest oder Abnahmetest?

Explorative Tests und User Acceptance Tests bewerten, ob neue Funktionen fachlich das tun, was das Business braucht. Dafür braucht es Menschen mit Fachwissen. Ein Regressionstest prüft Verhalten, das bereits abgenommen ist. Dazu gehört auch fachliche Logik wie die Rabattberechnung aus dem Beispiel oben. Weil das erwartete Ergebnis feststeht, lässt sich der Regressionstest gut automatisieren.

Wie läuft ein Regressionstest ab?

Einen festen Standardablauf gibt es nicht. Bewährt hat sich eine Trennung in zwei Phasen. Einmal, beim Aufbau der Suite, legst du fest, was automatisiert läuft und mit welchen Werkzeugen. Danach wiederholt sich bei jeder Änderung derselbe Ablauf: Änderung verstehen, Tests auswählen, ausführen und die Ergebnisse einordnen.

Phase 1: einmalig aufbauen

1. Testfälle definieren: Welche Abläufe muss die Suite dauerhaft absichern?
2. Automatisierung festlegen: Was läuft automatisiert, was bleibt manuell?
3. Tools wählen: Das passende Werkzeug je Testfall und Testebene.

Testfälle für neue Funktionen lassen sich direkt aus den Akzeptanzkriterien einer User Story ableiten. Wenn du das von Anfang an machst, baust du die Regressionssuite mit jedem Sprint ein Stück weiter aus.

Phase 2: bei jeder Änderung

1. Änderung verstehen: Was hat sich geändert, und welche Bereiche hängen davon ab?
2. Tests auswählen: Betroffene Tests nach festen Regeln, kritische Kernfunktionen zuerst.
3. Tests ausführen: In der Pipeline oder manuell.
4. Ergebnisse einordnen: Ist ein Fehlschlag ein echter Fehler, und wer ist zuständig?

Ergebnisse einordnen: Rot heißt selten „Produkt kaputt“

Regressionstests laufen meist in einer Testumgebung, nicht auf der Live-Website. Dort hängen viele Systeme zusammen, die teils andere Teams betreuen: Shop-Backend, Kundendaten, Preise. Schlägt ein Test fehl, liegt es deshalb oft nicht am eigenen Code. Häufige Ursachen sind veränderte Testdaten, ein Fremdsystem, das gerade nicht antwortet, oder ein Test, der nicht mehr zum gewollten Verhalten passt.

Den größten Aufwand macht deshalb das Einordnen, weniger das Ausführen. Für jeden Fehlschlag braucht es zwei Antworten: Ist das ein echter Fehler? Und wer ist zuständig? Ohne diesen Schritt gewöhnt sich ein Team an rote Ergebnisse und schaut nicht mehr hin. Dann übersieht es auch den echten Fehler. Wir haben dafür einen eigenen Ablauf aufgebaut, der jeden Fehlschlag einer Ursache und einer zuständigen Person zuordnet.

Welche Testebenen gibt es?

Regressionstests laufen auf mehreren Ebenen. Die Testpyramide ordnet sie: unten viele schnelle Unit-Tests, in der Mitte Integrations- und API-Tests, oben wenige End-to-End-Tests über die Oberfläche.

• Unit-Tests prüfen einzelne Funktionen oder Module. Sie laufen in Sekunden und sind leicht zu automatisieren.
• Integrations- und API-Tests prüfen, ob Module, Datenbank und Schnittstellen sauber Daten austauschen.
• End-to-End- und Frontend-Tests prüfen ganze Abläufe in der Oberfläche, inklusive Bedienbarkeit und Navigation. Sie sind am langsamsten und am aufwendigsten zu warten.

Je höher die Ebene, desto teurer ist jeder einzelne Test. Wer Fehler schon auf Unit-Ebene fängt, hält die Suite schnell. Einen Überblick über weitere Testmethoden findest du in unserem Artikel zu Software Testing.

Regressionstest-Tools 2026: Der Markt hat sich verschoben

Das richtige Tool hängt vom Team und vom Tech-Stack ab. Seit 2025 hat sich der Markt verschoben. Für neue Web-Projekte greifen viele Teams zu Playwright: In der Umfrage State of JS 2025 hat Playwright gleichauf mit Vitest am stärksten an Nutzung zugelegt. Selenium bleibt in großen Bestandssuiten stark. Neu dazugekommen sind KI-Plattformen, die Tests aus Text oder aufgezeichneten Abläufen erzeugen. Drei Kategorien helfen bei der Einordnung.

Die Grenzen verschwimmen: Auch Low-Code-Werkzeuge wie Katalon bringen inzwischen KI-Funktionen mit, etwa für die Testgenerierung. Für die Einordnung zählt, wie ein Team seine Tests überwiegend erstellt.

Playwright deckt mit einer Codebasis Chromium, Firefox und WebKit ab und wartet automatisch, bis Elemente bereit sind. Das macht Testläufe stabiler. Selenium spielt seine Stärken aus, wenn viele Programmiersprachen, ältere Browser oder eine große bestehende Suite abgedeckt werden müssen. Cypress ist bei Frontend-Teams beliebt, weil Tests direkt im Browser laufen und sich gut debuggen lassen. Für neue Web-Suites setzen wir Playwright ein.

Ein gutes Regressionstest-Tool sollte diese Eigenschaften mitbringen:

• Integration in CI/CD: Es läuft sauber in bestehenden Pipelines.
• Automatisierung: Wiederkehrende Abläufe laufen ohne manuelles Zutun.
• Testauswahl: Es startet pro Änderung nur die Tests, die davon betroffen sind.
• Reporting: Berichte zeigen Ergebnisse und Trends über die Zeit.
• Skalierbarkeit: Das Tool wächst mit der Anwendung und der Zahl der Tests mit.

KI im Regressionstest: Testgenerierung, Self-Healing, Fehleranalyse

KI verändert vor allem die Arbeit rund um den Testlauf. Sie schreibt Tests, repariert veraltete Tests und hilft beim Einordnen von Fehlschlägen. Den Testlauf selbst sollte sie nicht übernehmen. Ein Regressionstest muss für denselben Code immer dasselbe Ergebnis liefern, und KI-Modelle antworten nicht immer gleich. Drei Einsatzfelder sind 2026 praxisrelevant.

• Testgenerierung und agentische QA: KI erzeugt Testfälle aus User Stories und Spezifikationen. Erste agentische Werkzeuge entscheiden selbst, was und wann sie testen.
• Self-Healing: Ändert sich ein Element in der Oberfläche, passt die KI den Test an, damit er das Element wiederfindet.
• Fehleranalyse: KI schlägt vor, ob ein roter Test auf einen echten Fehler, veränderte Daten oder ein Fremdsystem zurückgeht.

KI-basierte Testauswahl gibt es ebenfalls, Meta hat sie zum Beispiel erforscht. Sie trifft aber eine statistische Vorhersage. Uns ist Nachvollziehbarkeit wichtiger, deshalb wählen wir Tests regelbasiert aus (mehr dazu bei den Best Practices).

Aus der Praxis: Wir setzen früher an als Self-Healing. Unsere Tests suchen Elemente so, wie ein Mensch sie beschreiben würde, etwa „der Button mit der Beschriftung ‚In den Warenkorb‘“. Technische Details, die sich oft ändern, nutzen sie dafür nicht. Automatische Prüfregeln erzwingen das. So brechen Tests bei Designänderungen gar nicht erst.

Wird ein Test trotzdem rot, darf unser KI-Werkzeug ihn nicht einfach „heilen“. Es entscheidet zuerst, ob der Test veraltet ist oder die Website einen Fehler hat. Eine Prüfung abzuschwächen, damit der Test grün wird, ist ausgeschlossen. Jede Reparatur prüft ein Mensch. Sonst passt die KI einen Test im Zweifel an einen echten Fehler an, und niemand merkt es.

Wie wir KI im Entwicklungsalltag einführen, zeigen wir auf unserer Seite zu AI Adoption im Engineering.

Regressionstest: Best Practices

Gute Regressionstests brauchen gute Strategie. Die folgenden Prinzipien halten den Aufwand beherrschbar, auch wenn die Suite wächst. Sie gelten unabhängig davon, ob du mit Playwright, Selenium oder einer KI-Plattform arbeitest.

• Gezielt automatisieren: Automatisiere, was regelmäßig wiederkehrt. Ein Szenario, das du nur einmal brauchst, testest du manuell oft schneller. Je öfter ein Test läuft, desto eher rechnet sich die Automatisierung.
• Gestuft testen: Pro Pull Request läuft eine schnelle Auswahl aus Unit-, Smoke- und betroffenen Regressionstests. Die volle Suite läuft zeitgesteuert, etwa nachts. Bei KSB dauert die vollständige Regression mit API-Tests und Website-Tests in Chrome und Firefox etwa 40 bis 45 Minuten.
• Tests regelbasiert auswählen: Ein festes Regelwerk wertet aus, welche Dateien sich geändert haben und welche Tests davon abhängen. Das Ergebnis ist jedes Mal gleich und nachvollziehbar. Playwright bringt das als Option mit („--only-changed“). Geänderte Daten oder Einstellungen in anderen Systemen erkennt die Auswahl aber nicht. Deshalb gehört die nächtliche volle Suite dazu.
• Schnelles Feedback sichern: Der Testlauf pro Pull Request sollte nach wenigen Minuten ein Ergebnis liefern. Dauert er regelmäßig länger, ist die Auswahl zu groß oder die Pyramide kippt.
• Flaky Tests sofort angehen: Ein Test, der ohne Änderung mal grün und mal rot ist, untergräbt das Vertrauen in die ganze Suite. Martin Fowler nennt solche Tests „useless“: Wer bei Rot nicht weiß, ob ein Fehler dahintersteckt, ignoriert irgendwann jedes Rot. Isoliere den Test, finde die Ursache und repariere ihn zeitnah. Vorsicht bei automatischen Wiederholungen: Sie verdecken instabile Tests, solange niemand auswertet, welche Tests erst im zweiten Anlauf bestanden haben.
• Visuelle Regressionen und Barrierefreiheit mitprüfen: Screenshot-Vergleiche zeigen, ob sich Layouts unbeabsichtigt verschoben haben. Automatisierte Accessibility-Checks finden fehlende Alternativtexte oder zu schwache Kontraste. Sie erkennen aber nur einen Teil der Barrieren, eine manuelle Prüfung bleibt nötig. Für Shops und Online-Dienste, die sich auch an Verbraucher richten, gilt das BFSG. Dort gehören beide Prüfungen in jeden Regressionslauf. Mehr dazu im Artikel zum Barrierefreiheitsstärkungsgesetz.
• Testpyramide einhalten: Viele Unit-Tests als Basis, darüber Integrations- und API-Tests, an der Spitze wenige End-to-End-Tests.
• Smoke-Test vorschalten: Er fängt offensichtliche Fehlfunktionen ab, bevor der lange Lauf startet.
• Architektur sauber halten: Eine klare, modulare Architektur beugt Fehlern vor und macht sie leichter auffindbar.

Testdaten: der unterschätzte Aufwand

Ein Test braucht Daten, mit denen er arbeitet: ein Kundenkonto, einen Artikel, einen Preis, einen Lagerbestand. Er prüft dann zum Beispiel, ob Kunde X Artikel Y in den Warenkorb legt und Preis Z sieht. Ändert jemand diese Daten, wird der Test rot, obwohl die Website fehlerfrei ist. Bei KSB ist das die häufigste Ursache für rote Tests, häufiger als technische Probleme. Vier Gründe machen Testdaten so aufwendig:

• Geteilte Systeme: Die Testdaten liegen in Systemen, die auch andere Teams nutzen und verändern.
• B2B-Logik: Preise, Sortiment und Bestellrechte hängen von Kunde, Land und Vertrag ab. Ein Test braucht genau die passende Kombination.
• Zustand: Ein Test, der eine Bestellung abschickt, verändert die Daten für den nächsten. Vor jedem Lauf muss ein definierter Ausgangszustand hergestellt werden.
• Zeit: Angebote laufen ab, Lagerbestände ändern sich.

Für viele Tests ersetzen wir das echte Backend deshalb durch Mocks. Das sind nachgebildete Antworten, die wir einmal vom echten System aufzeichnen und dann immer gleich abspielen. Wir prüfen beides: mit Mock, weil das stabil ist, und gegen das echte System, weil das realistisch ist.

Fazit zu Regressionstests

Ein guter Regressionstest findet Regressionen, bevor sie live gehen, und liefert dabei schnell Feedback. Dafür braucht es laufend gepflegte Testfälle, eine sinnvolle Automatisierung und eine gestufte Einbindung in die CI/CD-Pipeline.

Der Aufwand wächst mit der Komplexität. Microservice-Architekturen und häufige Releases vergrößern die Zahl der Abhängigkeiten, die ein Regressionstest abdecken muss. In vernetzten Testumgebungen stecken die meisten Stunden im Einordnen roter Tests und in der Pflege der Testdaten. KI hilft beim Schreiben und Warten von Tests. Der Testlauf selbst bleibt deterministisch, und die Strategie dahinter bleibt Teamarbeit.

Diesen Weg musst du nicht allein gehen. Bitgrip begleitet Unternehmen bei der Software-Qualitätssicherung, von der Teststrategie über die Automatisierung bis zum Review deiner Regressionstests. Lass uns über deinen QA-Prozess sprechen.

FAQ

Was versteht man unter einem Regressionstest?

Ein Regressionstest wiederholt bereits bestandene Testfälle nach einer Änderung an der Software. Er stellt sicher, dass bestehende Funktionen weiterhin fehlerfrei arbeiten. Auslöser sind neue Funktionen, Fehlerbehebungen, Optimierungen, Bibliotheks-Updates oder Änderungen an der Umgebung.

Was ist der Unterschied zwischen Regressionstest und Re-Test?

Ein Re-Test prüft gezielt, ob ein konkreter Fehler behoben ist. Ein Regressionstest prüft, ob eine Änderung andere, bestehende Funktionen beschädigt hat. In guten Teams stellt ein automatischer Test den Fehler zuerst nach. Nach der Behebung bleibt er als Regressionstest dauerhaft in der Suite.

Was ist der Unterschied zwischen Regressionstest, Smoke-Test und Integrationstest?

Die Begriffe beantworten verschiedene Fragen. Integrationstest beschreibt die Ebene: Spielen Module und Schnittstellen zusammen? Smoke-Test beschreibt den Umfang: nur die Kernfunktionen. Regressionstest beschreibt den Anlass: Er läuft nach einer Änderung. Ein Integrationstest kann deshalb gleichzeitig ein Regressionstest sein.

Welches Regressionstest-Tool ist 2026 das richtige?

Das hängt vom Team und vom Tech-Stack ab. Für neue Web-Projekte greifen viele Teams zu Playwright. Selenium bleibt bei vielen Programmiersprachen und großen Bestandssuiten stark, Cypress ist bei Frontend-Teams beliebt. KI-Plattformen wie Mabl oder testRigor lohnen sich, wenn du Tests aus Text oder aufgezeichneten Abläufen erzeugen willst.

Wie verändert KI das Regressionstesting?

KI hilft vor allem beim Schreiben von Tests, beim Reparieren veralteter Tests und beim Einordnen von Fehlschlägen. Der Testlauf selbst sollte ohne KI auskommen, weil er für denselben Code immer dasselbe Ergebnis liefern muss. Jede KI-Änderung an einem Test sollte ein Mensch prüfen.

Wer sollte Regressionstests durchführen?

Automatisierte Regressionstests laufen heute meist in der CI/CD-Pipeline. Aufbau und Pflege der Suite liegen beim QA-Team, oft gemeinsam mit der Entwicklung. An der Teststrategie sollte das ganze Team mitarbeiten, weil die Auswahl der Testfälle Wissen aus allen Bereichen braucht.