Ein Build kompiliert, das Deployment läuft durch – und trotzdem startet die App nicht. Genau hier setzt der Smoke Test an: eine schnelle, breite Prüfung der Kernfunktionen, bevor irgendein tieferer Test überhaupt beginnt. Für QA-Leads im DACH-Banking ist das kein Detail. Laut DORA-Report 2024 scheitern Low-Performer bei 64 % ihrer Deployments, während Elite-Teams unter 5 % bleiben (Google DORA via Octopus, 2024). Der Unterschied liegt selten am Code allein. Er liegt an Gates, die fehlerhafte Builds früh stoppen. Dieser Artikel zeigt, wie ein Smoke Test als automatisiertes Quality Gate funktioniert, wo er sich von Sanity und Regression unterscheidet und was er in regulierten Umgebungen leisten muss.

Kurz gefasst: Ein Smoke Test prüft direkt nach dem Build breit und flach, ob das System grundsätzlich funktioniert. Als CI/CD-Gate sollte er unter 2 Minuten laufen und defekte Builds sofort stoppen. Bei Low-Performern scheitern 64 % der Deployments (DORA, 2024) – ein schnelles Gate senkt dieses Risiko messbar.

Abbildung 1: Ein Smoke Test prüft breit und flach die Kernfunktionen eines Builds.

Was ist ein Smoke Test?

Ein Smoke Test ist laut ISTQB eine Testsuite, die die Hauptfunktionalität eines Systems abdeckt, um festzustellen, ob es grundsätzlich funktioniert, bevor die eigentliche Testphase beginnt (ISTQB, 2024). Der Begriff stammt aus der Hardware-Prüfung: Gerät einschalten, schauen, ob es raucht. Übertragen auf Software heißt das: läuft das System überhaupt an?

Bekannt ist der Test auch unter anderen Namen. ISTQB führt Confidence Test, Intake Test und Build Verification Test (BVT) als Synonyme. Im CI/CD-Kontext hat sich vor allem BVT durchgesetzt, weil er die Funktion präzise beschreibt: Er verifiziert, dass ein Build überhaupt testbar ist.

Wichtig ist die Abgrenzung. Ein Smoke Test prüft Breite, keine Tiefe. Er beantwortet eine einzige Frage: Ist dieser Build stabil genug, damit sich gründlicheres Testen lohnt? Findet er einen Fehler, stoppt die Pipeline – noch bevor teure Regressionsläufe Ressourcen binden.

Was deckt ein Smoke Test ab – und was nicht?

Ein Smoke Test prüft die kritischen Happy-Path-Flows eines Systems: Startet die Anwendung, funktioniert der Login, läuft eine Kerntransaktion durch, antworten die kritischen APIs (BrowserStack, 2024). Er bleibt bewusst breit und flach. Tiefe Prüfung ist hier explizit nicht das Ziel.

Was in einen Smoke Test gehört:

• Anwendungsstart: Lädt die App, ohne abzustürzen?

• Authentifizierung: Funktioniert der Login mit gültigen Daten?

• Kerntransaktion: Läuft der wichtigste Geschäftsprozess durch (z. B. eine Überweisung)?

• Kritische Schnittstellen: Antworten Kern-APIs und nachgelagerte Dienste?

Was ein Smoke Test bewusst auslässt:

• Edge Cases und seltene Sonderfälle

• Negativtests mit ungültigen Eingaben

• Performance- und Lasttests

• Detaillierte Validierung einzelner Module

Diese Trennschärfe ist der Punkt. Ein Smoke Test, der zu viel prüfen will, wird langsam und unzuverlässig – und verliert genau die Eigenschaft, die ihn wertvoll macht.

Smoke vs. Sanity vs. Regression – wo liegt der Unterschied?

Abbildung 3: Smoke, Sanity und Regression beantworten drei unterschiedliche Fragen.

Smoke, Sanity und Regression werden oft verwechselt, dabei beantworten sie drei verschiedene Fragen. Der Smoke Test fragt: Ist der Build stabil? Der Sanity Test fragt: Funktioniert eine konkrete Änderung? Der Regressionstest fragt: Hat die Änderung etwas Bestehendes gebrochen? ISTQB führt Sanity teilweise als Synonym – in der Praxis behandeln die meisten Testarchitekten beide aber bewusst getrennt.

Quellen: BrowserStack (2024), CloudBees (2024), CircleCI (2024).

Der praktische Unterschied: Ein Smoke Test ist breit und vollautomatisiert. Ein Sanity Test ist schmal, tief und oft manuell. Wer beide gleichsetzt, verliert ein wichtiges Werkzeug. Mehr zur Abgrenzung der Testarten finden Sie in unserem Überblick zu Software-Testarten.

Wie funktioniert der Smoke Test als CI/CD-Gate?

Abbildung 2: Als CI/CD-Gate stoppt der Smoke Test defekte Builds nach dem Fail-Fast-Prinzip.

Der Smoke Test läuft unmittelbar nach dem Deploy in Test oder Staging – vor allen tieferen Suiten. Damit wird er zum automatisierten Quality Gate, das defekte Builds früh stoppt (Harness, 2024). Statt einen kaputten Build durch die gesamte Pipeline zu schleusen, bricht das Gate sofort ab. Das Prinzip heißt Fail-Fast.

In der Praxis haben sich zwei Muster bewährt. Der Post-Deploy-Smoke prüft direkt nach jedem Deployment, ob die Umgebung grundsätzlich läuft. Der Pre-Promotion-Smoke sitzt als Gate zwischen Staging und Produktion: Nur ein grüner Smoke Test erlaubt die Promotion. Gerade im Banking, wo ein fehlerhaftes Prod-Deployment teuer wird, ist diese zweite Stufe entscheidend.

Warum die 2-Minuten-Regel zählt

Best Practice ist ein Smoke Test unter zwei Minuten Laufzeit (CircleCI, 2024). Der Grund ist psychologisch wie technisch. Dauert das Gate zu lange, beginnen Teams, es zu umgehen oder rote Ergebnisse zu ignorieren. Ein schnelles, deterministisches Gate behält das Vertrauen – und genau dieses Vertrauen ist die eigentliche Währung.

Die Umsetzung gelingt mit Selenium, Cypress oder Playwright über Tagging: Eine kleine, markierte Teilmenge der Tests bildet die Smoke-Suite. Wie ein vollständiger Regressionslauf danach aussieht, beschreiben wir im Leitfaden zum Regressionstest.

Welche Metriken zeigen den ROI eines Smoke Gates?

Abbildung 4: DORA Change Failure Rate 2024 – Low-Performer scheitern bei 64 % der Deployments.

Die zentrale Kennzahl ist die DORA Change Failure Rate. 2024 trennt sie die Leistungsklassen deutlich: Elite-Teams scheitern bei 5 % der Deployments, High bei 10 %, Medium bei 15 % – Low-Performer bei 64 % (Google DORA via Octopus, 2024). Ein zuverlässiges Smoke Gate fängt einen Teil dieser Fehlschläge ab, bevor sie produktiv werden.

Die Verteilung der Teams hat sich zudem verschoben. Im DORA-Report 2024 schrumpfte der High-Performer-Cluster von 31 % auf 22 %, während der Low-Cluster von 17 % auf 25 % wuchs (DORA via getDX, 2024). Stabilität ist also nicht selbstverständlich – sie muss aktiv erarbeitet werden.

Den exakten Laufzeitgewinn eines Autemos-Smoke-Gates können wir hier nicht beziffern, weil belastbare Benchmark-Daten fehlen würden. Qualitativ gilt aber ein klares Muster: Je früher ein Defekt im Pipeline-Lauf auffällt, desto günstiger die Korrektur. Ein Gate, das in zwei Minuten abbricht, spart die Kosten eines fehlgeschlagenen Prod-Deployments.

Was tun, wenn der Smoke Test selbst flaky wird?

Flaky Tests sind ein unterschätztes Risiko: In einer industriellen Studie verursachte Flakiness 11–27 % der Build-Fehlschläge, weiteres Rauschen lag bei 5–16 % (arXiv 2504.11839, 2025). Wird ausgerechnet das Smoke Gate unzuverlässig, untergräbt es das Vertrauen, das es schützen soll. Rote Ergebnisse werden dann ignoriert – und das Gate ist wertlos.

Die Gegenmaßnahme beginnt beim Design. Ein Smoke Test muss klein, deterministisch und schnell sein. Je weniger bewegliche Teile, desto stabiler das Ergebnis. Doch UI-Smoke-Checks brechen oft an verschobenen Locatoren, wenn sich das Frontend ändert.

Hier setzt KI-gestützte Automatisierung an. Self-Healing-Locatoren erkennen geänderte UI-Elemente und passen sich an, statt rot zu schlagen (JetBrains, 2025). Das senkt den Wartungsaufwand wartungsintensiver Smoke-Suiten spürbar. Wie das technisch funktioniert, erklären wir bei den Self-Healing-Locatoren.

