Was ist Smoke Testing?

Was ist Smoke Testing?

Smoke Testing ist eine schnelle, flache Reihe von Checks, die gegen einen frischen Build läuft, um zu bestätigen, dass das System stabil genug ist, um tieferes Testing zu rechtfertigen. Es prüft nur die kritischsten Pfade, etwa ob die Anwendung startet, ob Login funktioniert und ob ein zentraler Endpoint antwortet, und beantwortet eine einzige Ja-oder-Nein-Frage: hat dieser Build etwas so Fundamentales kaputt gemacht, dass kein weiterer Test noch nützliches Signal liefert? Lautet die Antwort ja, wird der Build sofort abgelehnt und der Rest der Pipeline übersprungen, sodass die Regression in Sekunden statt nach einem langen Full Run sichtbar wird.

Herkunft und Bedeutung des Begriffs

Der Name stammt aus dem Hardware-Engineering. Wenn eine neu bestückte Platine zum ersten Mal eingeschaltet wurde, war die Sorge simpel: kommt Rauch heraus, ist die Platine defekt und jeder weitere Test sinnlos. Software hat die Metapher fast unverändert übernommen. Ein Smoke Test ist das erste Einschalten eines Builds. Er misst weder Qualität noch Korrektheit noch Vollständigkeit. Er bestätigt nur, dass der Build intakt genug ist, um die Zeit und Kosten der folgenden tieferen Teststufen zu rechtfertigen. Deshalb heißt Smoke Testing auch Build Verification Testing (BVT) oder Build Acceptance Testing.

Was Smoke Testing abdeckt und was nicht

Ein Smoke Test berührt bewusst Breite, nicht Tiefe. Er läuft über die breitesten, geschäftskritischsten Pfade und bestätigt, dass jeder lebt, ohne die Edge Cases darin zu prüfen.

• Applikationsstart. Der Prozess bootet ohne Crash und der Health-Endpoint gibt 200 zurück.
• Kritische User-Flows. Sign-in, der Haupt-Feature-Pfad und der Checkout einer Commerce-App erreichen einen erfolgreichen Zustand.
• Integrations-Handshake. Die App verbindet sich ohne Timeout mit Datenbank, Cache und Message Queue.
• Verfügbarkeit statischer Assets. Das Haupt-JavaScript-Bundle und CSS laden vom CDN mit einer 200, nicht einer 404 durch einen veralteten Hash.
• Konfigurations-Sanity. Erforderliche Umgebungsvariablen lösen auf und es gibt kein undefined in der Ausgabe.

Was ein Smoke Test nicht abdeckt: Validierungsfehler, jeden Branch eines Workflows, Grenzwerte, Sicherheitsprüfungen oder Verhalten unter Last. Das gehört in Regression Testing, funktionales Testing oder einen dedizierten Load Test. Eine Smoke-Suite mit diesen Anliegen zu überladen ist der häufigste Weg, aus einem 30-Sekunden-Gate versehentlich eine langsame Mini-Regression-Suite zu machen.

Wann Smoke Testing läuft

1. Bei jedem CI-Build. Es ist die erste Stufe der Pipeline. Scheitert es, stoppt die Pipeline und keine nachgelagerte Stufe läuft.
2. Post-Deploy zu Staging oder Production. Es bestätigt, dass der Deploy tatsächlich hochgekommen ist, bevor Traffic geroutet wird. Blue-Green- und Canary-Rollouts gaten den Cut-over auf einen bestandenen Smoke Test.
3. Nach Infrastrukturänderungen. Ein neuer DNS-Eintrag, ein neues TLS-Zertifikat oder ein neues Failover-Ziel kann die Integration brechen, auch wenn der Code unverändert ist. Smoke prüft den Pfad end-to-end.
4. Vor einem Load Test. Es hat keinen Wert, einen 30-minütigen Load Test gegen einen Build zu fahren, dessen Login schon kaputt ist. Smoke zuerst, Load danach.

Smoke Testing vs Sanity Testing

Smoke und Sanity Testing werden oft verwechselt, weil beide schnell sind und tiefere Arbeit gaten. Der Unterschied liegt in Scope und Absicht. Smoke Testing ist breit und flach: es berührt viele kritische Features je einmal, um die Stabilität des ganzen Builds zu bestätigen. Sanity Testing ist eng und etwas tiefer: nach einer kleinen Änderung oder einem Bugfix prüft es, dass ein bestimmter Bereich nun korrekt funktioniert, ohne das ganze System erneut zu verifizieren. Smoke ist meist skriptgesteuert und läuft bei jedem Build; Sanity ist oft eine gezielte, manchmal manuelle Prüfung eines konkreten Release-Kandidaten.

Smoke Testing vs Regression Testing

Regression Testing beantwortet eine andere Frage als Smoke: nicht "ist der Build überhaupt lauffähig?", sondern "hat diese Änderung etwas kaputt gemacht, das vorher funktionierte?" Regression-Suiten sind breit und tief, decken viele Features und Edge Cases ab und dauern Minuten bis Stunden. Smoke ist das schnelle Gate, das zuerst läuft; Regression ist der gründliche Durchlauf danach. Die Tabelle stellt alle drei Praktiken nebeneinander.

Dimension	Smoke Testing	Sanity Testing	Regression Testing
Beantwortete Frage	Ist der Build überhaupt lauffähig?	Funktioniert dieser Fix?	Hat die Änderung etwas gebrochen?
Scope	Breit, alle kritischen Pfade	Eng, ein geänderter Bereich	Breit und tief, viele Features
Tiefe	Flach, ein Durchlauf je	Fokussiert, mittlere Tiefe	Tief, Edge Cases inklusive
Dauer	Sekunden bis wenige Minuten	Minuten	Minuten bis Stunden
Automatisierung	Fast immer skriptgesteuert	Oft manuell oder gezielt	Meist voll automatisiert
Zeitpunkt	Zuerst, bei jedem Build	Nach einer Änderung	Nach bestandenem Smoke

Manuelle vs automatisierte Smoke Tests

Früh im Projekt kann ein manueller Smoke Test eine kurze schriftliche Checkliste sein, die ein Entwickler von Hand durchgeht: App öffnen, einloggen, Hauptseite laden, eine Bestellung aufgeben. Das ist billig zu starten und braucht kein Tooling, skaliert aber nicht und kann keine automatisierte Pipeline gaten. Sobald der Build in CI läuft, sollte die Smoke-Suite automatisiert sein, damit sie einen Deploy ohne Mensch in der Schleife blockieren kann. Automatisierte Smoke Tests sind Code: eine Handvoll HTTP-Requests mit Status- und Body-Assertions für Services oder ein kurzes Browser-Skript für nutzerseitige Flows. Als Faustregel gilt: was du bei jedem Release von Hand prüfen würdest, ist Kandidat für einen automatisierten Smoke Test.

Wie man eine Smoke-Test-Suite entwirft

• Breite statt Tiefe. Wähle die fünf bis fünfzehn Pfade, deren Ausfall das ganze Release wertlos machen würde, und prüfe jeden genau einmal.
• Bleib schnell. Ziel sind Sekunden, nicht Minuten. Überschreitet die Suite wenige Minuten, ist sie eine Regression-Suite geworden.
• Sei deterministisch. Flaky Smoke Tests zerstören das Vertrauen in die Pipeline. Entferne Timing-Abhängigkeiten und retry nur bei echt transienten Netzwerkfehlern.
• Blockiere den Build. Ein gescheiterter Smoke Test muss die Pipeline stoppen. Es gibt keinen gelben Smoke-Status.
• Halte es billig. Ein paar HTTP-Checks plus eine kurze Browser-Assertion genügen.

Smoke Testing für APIs und Web-Apps

Für HTTP-Services ist ein kurzes Skript mit 5 bis 15 Critical-Path-Requests ein solides Smoke-Harness. In einem Tool wie k6 setzt du einen virtuellen User und eine Iteration und fügst check()-Assertions auf Status und Body hinzu; in JMeter nutzt du eine Thread Group mit einem User und einem Loop und eine Response Assertion pro Sampler. Wichtig: ein Smoke Test auf einem Entwickler-Laptop beweist nicht, dass die Production-CDN-, DNS- und TLS-Kette funktioniert. Dieselben Checks aus einer echten Cloud-Region gegen den öffentlichen Endpoint tun das. Genau hier überlappen sich kontinuierliches Smoke Testing und Monitoring: ein API-Monitor, der deine kritischen Endpoints planmäßig aus der Cloud trifft, wie du sie in LoadFocus API Monitoring bauen kannst, ist praktisch ein Smoke Test, der nie aufhört zu laufen, und fängt einen kaputten Deploy oder ein abgelaufenes Zertifikat in Minuten. Wer das Gate direkt in die Pipeline verdrahten will, kann dieselben Critical-Path-Checks aus LoadFocus vor einem vollen Load Test ausführen.

Nutzen und Grenzen

Der Nutzen von Smoke Testing ist früh, billig und mit hoher Sicherheit einen kaputten Build abzulehnen. Es scheitert schnell, schützt die teureren Teststufen vor vergeblicher Arbeit und gibt jedem Deploy ein klares Go oder No-Go. Seine Grenze ist genau sein Design: es ist absichtlich flach und wird nie einen subtilen Logikfehler, einen Grenzwertfehler oder ein langsames Memory Leak fangen. Ein bestandener Smoke Test bedeutet "der Build ist weiteres Testen wert", nicht "der Build ist korrekt".

Best Practices

• Zuerst und überall ausführen. Mach Smoke zum Eröffnungs-Gate der CI und wiederhole es nach jedem Deploy in eine neue Umgebung.
• Halte es rigoros klein. Widersteh dem Drang, "nur noch einen" Check hinzuzufügen; eine aufgeblähte Smoke-Suite wird übersprungen.
• Teste von dort, wo Nutzer sind. Fahre Post-Deploy-Smoke lieber aus der Cloud gegen öffentliche Endpoints als von einem Build-Agent im eigenen Netz.
• Alarmiere laut bei Fehlern. Ein gescheiterter Smoke Test soll blockieren, nie still eine Warnung weitergeben.
• Prüfe die Suite, wenn sich das Produkt ändert. Kommt ein neuer kritischer Flow, nimm ihn in Smoke auf; wird ein Pfad entfernt, streiche ihn.

FAQ zum Smoke Testing

Ist Smoke Testing dasselbe wie Build Verification Testing?

Ja. Build Verification Testing (BVT) und Build Acceptance Testing sind die formalen Namen für dieselbe Praxis: eine schnelle Reihe von Checks, die bestätigt, dass ein neuer Build stabil genug für tieferes Testing ist. Der Begriff Smoke Testing ist im Alltag gebräuchlicher.

Wie lange sollte ein Smoke Test dauern?

Höchstens Sekunden bis wenige Minuten. Der Sinn ist schnelles Scheitern und das Gaten der Pipeline. Braucht deine Smoke-Suite zehn Minuten, ist sie ins Regression-Gebiet abgedriftet und sollte aufgeteilt werden.

Sollten Smoke Tests automatisiert oder manuell sein?

Automatisiert, wo eine Pipeline existiert, denn ein Build-blockierendes Gate darf nicht von einem verfügbaren Menschen abhängen. Eine manuelle Checkliste ist ein guter Start für ein junges Projekt, aber jeder bei jedem Release wiederholte Check sollte ein automatisierter Smoke Test werden.

Was ist der Unterschied zwischen Smoke Testing und Sanity Testing?

Smoke Testing ist breit und flach und läuft bei jedem Build, um die Gesamtstabilität zu bestätigen. Sanity Testing ist eng und etwas tiefer und läuft nach einer bestimmten Änderung, um zu bestätigen, dass ein Bereich nun funktioniert.

Können Smoke Tests gegen Production laufen?

Ja, und sie sollten. Post-Deploy-Smoke gegen Staging oder Production bestätigt, dass das Release wirklich hochkam, bevor Traffic geroutet wird. Führt man sie kontinuierlich aus der Cloud aus, wird Smoke Testing zu einer stets aktiven Production-Verifikation.

Bedeutet ein bestandener Smoke Test, dass die Software fehlerfrei ist?

Nein. Ein bestandener Smoke Test bedeutet nur, dass der Build stabil genug für tieferes Testing ist. Er ist absichtlich flach und kann keine Edge-Case-Logikfehler, Grenzwertfehler oder Performance-Probleme fangen.