Was ist Smoke Testing?

Was ist Smoke Testing?

Smoke Testing ist eine schnelle, flache Reihe von Checks, die gegen einen frischen Build laeuft, um zu bestaetigen, dass das System stabil genug ist, um tieferes Testing zu rechtfertigen. Es prueft 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 nuetzliches Signal liefert? Lautet die Antwort ja, wird der Build sofort abgelehnt und der Rest der Pipeline uebersprungen, 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 bestueckte 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 unveraendert uebernommen. Ein Smoke Test ist das erste Einschalten eines Builds. Er misst weder Qualitaet noch Korrektheit noch Vollstaendigkeit. Er bestaetigt nur, dass der Build intakt genug ist, um die Zeit und Kosten der folgenden tieferen Teststufen zu rechtfertigen. Deshalb heisst Smoke Testing auch Build Verification Testing (BVT) oder Build Acceptance Testing.

Was Smoke Testing abdeckt und was nicht

Ein Smoke Test beruehrt bewusst Breite, nicht Tiefe. Er laeuft ueber die breitesten, geschaeftskritischsten Pfade und bestaetigt, dass jeder lebt, ohne die Edge Cases darin zu pruefen.

• Applikationsstart. Der Prozess bootet ohne Crash und der Health-Endpoint gibt 200 zurueck.
• 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.
• Verfuegbarkeit 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 loesen auf und es gibt kein undefined in der Ausgabe.

Was ein Smoke Test nicht abdeckt: Validierungsfehler, jeden Branch eines Workflows, Grenzwerte, Sicherheitspruefungen oder Verhalten unter Last. Das gehoert in Regression Testing, funktionales Testing oder einen dedizierten Load Test. Eine Smoke-Suite mit diesen Anliegen zu ueberladen ist der haeufigste Weg, aus einem 30-Sekunden-Gate versehentlich eine langsame Mini-Regression-Suite zu machen.

Wann Smoke Testing laeuft

1. Bei jedem CI-Build. Es ist die erste Stufe der Pipeline. Scheitert es, stoppt die Pipeline und keine nachgelagerte Stufe laeuft.
2. Post-Deploy zu Staging oder Production. Es bestaetigt, dass der Deploy tatsaechlich hochgekommen ist, bevor Traffic geroutet wird. Blue-Green- und Canary-Rollouts gaten den Cut-over auf einen bestandenen Smoke Test.
3. Nach Infrastrukturaenderungen. Ein neuer DNS-Eintrag, ein neues TLS-Zertifikat oder ein neues Failover-Ziel kann die Integration brechen, auch wenn der Code unveraendert ist. Smoke prueft den Pfad end-to-end.
4. Vor einem Load Test. Es hat keinen Wert, einen 30-minuetigen 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 beruehrt viele kritische Features je einmal, um die Stabilitaet des ganzen Builds zu bestaetigen. Sanity Testing ist eng und etwas tiefer: nach einer kleinen Aenderung oder einem Bugfix prueft es, dass ein bestimmter Bereich nun korrekt funktioniert, ohne das ganze System erneut zu verifizieren. Smoke ist meist skriptgesteuert und laeuft bei jedem Build; Sanity ist oft eine gezielte, manchmal manuelle Pruefung eines konkreten Release-Kandidaten.

Smoke Testing vs Regression Testing

Regression Testing beantwortet eine andere Frage als Smoke: nicht "ist der Build ueberhaupt lauffaehig?", sondern "hat diese Aenderung 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 laeuft; Regression ist der gruendliche Durchlauf danach. Die Tabelle stellt alle drei Praktiken nebeneinander.

Dimension	Smoke Testing	Sanity Testing	Regression Testing
Beantwortete Frage	Ist der Build ueberhaupt lauffaehig?	Funktioniert dieser Fix?	Hat die Aenderung etwas gebrochen?
Scope	Breit, alle kritischen Pfade	Eng, ein geaenderter 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 Aenderung	Nach bestandenem Smoke

Manuelle vs automatisierte Smoke Tests

Frueh im Projekt kann ein manueller Smoke Test eine kurze schriftliche Checkliste sein, die ein Entwickler von Hand durchgeht: App oeffnen, 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 laeuft, 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 fuer Services oder ein kurzes Browser-Skript fuer nutzerseitige Flows. Als Faustregel gilt: was du bei jedem Release von Hand pruefen wuerdest, ist Kandidat fuer einen automatisierten Smoke Test.

Wie man eine Smoke-Test-Suite entwirft

• Breite statt Tiefe. Waehle die fuenf bis fuenfzehn Pfade, deren Ausfall das ganze Release wertlos machen wuerde, und pruefe jeden genau einmal.
• Bleib schnell. Ziel sind Sekunden, nicht Minuten. Ueberschreitet die Suite wenige Minuten, ist sie eine Regression-Suite geworden.
• Sei deterministisch. Flaky Smoke Tests zerstoeren das Vertrauen in die Pipeline. Entferne Timing-Abhaengigkeiten 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 genuegen.

Smoke Testing fuer APIs und Web-Apps

Fuer 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 fuegst 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 oeffentlichen Endpoint tun das. Genau hier ueberlappen sich kontinuierliches Smoke Testing und Monitoring: ein API-Monitor, der deine kritischen Endpoints planmaessig aus der Cloud trifft, wie du sie in LoadFocus API Monitoring bauen kannst, ist praktisch ein Smoke Test, der nie aufhoert zu laufen, und faengt 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 ausfuehren.

Nutzen und Grenzen

Der Nutzen von Smoke Testing ist frueh, billig und mit hoher Sicherheit einen kaputten Build abzulehnen. Es scheitert schnell, schuetzt 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 ueberall ausfuehren. Mach Smoke zum Eroeffnungs-Gate der CI und wiederhole es nach jedem Deploy in eine neue Umgebung.
• Halte es rigoros klein. Widersteh dem Drang, "nur noch einen" Check hinzuzufuegen; eine aufgeblaehte Smoke-Suite wird uebersprungen.
• Teste von dort, wo Nutzer sind. Fahre Post-Deploy-Smoke lieber aus der Cloud gegen oeffentliche Endpoints als von einem Build-Agent im eigenen Netz.
• Alarmiere laut bei Fehlern. Ein gescheiterter Smoke Test soll blockieren, nie still eine Warnung weitergeben.
• Pruefe die Suite, wenn sich das Produkt aendert. 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 fuer dieselbe Praxis: eine schnelle Reihe von Checks, die bestaetigt, dass ein neuer Build stabil genug fuer tieferes Testing ist. Der Begriff Smoke Testing ist im Alltag gebraeuchlicher.

Wie lange sollte ein Smoke Test dauern?

Hoechstens 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 verfuegbaren Menschen abhaengen. Eine manuelle Checkliste ist ein guter Start fuer 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 laeuft bei jedem Build, um die Gesamtstabilitaet zu bestaetigen. Sanity Testing ist eng und etwas tiefer und laeuft nach einer bestimmten Aenderung, um zu bestaetigen, dass ein Bereich nun funktioniert.

Koennen Smoke Tests gegen Production laufen?

Ja, und sie sollten. Post-Deploy-Smoke gegen Staging oder Production bestaetigt, dass das Release wirklich hochkam, bevor Traffic geroutet wird. Fuehrt 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 fuer tieferes Testing ist. Er ist absichtlich flach und kann keine Edge-Case-Logikfehler, Grenzwertfehler oder Performance-Probleme fangen.