Was ist ein Smoke Test?
Ein Smoke Test ist eine kurze Vorabprüfung, die zeigt, ob ein neuer Build oder ein frisches Deployment grundsätzlich funktioniert, bevor gründlichere Tests oder echte Nutzer darauf treffen. Er prüft wenige Kernfunktionen, etwa ob die Anwendung startet, antwortet und eine Anmeldung zulässt. Schlägt er fehl, hält die Pipeline an. Das ISTQB-Glossar nennt ihn „eine Testart, um ausreichendes Vertrauen zu gewinnen, dass ein Testobjekt für das geplante Testen bereit ist“.
Auch bekannt als: Smoke-Test · Smoketest · Smoke Testing · Smoke-Testen · Rauchtest · Build Verification Test
Ist Smoke Test bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Ein Smoke Test geht breit und flach über das System. Er prüft, ob die wichtigsten Funktionen überhaupt ansprechbar sind, und überlässt die Frage, ob sie richtig rechnen, den späteren Tests. Typische Prüfungen sind ein Aufruf der Startseite oder eines Health-Endpunkts, eine Anmeldung mit einem Testkonto, eine lesende Datenbankabfrage und die Antwort der angebundenen Dienste. Das Ergebnis ist binär. Bestanden heißt, die gründlichen Tests dürfen starten. Durchgefallen heißt, der Build geht zurück, und niemand wartet eine Stunde auf eine Regressionssuite für einen Stand, der gar nicht startet. Das ISTQB-Glossar kennt neben dem Smoke-Testen auch den Build-Verifizierungstest, einen automatisierten Test, der jeden neuen Build auf Integrität, Kernfunktionalität, Stabilität und Testbarkeit prüft.
Woher kommt der Begriff Smoke Test?
Der Begriff stammt aus der Elektronik und aus dem Rohrleitungsbau. Wer eine neu gebaute oder reparierte Platine zum ersten Mal an Spannung legt, sieht im schlechtesten Fall Rauch aufsteigen, und dann ist jede weitere Prüfung überflüssig. Cem Kaner, James Bach und Bret Pettichord führen den Softwarebegriff in ihrem Buch „Lessons Learned in Software Testing“ von 2002 auf genau diesen Hardwaretest zurück. Im Rohrleitungsbau drückt man Rauch durch frisch verlegte Leitungen, bevor Wasser hineinkommt, und sieht am austretenden Rauch, wo sie undicht sind. Beide Bilder treffen den Kern. Der Test sucht die groben Fehler, früh und mit wenig Aufwand, die feinen bleiben den gründlichen Tests danach.
In einer CI/CD-Pipeline steht der Smoke Test an zwei Stellen. Nach dem Build prüft er, ob das Artefakt startet, bevor Integrations- und Regressionstests Zeit kosten. Nach dem Deployment prüft er die neue Version in der Zielumgebung, bevor sie Traffic bekommt. Die Dokumentation von Argo Rollouts zeigt das mit einer Analyse namens smoke-tests, die bei einem Blue-Green Deployment vor dem Umschalten gegen den Preview-Service läuft. Schlägt sie fehl, schaltet der Rollout nicht um. Eine zweite Analyse nach dem Umschalten führt bei einem Fehler zurück auf die alte Version. Beim Canary Release läuft der Smoke Test, bevor der erste Teil der Nutzer die neue Version sieht, danach übernehmen die Metrik-Gates. Damit ist er ein Quality Gate mit sehr kurzer Laufzeit.
In Industrial DevOps endet die Pipeline an einer Steuerung, und der Smoke Test bekommt eine eigene Form. An der echten Anlage bleibt nach dem Einspielen im Wartungsfenster wenig Zeit, an einer virtuellen Steuerung kann er nach jedem Commit laufen. S7-PLCSIM Advanced von Siemens simuliert eine S7-1500 mit vollwertigem Ethernet-Anschluss und hat eine API für eigene C++- und C#-Programme. Die Pipeline lädt den neuen Stand, schaltet die Instanz in RUN und prüft, ob eine Verbindung zustande kommt, ob die CPU in RUN bleibt und ob das Lebensbit wechselt, mit dem das Programm seinen laufenden Zyklus anzeigt. Erst danach geht der Stand an den HiL-Prüfstand oder ins Wartungsfenster. Fällt ein Stand hier durch, kostet das ein paar Minuten Rechenzeit. An der Anlage hätte er die Linie angehalten.
Die fehlende Umgebungsvariable
Nach dem Deployment auf Staging startet die neue Version, die Startseite lädt, und der Health-Endpunkt meldet sich. Die Anmeldung mit dem Testkonto scheitert trotzdem, weil in der Umgebung die Variable für den Identity-Provider fehlt. Der Smoke Test bricht nach zwei Minuten ab und nennt den Schritt, der fehlgeschlagen ist. Die Regressionssuite, die sonst eine Stunde läuft und an jeder Stelle mit Anmeldung rot geworden wäre, startet gar nicht erst. Das Team ergänzt die Variable und deployt neu.
Kein Umschalten ohne grünen Smoke Test
Ein Team rollt einen Bestellservice mit Argo Rollouts als Blue-Green Deployment aus. Vor dem Umschalten läuft eine Analyse gegen den Preview-Service, die eine Testbestellung anlegt, abruft und wieder storniert. Bei einem Release liefert der Abruf einen Fehler, weil eine Datenbankmigration noch nicht durchgelaufen ist. Der Rollout schaltet nicht um, der Live-Traffic bleibt auf der alten Version. Die Kunden merken nichts davon, und das Team korrigiert die Reihenfolge der Migration am nächsten Vormittag in Ruhe.
Das Lebensbit, das niemand mehr fand
Ein Entwickler benennt im TIA Portal einen Datenbaustein um, damit der Name zur neuen Struktur passt. Das Projekt übersetzt fehlerfrei, und die Pipeline lädt den Stand in eine Instanz von S7-PLCSIM Advanced. Die CPU geht in RUN, aber der Smoke Test findet die Variable mit dem Lebensbit nicht mehr, weil sie jetzt unter einem anderen Pfad liegt. Ein Leitsystem, das per OPC UA auf dieselbe Variable zugreift, hätte nach dem nächsten Wartungsfenster nur noch Verbindungsfehler gemeldet. So steht der Befund im Merge Request.
- Was ist der Unterschied zwischen Smoke Test und Sanity Test?
- Eine verbindliche Abgrenzung gibt es nicht, das aktuelle ISTQB-Glossar führt den Sanity Test gar nicht. Im üblichen Sprachgebrauch prüft der Smoke Test breit und flach, ob ein neuer Build grundsätzlich läuft. Der Sanity Test prüft schmal, ob eine bestimmte Korrektur wirkt. Die englische Wikipedia nennt beide Begriffe teils als Synonyme. Legen Sie im Team fest, was Sie mit welchem Wort meinen, sonst sprechen zwei Kollegen im Stand-up über denselben Test und meinen Verschiedenes.
- Was ist der Unterschied zwischen Smoke Test und Regressionstest?
- Der Smoke Test prüft in kurzer Zeit, ob ein Stand überhaupt testbar ist, der Regressionstest prüft gründlich, ob eine Änderung bestehende Funktionen beschädigt hat. Das ISTQB definiert den Regressionstest als änderungsbezogenes Testen, das feststellen soll, ob in unveränderten Bereichen der Software Fehlerzustände eingebaut oder freigelegt wurden. In der Pipeline läuft der Smoke Test deshalb zuerst und entscheidet, ob sich die lange Regressionssuite lohnt. In unseren Pipelines läuft er nach jedem Deployment, die Regressionssuite nachts.
- Wer führt Smoke Tests durch?
- In einer CI/CD-Pipeline führt die Pipeline den Smoke Test selbst aus, nach jedem Build oder Deployment und ohne dass jemand danebensteht. Schreiben und pflegen sollte ihn das Team, das die Anwendung entwickelt, weil es am besten weiß, welche Funktionen auf keinen Fall ausfallen dürfen. In klassischen Testabteilungen prüfen Testerinnen und Tester einen neuen Build zuerst von Hand, bevor sie ihn zum Testen annehmen. Das funktioniert, kostet bei täglichen Builds aber jeden Morgen dieselbe halbe Stunde.
- Was prüft ein Smoke Test konkret?
- Ein Smoke Test prüft die wenigen Funktionen, ohne die jeder weitere Test sinnlos wäre. Bei einer Webanwendung sind das meist Erreichbarkeit, Anmeldung, ein lesender Datenbankzugriff und die wichtigste Geschäftsfunktion, etwa eine Testbestellung. Bei einer Steuerung sind es Verbindung, Betriebszustand RUN und ein wechselndes Lebensbit. Der ganze Satz sollte in wenigen Minuten durchlaufen. Dauert er länger, wird er zur zweiten Regressionssuite, und das Team wartet wieder auf Ergebnisse, die es schnell haben wollte.
Wo steht Ihr Team bei Smoke Test?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Weiterführende Primärquellen zu Smoke Test: Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01ISTQB GlossarySmoke-Testen(externe Seite, öffnet in neuem Tab)
Deutsche Fassung der ISTQB-Definition, die seit April 2026 im Glossar steht und den Smoke Test als Testart beschreibt, mit der man ausreichendes Vertrauen gewinnt, dass ein Testobjekt für das geplante Testen bereit ist.
- /02ISTQB GlossaryBuild-Verifizierungstest(externe Seite, öffnet in neuem Tab)
ISTQB-Definition des automatisierten Tests, der jeden neuen Build auf Integrität, Kernfunktionalität, Stabilität und Testbarkeit prüft.
- /03Argo RolloutsAnalysis & Progressive Delivery(externe Seite, öffnet in neuem Tab)
Projektdokumentation mit einer Analyse namens smoke-tests, die bei Blue-Green Deployments vor und nach dem Umschalten des Traffics läuft und über Umschalten oder Rückweg entscheidet.
- /04SiemensSIMATIC S7-1500 S7-PLCSIM Advanced, Funktionshandbuch(externe Seite, öffnet in neuem Tab)
Handbuch zur virtuellen S7-1500, Ausgabe 02/2024, mit dem Schalten der Instanz in RUN, OPC UA über TCP/IP und der API für eigene C++- und C#-Programme.
- /05WikipediaSmoke testing (software)(externe Seite, öffnet in neuem Tab)
Überblick mit der Herkunft des Begriffs aus dem Hardwaretest, Synonymen wie Build Verification Test und Belegstellen aus der Testliteratur.
Erstgespräch.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance