Regressionstest 2026: ISTQB-Definition, Praxis & Tools

Sie ändern eine Zeile Code, schließen einen Ticket-Bugfix oder rollen ein Library-Update aus. Jedes Mal stellt sich dieselbe Frage: Funktioniert alles, was vorher lief, immer noch? Genau dort setzt der Regressionstest an.

Dieser Praxis-Guide zeigt Ihnen, wie das ISTQB den Regressionstest definiert, wie er sich von Smoke-Test, Sanity-Test und Retest abgrenzt, nach welchen Strategien Sie Testfälle auswählen und welche Tools sich in modernen CI/CD-Pipelines bewährt haben.

Wir starten bei der Definition, klären die Abgrenzung gegenüber verwandten Testarten, zeigen drei Auswahl-Strategien für Testfälle und enden mit einer Tool-Vergleichstabelle plus konkretem Pipeline-Anker.

Was ist ein Regressionstest? (ISTQB-Definition)

Das ISTQB-Glossar definiert den Regressionstest als „eine Art änderungsbezogenes Testen, um festzustellen, ob in unveränderten Bereichen der Software Fehlerzustände eingebaut oder freigelegt wurden". Der Test fragt also nicht, ob die neue Funktion läuft, sondern ob das Bestehende nach der Änderung weiterhin korrekt arbeitet.

Damit gehört der Regressionstest in jede Phase Ihres Testprozesses: Sie können ihn auf Komponentenebene (Unit-Test), Integrationsebene, Systemebene und Abnahmeebene anwenden. Eine umfassende Einordnung der Test-Stufen finden Sie im Hub-Artikel Was ist Software Testing? Definition, 7 Methoden und Testpyramide.

In der Praxis ist der Regressionstest Ihr Sicherheitsnetz nach jeder Codeänderung. Er ist das Werkzeug, mit dem Sie messen können, ob ein Bugfix wirklich nur den gemeldeten Defekt behebt oder einen neuen Fehler an anderer Stelle ausgelöst hat.

Wann führen Sie Regressionstests durch?

Ein Regressionstest ist immer dann angezeigt, wenn sich am System oder seiner Umgebung etwas ändert. Konkret heißt das:

• Bugfix: Sie korrigieren einen Defekt und prüfen, ob die Korrektur keine neue Regression ausgelöst hat.
• Neues Feature: Eine fachliche Erweiterung kann unbeabsichtigt auf bestehende Funktionen wirken.
• Refactoring: Die Funktionalität soll gleich bleiben, der Code wird umgebaut. Ein klassischer Regressions-Trigger.
• Dependency-Update: Library-Versionen, Frameworks oder Container-Basisimages ändern sich. Auch hier prüfen Sie Bestehendes.
• Konfigurations- oder Infrastruktur-Änderung: Eine neue Umgebung, ein anderes Datenbank-Setup, ein veränderter Reverse-Proxy.
• Release-Vorbereitung: Vor jedem Produktiv-Release läuft typischerweise eine umfangreichere Regressionssuite.

Das ISTQB beschreibt zusätzlich die regressionsvermeidende Teststrategie: einen Ansatz, der die Anzahl notwendiger Regressionstests durch automatisierte Tests, gut isolierte Module und stabile Schnittstellen reduziert. Sie testen also nicht mehr Bestehendes, weil Sie es können, sondern weil Sie es müssen, wenn die Änderung das Risiko erhöht.

Abgrenzung: Smoke-, Sanity-, Retest- und Regressionstest

Die vier Begriffe werden in Projekten oft synonym verwendet. Das ist falsch, und es kostet Aufwand: Ein Smoke-Test ersetzt keinen Regressionstest, ein Retest schließt keine Lücken in einer Regressionssuite. Die folgende Tabelle stellt die Unterschiede klar gegenüber.

Eine Faustregel: Smoke-Test sagt „Ja, wir können testen". Sanity-Test sagt „Ja, der Change wirkt". Retest sagt „Ja, der Defekt ist weg". Der Regressionstest sagt „Ja, alles andere läuft weiter".

Wer die vier Begriffe sauber trennt, vermeidet ein klassisches Missverständnis im Team: dass ein erfolgreich gelaufener Smoke-Test bereits eine Aussage über die Stabilität des Releases macht. Macht er nicht. Eine ausführlichere Einordnung in die Test-Stufen-Familie liefern unsere Artikel zu Integrationstests nach ISTQB und Unit Tests.

Testfall-Auswahl: vollständig, risikobasiert oder zielgerichtet?

Sobald eine Testsuite über mehrere hundert Testfälle wächst, stellt sich die Frage: Welche Tests laufen bei welcher Änderung? Drei Strategien haben sich in der Praxis bewährt.

1. Vollständige Regression (Full Suite)

Alle Tests werden bei jeder Änderung ausgeführt. Vorteil: maximale Sicherheit. Nachteil: hohe Laufzeiten, hoher Infrastruktur-Aufwand. Geeignet für überschaubare Suiten oder als nächtlicher Lauf vor einem Release-Branch.

2. Risikobasierte Auswahl

Sie priorisieren die kritischen Funktionen und die am häufigsten genutzten Pfade. Eine Risiko-Matrix klassifiziert Testfälle nach Eintrittswahrscheinlichkeit eines Fehlers und Schadenshöhe. Die Top-Klasse läuft bei jedem Commit, die Mittelklasse bei jedem Merge in den Hauptbranch, die Niedrig-Klasse einmal pro Nacht.

3. Zielgerichtete Auswahl (Targeted Regression)

Mittels Impact-Analyse identifizieren Sie, welche Module von einer Änderung betroffen sind. Nur die zugehörigen Testfälle laufen. Voraussetzung sind gute Modulgrenzen, eine Coverage-Erfassung und idealerweise ein Tool, das Code-Änderungen auf Testfälle mapped (Test Impact Analysis).

In der Praxis kombinieren reife Teams diese Strategien: Smoke- und Targeted-Tests bei jedem Pull-Request, Risikobasierter Lauf bei jedem Merge, Full-Suite vor dem Release. So balancieren Sie Sicherheitsbedürfnis und Pipeline-Geschwindigkeit.

Wann lohnt sich Automatisierung?

Regressionstests sind der ROI-stärkste Kandidat für Testautomatisierung, weil dieselben Testfälle viele Male wiederholt werden. Nicht jeder Testfall sollte aber automatisiert sein. Drei Pflicht-Kriterien helfen bei der Entscheidung.

Wann Sie automatisieren sollten

• Häufige Wiederholung: Der Test läuft mehr als fünfmal pro Sprint. Bei weniger lohnt sich der Initialaufwand selten.
• Stabile Anforderungen: Die getestete Funktion ändert sich nicht alle zwei Wochen. Sonst wartet das Team mehr Tests, als es schreibt.
• Klare Verifikation: Das erwartete Ergebnis lässt sich eindeutig prüfen (Assertion-fähig). Bei rein visuellen oder explorativen Tests ist die Hürde höher.

Wann manuelles Testen sinnvoll bleibt

• Einmalige Migrations- oder Akzeptanztests vor einem Go-Live.
• Explorative Tests, bei denen Tester:innen aktiv neue Fehler suchen, statt bekannte zu verifizieren.
• Usability- und Look-and-Feel-Prüfungen, bei denen menschliche Wahrnehmung die zentrale Messlatte ist.

Eine breitere Diskussion zu Regeln und Mustern automatisierter Tests finden Sie in unserem Praxis-Artikel Testautomatisierung 2026: 6 goldene Regeln.

Passende Tools im Überblick

Den einen Regressionstest-Standard gibt es nicht. Die Wahl hängt von Ihrer Test-Stufe ab: Unit-Tests laufen mit anderen Werkzeugen als End-to-End-Tests, Performance-Regressionen wieder mit anderen. Die folgende Tabelle ordnet die in DACH-Projekten verbreiteten Tools nach Einsatzzweck.

Ein konzeptionelles Pseudocode-Beispiel zeigt das Muster, das alle UI-Tools teilen: Setup, Aktion, Assertion. Die exakte Syntax unterscheidet sich, das Prinzip nicht.

test('Anmeldung mit gültigem Konto bleibt funktionsfähig', async () => {
  await page.goto('/login');
  await page.fill('#email', 'tester@example.com');
  await page.fill('#password', 'PflichtFeld!');
  await page.click('button[type=submit]');

  await expect(page).toHaveURL('/dashboard');
  await expect(page.locator('h1')).toContainText('Willkommen');
});

Wir verzichten hier bewusst auf einen Tool-spezifischen Tutorial-Anteil. Konkrete Setup-Anleitungen, Page-Object-Patterns und CI-Integrationen finden Sie in den verlinkten Tool-Artikeln.

Regressionstests in CI/CD-Pipelines

Eine Regressionssuite, die nur lokal läuft, ist eine Suite, die nicht zuverlässig läuft. In der Praxis gehört die Regressionsstrategie in die CI/CD-Pipeline. Drei Aspekte sind dabei entscheidend.

Trigger und Stufung

Nicht jeder Pipeline-Lauf muss die volle Suite ausführen. Eine bewährte Stufung:

• Auf Pull-Request: Smoke-Tests plus zielgerichtete Regression der betroffenen Module. Laufzeit unter 10 Minuten.
• Auf Merge in den Hauptbranch: Erweiterte Regression mit risikobasierter Auswahl. Laufzeit bis 30 Minuten.
• Nightly oder vor Release-Branch: Vollständige Regression einschließlich Performance-Schwellen-Prüfung. Laufzeit ohne harte Obergrenze.

Parallelisierung

Lange Regressionsläufe sind der Hauptgrund, warum Teams die Pipeline aushebeln und Tests skippen. Parallelisierung ist die Antwort. Moderne Tools wie Playwright unterstützen Worker-basierte Parallelisierung nativ. In Jenkins oder GitHub Actions nutzen Sie Matrix-Builds, um Testklassen auf mehrere Runner zu verteilen.

Shift-Left als Beschleuniger

Regressionstests früher in der Pipeline einzubauen, reduziert Folgekosten. Statt Regressionen erst im Release-Cycle zu entdecken, fängt eine Pull-Request-Pipeline mit gut gewählten Tests die häufigsten Probleme direkt im Commit-Moment ab. Mehr zum Trade-off zwischen Shift-Left und Shift-Right finden Sie im Artikel Shift Left vs. Shift Right Testing 2026.

Fazit: Regressionstest ist Pipeline-Bestandteil, nicht Release-Event

Ein Regressionstest beantwortet eine einzige Frage: Funktioniert das Bestehende nach der Änderung weiterhin? Das ISTQB-Glossar gibt Ihnen den präzisen Begriff. Die Abgrenzung zu Smoke-, Sanity- und Retest räumt mit Missverständnissen im Team auf. Drei Auswahl-Strategien helfen bei wachsenden Suiten.

Tests sind kein Add-on. Tests sind der Vertrag, den Ihr Team mit der Produktion schließt.

Wer Regressionstests konsequent in die Pipeline integriert, gewinnt Geschwindigkeit zurück, die manuell verlorenginge. Wenn Sie diesen Weg gehen wollen und sich fragen, wo Sie ansetzen sollen, ist eine pragmatische Test-Strategie der erste Schritt.

Häufige Fragen zum Regressionstest (FAQ)

Was ist der Unterschied zwischen Regressionstest und Retest?

Ein Retest prüft, ob ein einzelner, gemeldeter Defekt nach dem Bugfix behoben ist. Der Regressionstest prüft danach, ob die Korrektur keine neuen Fehler an anderer Stelle ausgelöst hat. Retest ist schmal und auf den Defekt fokussiert, der Regressionstest breit und auf das Gesamtverhalten gerichtet.

Wann sollte ich Regressionstests automatisieren?

Sobald derselbe Testfall mehr als fünfmal pro Sprint wiederholt wird, sich die getestete Funktion selten ändert und das erwartete Ergebnis eindeutig prüfbar ist. Einmalige Migrations- oder rein explorative Tests bleiben manuell.

Welche Tools eignen sich für Regressionstests in CI/CD?

Für UI- und End-to-End-Tests sind Playwright, Selenium und Cypress die verbreitetsten Optionen. Für Unit- und Service-Tests JUnit (Java) oder pytest (Python). Für Performance-Regressionen k6. Die Pipeline-Integration läuft in DACH typischerweise über Jenkins oder GitHub Actions.

Wie wähle ich Testfälle für einen Regressionstest aus?

Drei Strategien stehen zur Wahl: vollständige Regression (alle Tests), risikobasierte Auswahl (priorisiert nach Eintrittswahrscheinlichkeit und Schadenshöhe) und zielgerichtete Auswahl (nur die von der Änderung betroffenen Module via Impact-Analyse). Reife Teams kombinieren die drei abhängig vom Pipeline-Trigger.

Was ist eine regressionsvermeidende Teststrategie nach ISTQB?

Eine Strategie, die die Anzahl notwendiger Regressionstests durch gut isolierte Module, stabile Schnittstellen und automatisierte Tests reduziert. Sie testen nicht mehr, sondern bewusster: dort, wo die Änderung das Risiko erhöht.

Welche Rolle spielen Regressionstests in agilen Projekten?

In agilen Projekten ist der Regressionstest kein Release-Event, sondern Pipeline-Bestandteil. Jeder Sprint produziert neue Features und neue Risiken für bestehendes Verhalten. Eine automatisierte Regressionssuite ermöglicht es, häufiger zu releasen, ohne die Qualität zu opfern. Ein Schwerpunkt liegt auf der Test-Pflege: Tests werden gemeinsam mit dem Code weiterentwickelt, sonst veraltet die Suite schneller, als sie schützen kann.