Die Hälfte der QA-Teams verwendet “Smoke” und “Sanity” synonym. Die andere Hälfte streitet in Stand-ups darüber. Beide Gruppen verlieren Stunden pro Sprint durch falsch geroutete Tests, und die meisten wissen nicht einmal, dass es passiert.
Die Verwirrung geht über Terminologie hinaus. Wählt man den falschen Testtyp, verbringen QA-Ingenieure eine Stunde damit, einen Rabattcode-Fix zu debuggen, während der Login seit dem morgendlichen Build defekt ist. Anders herum gibt ein Smoke-Pass still grünes Licht für ein Release, das einen Fehler direkt zu den Montagmorgen-Kunden liefert. Der DORA-Bericht 2025 stellte fest, dass Teams, die die Auslieferung mit KI beschleunigen, eine erhöhte Auslieferungsinstabilität erleben, wenn ihre zugrunde liegende Testdisziplin schwach ist. Teams, die diese Falle vermeiden, kombinieren diese Kontrollpunkte in der Regel mit Regressionstestdiensten, die alles miteinander verbinden.
Dieser Artikel liefert Ihnen zuerst die Kurzversion: Smoke-Testing prüft, ob der Build läuft, Sanity-Testing prüft, ob eine bestimmte Änderung funktioniert. Dann wird erörtert, wie man beides einsetzt, ohne Sprint-Kapazität zu verschwenden, und was es tatsächlich kostet, wenn Teams die falsche Wahl treffen.
Was Smoke-Testing wirklich tut
Ein Smoke-Test ist die Eingangskontrolle, nicht die gesamte Testsuite. Er beantwortet eine einzige Frage: Ist dieser Build testfähig genug? Wenn die Anmeldung nicht funktioniert, die Startseite einen 500-Fehler ausgibt oder die Datenbankverbindung unterbrochen ist, deckt der Smoke-Test dies innerhalb von zehn Minuten auf, der Build wird abgelehnt und niemand im weiteren Verlauf verschwendet Zeit damit.
Die Disziplin ist wichtiger als die Definition. Sobald eine Testsuite länger als zehn Minuten dauert, verlieren die Entwickler das Vertrauen und beginnen, sie zu umgehen. Daher sollte sie klein gehalten werden: fünf bis sieben kritische Pfade, keine Sonderfälle, keine aufwendigen Validierungen. Bei einem E-Commerce-Projekt bedeutet das in der Regel, dass die Startseite geladen wird, der Login funktioniert, die Suche Ergebnisse liefert, eine Produktseite gerendert wird, Artikel in den Warenkorb gelegt werden und der Checkout gestartet wird. Das ist die gesamte Testsuite. Schlägt einer dieser Schritte fehl, ist das Projekt von vornherein zum Scheitern verurteilt.
Hier spielt die Automatisierung ihre Stärken voll aus. Smoke-Tests werden bei jedem Merge in den Hauptzweig, jedem Deployment in eine neue Umgebung, jedem nächtlichen Build und jeder Übergabe eines Release Candidates ausgeführt. Manuelle Smoke-Tests in diesem Rhythmus führen unweigerlich zu übersprungenen Durchläufen. Skriptbasierte Smoke-Tests in CI/CD liefern dem Team innerhalb von zehn Minuten ein eindeutiges Ergebnis und entlasten die Qualitätssicherung für anspruchsvollere Aufgaben.
Eine Falle, auf die man achten sollte: Wenn der Rauchtest erfolgreich ist, bedeutet das nicht, dass der Build gut ist. Es bedeutet lediglich, dass der Build testbar ist.
Was ein Realitätstest tatsächlich bewirkt
Sanity-Tests funktionieren genau umgekehrt. Während Smoke-Tests die Anwendung umfassend testen, konzentrieren sich Sanity-Tests auf einen spezifischen Bereich, in dem sich etwas geändert hat. Hat ein Entwickler beispielsweise einen Fehler mit einem Rabattcode behoben? Der Sanity-Test prüft dann den Rabattprozess, die Neuberechnung des Warenkorbwerts und den davon abhängigen Checkout-Schritt. Sonst nichts.
Auslöser ist stets eine gezielte Änderung: eine Fehlerbehebung, eine Konfigurationsanpassung, eine kleine Verbesserung, ein Update einer Drittanbieterintegration oder ein Hotfix, bei dem keine Zeit für einen vollständigen Regressionstest besteht. Sanity geht davon aus, dass der Build bereits stabil ist (der Smoke-Test wurde erfolgreich abgeschlossen), überspringt daher die grundlegenden Prüfungen und prüft direkt, ob sich die Änderung wie erwartet verhalten hat und ob sie benachbarte Komponenten beeinträchtigt hat.
Sanity-Tests werden üblicherweise manuell durchgeführt. Der Grund dafür ist praktischer Natur: Die Testinhalte ändern sich von Build zu Build, sodass automatisierte Testreihen innerhalb weniger Wochen veralten. Ein QA-Ingenieur, der die zu überprüfende Änderung versteht, ist einer automatisierten Testreihe, die für die Fehlerbehebung des letzten Sprints geschrieben wurde, deutlich überlegen. Eine Ausnahme bilden wiederkehrende Risikobereiche wie Zahlungen oder Authentifizierung, wo monatlich ähnliche Patches eingespielt werden. Diese Tests lohnen sich für eine einmalige Automatisierung.
Schlägt der Plausibilitätstest fehl, wird die Korrektur verworfen, der Rest des Builds bleibt aber in der Regel funktionsfähig. Das ist der strukturelle Unterschied zwischen Smoke- und Plausibilitätstests, und deshalb ist die Unterscheidung zwischen Plausibilitäts- und Smoke-Tests in der Praxis so wichtig: Smoke-Tests führen zum Absturz des gesamten Builds, Plausibilitätstests hingegen nur zu einem Teil davon.
Smoke-Testing vs. Sanity-Testing auf einen Blick
Wenn die beiden nebeneinander stehen, wird der Smoke-vs.-Sanity-Testing-Unterschied offensichtlich. Die folgende Tabelle ist derselbe Vergleich, den jeder QA-Leiter irgendwann auf ein Whiteboard skizziert. Nutzen Sie sie als Referenz.
Auslöser
Neuer Build, frisches Deployment
Gezielte Änderung an einem stabilen Build
Umfang
Breit, gesamte Anwendung
Eng, ein oder zwei Module
Tiefe
Flach, nur kritische Pfade
Tief, innerhalb des geänderten Bereichs
Position im Zyklus
Zuerst, vor allen anderen Tests
Nach Smoke, vor vollständigem Regression
Automatisierungseignung
Stark automatisiert, läuft in CI/CD
Meist manuell, selektive Automatisierung
Wer es ausführt
Automatisierte Pipeline, manchmal Entwickler
QA-Ingenieur, der mit der Änderung vertraut ist
Dokumentation
Geskriptete, versionskontrollierte Suite
Oft ungeskriptet, checklistengesteuert
Was Scheitern bedeutet
Build wird vollständig abgelehnt
Spezifischer Fix wird abgelehnt
Das Muster ist einfach, sobald man es sieht: Smoke ist Breite, Sanity ist Tiefe. Verwechselt man sie, verschwendet man Stunden.
Die 30-Sekunden-Entscheidungsregel
Die gesamte Smoke-Testing-vs.-Sanity-Testing-Debatte reduziert sich auf eine Regel: Smoke-Testing, wenn Sie einen neuen Build haben und nicht wissen, ob er überhaupt funktioniert. Sanity-Testing, wenn Sie einen stabilen Build haben und eine bestimmte Änderung verifizieren müssen.
Vier kurze Beispiele der Regel in der Praxis:
- Neuer Build aus der Entwicklung → Smoke
- Einzelner Bug-Fix gegen einen Build, der heute Morgen Smoke bestanden hat → Sanity
- Freitagsnachmittags-Hotfix auf einem Build, der bereits in Produktion ist → Sanity, eng begrenzt
- Großes Refactoring zusammengeführt, das 14 Dateien berührte → zuerst Smoke, dann Sanity für jedes berührte Modul
Das ist der vollständige Entscheidungsbaum. Der Auslöser ist, was sich geändert hat, nicht wie lange es her ist und nicht wie zuversichtlich der Entwickler bezüglich des Fixes ist.
Wo Regressionstesting einzuordnen ist
Smoke und Sanity sind Tore. Regression ist der vollständige Durchlauf, der bestätigt, dass der Rest der Anwendung noch funktioniert, nachdem alles andere bestanden hat. Smoke läuft bei jedem Build, Sanity läuft nach jeder gezielten Änderung, Regression läuft nächtlich oder vor einem Release.
Das Verhältnis ist hierarchisch. Sanity ist technisch gesehen eine Teilmenge von Regression: Es verwendet Regressions-Testfälle wieder, beschränkt sie aber auf den geänderten Bereich. Das Problem beginnt, wenn Teams beide als dieselbe Suite behandeln. Ein “Sanity-Test”, der sechs Stunden auf einem Hotfix läuft, ist kein Sanity-Test mehr, sondern ein Regressionszyklus mit einem Sanity-Etikett, und das Team hat den Geschwindigkeitsvorteil verloren, der Sanity überhaupt erst lohnenswert gemacht hat.
Die drei Schichten arbeiten zusammen: Smoke sichert den Build, Sanity sichert die Änderung, Regression sichert das Release. Überspringt man eine Schicht, zeigen sich die Kosten woanders.
Wann was einzusetzen ist, mit echten Auslösern
Theorie ist einfach. Der schwierige Teil ist die richtige Entscheidung, wenn ein Entwickler um 16:30 Uhr einen PR in Slack einwirft. Hier sind die Muster, die wir am häufigsten sehen, und die richtige Entscheidung für jeden.
Ein Entwickler hat ein Refactoring zusammengeführt, das 14 Dateien berührte. Der Build ist neu und der Wirkungsradius ist groß. Zuerst Smoke ausführen, denn alles könnte defekt sein. Wenn er besteht, Sanity für jedes vom Refactoring berührte Modul ausführen. Die vollständige Regression überspringen, es sei denn, das Release steht unmittelbar bevor.
Ein Bug-Fix für einen einzelnen Login-Fehler ist eingegangen. Der Build selbst ist derjenige, der heute Morgen Smoke bestanden hat. Smoke wird nicht erneut benötigt, da die Grundlage sich nicht bewegt hat. Sanity für den Login-Flow und die beiden davon abhängigen Flows ausführen (Passwort-Reset, Konto-Sperrung). Zehn Minuten, nicht eine Stunde.
Ein Freitagsnachmittags-Hotfix muss für einen Checkout-Fehler ausgeliefert werden. Der Build ist derselbe, der in Produktion läuft, mit einer gezielten Änderung. Sanity ist die richtige Wahl, eng auf den Checkout-Pfad begrenzt. Smoke würde Zeit auf Flows verschwenden, die Sie nicht haben, auf Flows, die sich seit letzter Woche nicht verändert haben.
Ein Nightly-Build kam vom Main-Branch mit zehn zusammengeführten PRs. Automatisiertes Smoke-Testing läuft zuerst, dann vollständige Regression über Nacht. Das ist der Rhythmus, bei dem Automatisierung sich rechnet.
Eine Drittanbieter-Zahlungs-API wurde aktualisiert. Dies ist eine grundlegende Integration, daher deckt Smoke-Testing sie ab (startet die App noch, lädt der Checkout noch), dann deckt Sanity die Zahlungsflows in der Tiefe ab.
Ein Designer hat eine CSS-Änderung eingereicht. Es ist verlockend, das Testen ganz zu überspringen. Nicht tun. Sanity für die betroffenen Bildschirme ausführen und verifizieren, dass Auth noch funktioniert, da CSS-Spezifitäts-Bugs wirklich Login-Flows brechen können.
Was es kostet, wenn man falsch liegt
Die meisten Teams messen die Kosten einer falschen Testentscheidung nicht, weil der Verlust sich in der normalen Sprint-Kapazität versteckt. Er zeigt sich als “QA ist langsam” oder “wir verpassen immer wieder Release-Termine”, wenn das eigentliche Problem Stunden sind, die mit dem Testen der falschen Schicht verbracht werden. Das Muster verstärkt sich, wenn Teams KI-generierten Code auf schwacher Testdisziplin aufbauen: Die Stack-Overflow-Entwicklerumfrage 2025 ergab, dass 45 % der Entwickler sagen, dass das Debuggen von KI-generiertem Code mehr Zeit in Anspruch nimmt als erwartet, und 66 % zitieren “fast richtig, aber nicht ganz”-Lösungen als ihre größte Frustration. Die Verwechslung von Smoke- und Sanity-Testing erzeugt dieselbe Art von versteckter Steuer: Stunden, die wie Arbeit aussehen, aber tatsächlich Nacharbeit sind.
Sanity-Testing auf einem instabilen Build
Das Szenario: Ein Entwickler gibt um 9 Uhr einen Fix für einen Rabattcode-Fehler ein. QA nimmt ihn auf, springt direkt zum Sanity-Testing des Rabatt-Flows, verbringt eine Stunde mit der Validierung von Edge Cases und entdeckt dann gegen 10:15 Uhr, dass der Login-Service auf demselben Build 500-Fehler wirft und dies seit dem Morgen-Merge tut.
Diese Stunde ist weg, und mit ihr die Kontextwechsel-Steuer des Debuggens der falschen Schicht. Der QA-Ingenieur muss jetzt auf einen neuen Build warten, seine Umgebung zurücksetzen und von vorne beginnen. Multipliziert mit der Anzahl der Male, die sich dieses Muster in einem Sprint wiederholt, verliert man den Großteil eines Tages pro Zyklus. Der Fix ist mechanisch: Smoke sichert jeden neuen Build, bevor Sanity ihn berührt. Keine Ausnahmen.
Smoke-Testing, wenn man Sanity braucht
Das umgekehrte Szenario ist gefährlicher, weil es ausgeliefert wird. Ein Entwickler behebt einen Rabattcode-Fehler. QA führt die Smoke-Suite aus, die prüft, ob Login funktioniert, die Homepage lädt und der Checkout startet. Alles besteht. Der Fix wird ausgeliefert.
Der eigentliche Rabattcode-Fehler war nie im Pfad der Smoke-Suite, da Smoke nicht tief in den Rabatt-Flow geht. Kunden stoßen am Montagmorgen darauf. Jetzt ist es ein Produktionsvorfall, kein Testzyklus, und die Kosten sprangen von QA-Stunden zu Engineering-Stunden plus Support-Tickets plus Vertrauensverlust. Dies ist genau der Fehlermodus, der eine saubere DORA Change Failure Rate in eine schlechte verwandelt.
Sanity existiert, um diese Fehlerklasse abzufangen. Ihn zu überspringen, weil “Smoke bestanden hat”, ist die häufigste Version der Sanity-vs.-Smoke-Testing-Verwirrung, und die teuerste.
Die QA-Team-Checkliste
Die Erkenntnis ist operativ, nicht theoretisch. Führen Sie diese Checkliste gegen Ihren aktuellen QA-Prozess aus, und der Großteil der falsch gerouteten Test-Kosten verschwindet.
Vor jedem Build:
- Die Smoke-Suite läuft automatisch in CI/CD, bleibt unter zehn Minuten und deckt fünf bis sieben kritische Pfade ab
- Schlägt Smoke fehl, wird der Build abgelehnt, kein weiteres Testing findet darauf statt
- Smoke-Suites werden vierteljährlich überprüft und aktualisiert, wenn sich kritische Features ändern
Nach jeder gezielten Änderung:
- Identifizieren, was sich geändert hat und welche Flows daneben liegen
- Sanity nur auf diesem Umfang ausführen, nicht auf der gesamten Anwendung
- Den Sanity-Umfang im Pull Request dokumentieren, damit der Nächste weiß, was abgedeckt wurde und was nicht
- Sanity nur automatisieren, wenn derselbe Bereich wiederholt gepatcht wird
Vor jedem Release:
- Vollständige Regression läuft gegen einen Build, der bereits Smoke- und Sanity-Tore bestanden hat
- Sanity ersetzt niemals Regression bei einem Release-Kandidaten
- Release-Sicherheit kommt davon, dass alle drei Schichten bestehen, nicht eine von ihnen gut besteht
Die Regel noch einmal: Smoke sichert den Build, Sanity sichert die Änderung, Regression sichert das Release. Die meisten QA-Verzögerungen entstehen durch das Ausführen des falschen Typs. Der Fix ist kein neues Tool, es ist Disziplin darüber, welcher Test welche Frage beantwortet. Wenn Sie einen zweiten Blick auf Ihren QA-Prozess von einem Team wollen, das dieses Playbook über Hunderte von ausgelieferten Projekten ausführt, kontaktieren Sie uns.
Erfahren Sie, wie QAwerk Sitch dabei half, QA-Tore zu etablieren, die Onboarding, Chat und Zahlungen vor der landesweiten Expansion stabilisierten, mit über 50 verhinderten kritischen Produktionsfehlern und 99,8 % absturzfreien Sitzungen.
