Smoke-Test (Rauchtest) 2026: ISTQB-Definition, Abgrenzung & Praxis

Sie pushen einen Commit, der CI-Job läuft an, der Build steht. Bevor Ihre umfangreiche Test-Suite startet, fehlt eine einfache Antwort: Ist dieser Build überhaupt testbar? Genau diese Antwort liefert der Smoke-Test.

Dieser Praxis-Guide zeigt Ihnen, wie das ISTQB den Smoke-Test definiert, wann Sie ihn einsetzen, wie er sich von Sanity-Test, Retest und Regressionstest abgrenzt und welche Tools sich in modernen CI/CD-Pipelines bewährt haben.

Wir starten bei der Begriffsklärung, klären die Abgrenzung gegenüber verwandten Testarten, zeigen den Aufbau einer Smoke-Test-Suite und enden mit einer Tool-Vergleichstabelle plus konkretem Pipeline-Pattern.

Was ist ein Smoke-Test? (ISTQB-Definition)

Das ISTQB-Glossar definiert den Smoke-Test als „eine Testsuite, die die Hauptfunktionalität einer Komponente oder eines Systems überdeckt, um vor Beginn der geplanten Testausführung festzustellen, ob die Komponente oder das System ordnungsgemäß funktioniert". Der Smoke-Test fragt also nicht, ob jede Funktion fehlerfrei läuft, sondern ob der Build die Grundlage für weiteres Testen liefert.

Der Begriff stammt ursprünglich aus der Hardware-Entwicklung: Ein neues Bauteil wurde eingeschaltet, und solange kein Rauch aufstieg, galt es als grundsätzlich funktionsfähig. In der Softwareentwicklung übernimmt der Smoke-Test diese Rolle als breiter, aber sehr flacher Stabilitäts-Check vor jedem Testlauf.

Smoke-Tests stehen am Anfang der Testkette und entscheiden über das „Go" oder „No-Go" für die nachgelagerten Test-Stufen. Eine umfassende Einordnung der Test-Arten finden Sie im Hub-Artikel Was ist Software Testing? Definition, 7 Methoden und Testpyramide.

Wann führen Sie einen Smoke-Test durch?

Ein Smoke-Test ist immer dann sinnvoll, wenn ein neuer Build entsteht oder ein System in eine neue Umgebung gehoben wird. Konkret heißt das:

• Nach jedem CI-Build: Bevor die teure Test-Suite startet, prüft der Smoke-Test, ob der Build startbar ist und die Kernpfade laufen.
• Nach jedem Deployment in eine Test- oder Staging-Umgebung: Der Smoke-Test bestätigt, dass Konfiguration, Datenbank und Reverse-Proxy korrekt zusammenspielen.
• Vor jeder geplanten Testausführung: Ein roter Smoke-Test stoppt das Test-Team rechtzeitig und vermeidet stundenlange Fehlersuche an Symptomen statt Ursachen.
• Vor jedem Release-Tag: Ein finaler Smoke-Test im Produktions-Replikat liefert die Freigabe für den Release-Cut.
• Nach Hotfixes auf der Produktion: Auch dort gehört ein Smoke-Test in den Pipeline-Pfad, damit der Fix nicht den nächsten Vorfall provoziert.

In der Praxis ist der Smoke-Test der erste Pipeline-Schritt nach dem Build. Er ist Ihr Frühwarnsystem: Statt einen kaputten Build durch alle Folge-Stufen zu schicken, schlagen Sie früh Alarm und sparen Aufwand entlang der gesamten Pipeline.

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

Projekte verwenden die vier Begriffe oft synonym. Das ist falsch, und es kostet Aufwand: Ein Smoke-Test ersetzt keinen Regressionstest, ein Sanity-Test schließt keine Lücke in einer Smoke-Suite. Die folgende Tabelle stellt die Unterschiede klar gegenüber.

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

Wer diese Trennung im Team verankert, vermeidet ein typisches Missverständnis: dass ein erfolgreich gelaufener Smoke-Test bereits eine Aussage über die Release-Reife macht. Macht er nicht. Eine ausführlichere Einordnung der vier Test-Arten liefert unser Praxis-Guide Regressionstest 2026: ISTQB-Definition, Praxis und Tools.

Aufbau einer Smoke-Test-Suite: Was gehört rein?