Warum ist das im DACH-Banking besonders relevant?

Im regulierten Banking ist ein Smoke Gate mehr als Komfort – es ist Teil der Auditierbarkeit. Bemerkenswert: 73 % der Organisationen nutzen noch keine KI in ihren CI/CD-Workflows (JetBrains State of CI/CD, 2025). Wer hier früh auf wartungsarme, KI-gestützte Gates setzt, verschafft sich einen Vorsprung bei Zuverlässigkeit und Nachweisbarkeit.

Banking-Plattformen sind zudem fragmentiert. Laut JetBrains nutzen 32 % der Organisationen zwei CI/CD-Tools, 9 % sogar drei oder mehr (JetBrains, 2025). Ein Kunde interagiert über Web, Mobile, API und teils Desktop. Ein Smoke Gate, das nur einen Kanal abdeckt, lässt blinde Flecken zurück.

Der Cross-Channel-Ansatz löst genau das. Ein einheitliches Smoke-Gate über alle Kanäle hinweg – Web, Mobile, API, Desktop – prüft die Plattform konsistent. Autemos deckt diese Stacks mit einer einzigen Suite ab und liefert reproduzierbare Gate-Ergebnisse, wie sie ein Audit verlangt. Den breiteren Kontext bietet unser Leitfaden zur KI-Testautomatisierung.

Häufig gestellte Fragen

Wie lange sollte ein Smoke Test dauern?

Best Practice sind unter zwei Minuten (CircleCI, 2024). Dauert das Gate länger, beginnen Teams es zu umgehen oder rote Ergebnisse zu ignorieren. Ein kurzes, deterministisches Smoke Gate behält das Vertrauen der Entwickler – und nur ein vertrauenswürdiges Gate erfüllt seinen Zweck im CI/CD-Lauf.

Ist ein Smoke Test dasselbe wie ein Sanity Test?

Nein, auch wenn ISTQB Sanity teilweise als Synonym führt. Ein Smoke Test ist breit, flach und vollautomatisiert und prüft, ob der Build stabil ist. Ein Sanity Test ist schmal, tief und oft manuell und prüft eine konkrete Änderung. In der Praxis behandeln Testarchitekten beide bewusst getrennt.

Kann ein Smoke Test manuell durchgeführt werden?

Grundsätzlich ja, in der Praxis wird er aber meist vollautomatisiert (BrowserStack, 2024). Als CI/CD-Gate muss er nach jedem Build automatisch laufen. Manuelle Smoke Tests bremsen die Pipeline und widersprechen dem Fail-Fast-Prinzip. Automatisierung ist hier kein Luxus, sondern Voraussetzung.

Was passiert, wenn der Smoke Test fehlschlägt?

Die Pipeline stoppt sofort – das ist das Fail-Fast-Prinzip (Harness, 2024). Tiefere Tests wie Regression laufen gar nicht erst an, was Ressourcen spart. Der Build wird zurückgewiesen, das Team behebt das Grundproblem, und erst ein grüner Smoke Test gibt die Pipeline wieder frei.

Warum sind flaky Smoke Tests so gefährlich?

Weil sie das Vertrauen ins Gate zerstören. Flakiness verursacht 11–27 % der Build-Fehlschläge (arXiv 2504.11839, 2025). Schlägt ein Gate ohne echten Fehler rot, gewöhnen sich Teams daran, es zu ignorieren. Self-Healing-Locatoren und striktes, deterministisches Design halten die Suite stabil.

Fazit

Ein Smoke Test ist die günstigste Versicherung in Ihrer Pipeline. Er prüft in unter zwei Minuten breit und flach, ob ein Build überhaupt testbar ist – und stoppt defekte Builds, bevor sie teure Regressionsläufe oder ein fehlerhaftes Prod-Deployment auslösen. Die Zahlen sind eindeutig: Während Elite-Teams bei 5 % ihrer Deployments scheitern, sind es bei Low-Performern 64 % (DORA, 2024). Im DACH-Banking entscheidet ein zuverlässiges, kanalübergreifendes Gate über Auditierbarkeit und Releasesicherheit. Die größte Gefahr ist nicht der fehlende Test, sondern der flaky Smoke Test, der Vertrauen zerstört. Genau hier helfen Self-Healing und ein einheitliches Cross-Stack-Gate. Möchten Sie Ihr Smoke Gate über Web, Mobile, API und Desktop konsolidieren? Sprechen Sie mit unserem Team.