Eine gute Smoke-Suite ist breit genug, um die Kernpfade zu prüfen, und schmal genug, um in wenigen Minuten zu laufen. Drei Prinzipien helfen bei der Auswahl.

1. Kritische Pfade statt vollständige Workflows

Listen Sie die fünf bis zehn Aktionen, ohne die das Produkt für die meisten Nutzer wertlos wäre. In einem Online-Shop sind das typischerweise Startseite, Login, Produktdetail, Warenkorb und Checkout-Einstieg. Jeder Pfad wird einmal abgelaufen, nicht in jeder Variante.

2. Laufzeit unter zehn Minuten

Eine Smoke-Suite, die zwanzig Minuten läuft, wird vom Team umgangen. Setzen Sie eine Obergrenze und priorisieren Sie hart: Lieber fünf wirklich kritische Pfade als zwanzig „eigentlich auch wichtige". Parallelisierung verschiebt die Grenze nach oben, ändert aber nicht das Prinzip.

3. Idempotenz und Umgebungs-Unabhängigkeit

Smoke-Tests müssen wiederholbar sein, ohne den Zustand der Umgebung zu kennen. Verwenden Sie isolierte Testdaten, räumen Sie nach jedem Lauf auf und vermeiden Sie Abhängigkeiten zu Tagesschwankungen wie Marketing-Bannern oder dynamischen Empfehlungen.

Diese drei Prinzipien gelten unabhängig vom eingesetzten Tool. Sie sind die Grundlage dafür, dass die Suite über Monate stabil bleibt und das Team ihr vertraut.

Manuell oder automatisiert?

Smoke-Tests sind der ROI-stärkste Kandidat für Testautomatisierung. Sie laufen sehr oft, ändern sich selten und prüfen klar verifizierbare Ergebnisse. Drei Indikatoren entscheiden, ob ein Pfad automatisiert oder manuell gehalten wird.

• Lauf-Häufigkeit: Smoke-Tests laufen bei jedem Build. Manueller Smoke-Test ist nur eine Übergangslösung in Pre-Pipeline-Projekten.
• Verifizierbarkeit: Klare Assertion wie „Login-Seite zeigt E-Mail-Feld" eignet sich für Automatisierung, subjektive Bewertungen wie „Hero-Bild wirkt ansprechend" gehören in explorative Tests.
• UI-Stabilität: Stabile Selektoren erlauben Automatisierung. Frühphasen-Prototypen mit täglich wechselnden Layouts bleiben besser manuell, bis die Oberfläche sich stabilisiert hat.

In gereiften Projekten sind Smoke-Tests vollautomatisiert und Teil der Pipeline. Die Auswahl der zugrundeliegenden Werkzeuge folgt dem Tech-Stack und der Test-Stufe. Mehr zu wirtschaftlich tragfähiger Automatisierung lesen Sie in unserem Beitrag Testautomatisierung 2026: 6 goldene Regeln.

Passende Tools im Überblick

Den einen Smoke-Test-Standard gibt es nicht. Die Wahl hängt davon ab, was Sie smoken: eine Web-Anwendung, eine API, einen Service oder die Verfügbarkeit eines Hosts. Die folgende Tabelle ordnet die in DACH-Projekten verbreiteten Werkzeuge nach Einsatzzweck.

Das folgende Pseudocode-Beispiel zeigt das Muster, das alle UI-Smokes teilen: ein definierter Einstiegspunkt, eine einfache Aktion, eine Assertion zum sichtbaren Ergebnis.

test('Startseite und Login erreichbar', async () => {
  await page.goto('/');
  await expect(page.locator('header')).toBeVisible();

  await page.goto('/login');
  await expect(page.locator('input[name=email]')).toBeVisible();
  await expect(page.locator('button[type=submit]')).toBeEnabled();
});

Konkrete Setup-Anleitungen, Page-Object-Patterns und CI-Integrationen finden Sie in den verlinkten Tool-Artikeln.

Smoke-Tests in CI/CD-Pipelines

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

Pipeline-Stage und Trigger

Der Smoke-Test liegt am Anfang der Test-Pipeline, direkt nach dem Build und dem Container-Push. Eine bewährte Stufung:

• Pull-Request: Smoke gegen ein ephemeres Preview-Deployment. Laufzeit unter fünf Minuten.
• Merge in den Hauptbranch: Smoke gegen Staging, danach erweiterte Regression. Schwellenwert: Smoke muss grün sein, sonst stoppt die Pipeline.
• Nightly oder vor Release: Smoke gegen ein Produktions-Replikat, einschließlich Verfügbarkeits-Checks der angebundenen Drittsysteme.

Parallelisierung und Laufzeit

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

Reporting und Abbruchverhalten

Ein Smoke-Test, der nicht klar signalisiert „Build kaputt, Pipeline STOPP", verfehlt seinen Zweck. Setzen Sie harte Schwellenwerte: Ein einziger fehlgeschlagener Pfad bricht die Pipeline ab. Die Folge-Stufen starten nicht, das Team bekommt eine eindeutige Push-Benachrichtigung. Wer hier eine Toleranz einbaut, holt sich genau die kaputten Builds in die teure Test-Suite zurück, die der Smoke-Test verhindern sollte.

Fazit: Smoke-Test ist Pipeline-Schutzschild, nicht Release-Stempel

Ein Smoke-Test beantwortet eine einzige Frage: Ist dieser Build überhaupt testbar? Das ISTQB-Glossar gibt Ihnen den präzisen Begriff. Die Abgrenzung zu Sanity-, Retest- und Regressionstest räumt mit Missverständnissen im Team auf. Drei Auswahl-Prinzipien helfen beim Bau einer schlanken Suite.

Tests sind kein Zeremoniell. Tests sind der erste Filter, den Ihr Build überstehen muss, bevor er weitere Ressourcen bindet.

Wer Smoke-Tests konsequent als ersten Pipeline-Schritt einbaut, gewinnt Geschwindigkeit zurück, die mit kaputten Builds in der Folge-Suite 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 Smoke-Test (FAQ)

Was ist der Unterschied zwischen Smoke-Test und Sanity-Test?

Der Smoke-Test prüft breit, aber sehr flach, ob die Kernpfade eines neuen Builds funktionieren. Der Sanity-Test prüft schmal, aber tief, ob ein konkreter Fix oder Change wie erwartet wirkt. Smoke ist der breite Eingangsfilter nach jedem Build, Sanity ist der fokussierte Detail-Check vor einer breiteren Regressions-Suite.

Wie viele Smoke-Tests sollte eine Suite enthalten?

Faustregel: zwischen fünf und fünfzehn automatisierte Pfade, abhängig von der Komplexität der Anwendung. Wichtiger als die Anzahl ist die Laufzeit: Die gesamte Suite sollte in unter zehn Minuten durchlaufen. Mehr Pfade kosten Pipeline-Zeit, weniger Pfade übersehen kritische Lücken.

Welche Tools eignen sich für Smoke-Tests in CI/CD?

Für UI-Smokes sind Playwright, Cypress und Selenium die verbreitetsten Optionen. API-Smokes laufen häufig mit Postman und Newman. Verfügbarkeits-Smokes brauchen oft nur curl und ein Shell-Skript. Die Pipeline-Integration läuft in DACH typischerweise über Jenkins oder GitHub Actions.

Wer führt Smoke-Tests durch?

In gereiften CI/CD-Projekten ist der Smoke-Test vollautomatisiert und läuft ohne menschlichen Eingriff direkt nach dem Build. In Pre-Pipeline-Projekten übernimmt das Test-Team einen manuellen Smoke-Test als Übergangslösung. Verantwortlich für den Bau und die Pflege der Suite sind in beiden Fällen die Test-Engineers gemeinsam mit den Entwicklerinnen und Entwicklern.

Ersetzt der Smoke-Test den Integrationstest?

Nein. Der Smoke-Test prüft an der Oberfläche, ob Kernpfade funktionieren. Der Integrationstest prüft systematisch das Zusammenwirken mehrerer Komponenten, einschließlich Randfällen und Fehlerpfaden. Smoke ist der Eingangsfilter, Integration ist die strukturelle Prüfung.

Was passiert, wenn der Smoke-Test rot ist?

Die Pipeline stoppt. Die nachgelagerten Test-Stufen starten nicht, der Build wird nicht promoviert, das Entwicklungsteam erhält eine direkte Benachrichtigung. Diese harte Konsequenz ist gewollt: Sie verhindert, dass ein kaputter Build durch eine teure Regressions-Suite gejagt wird und dort eine Vielzahl von Folgefehlern produziert, die alle dieselbe Ursache haben.