Der Smoke est prüft nach jedem neuen Build die grundlegende Lauffähigkeit der gesamten Anwendung – er beantwortet die Frage: „Ist der Build stabil genug für weiteres Testen?“ Ein Sanity-Test hingegen wird gezielt nach einem bestimmten Fix oder einer neuen Funktion eingesetzt und prüft, ob diese spezifische Änderung korrekt funktioniert. Smoke Tests sind breiter, Sanity-Tests sind tiefer in einem eng begrenzten Bereich.
Definition: Was ist ein „Smoke Test“?
Der Smoke Test (engl. smoke test, auch Build Verification Test oder BVT) ist eine Testart, die nach jedem neuen Software-Build die grundlegenden Kernfunktionen einer Anwendung prüft. Ziel ist es, kritische Fehler so früh wie möglich zu erkennen – bevor aufwändigere Testarten wie Regressionstests oder Integrationstests gestartet werden. Der Begriff stammt aus der Elektronikindustrie: Beim ersten Einschalten eines neuen Geräts galt es als bestanden, wenn kein Rauch aufstieg. In der Softwareentwicklung bedeutet das: Funktioniert die Anwendung grundsätzlich, oder ist der Build so fehlerhaft, dass weiteres Testen keinen Sinn ergibt? Der Smoke Test deckt typischerweise den Happy Path der wichtigsten Anwendungsfälle ab und bildet den ersten Quality Gate in einer CI/CD-Pipeline. Er ist kein vollständiger Funktionstest, sondern eine schnelle Plausibilitätsprüfung mit hohem Signalwert für das gesamte QA-Team.
Praxisbeispiele für Smoke Test mit QF-Test
QF-Test unterstützt Tester:innen und Entwickler:innen dabei, Smoke Tests als automatisierten Quality Gate in bestehende Build- und Deployment-Prozesse zu integrieren – schnell, stabil und mit minimalem Wartungsaufwand.
Praxisnahe Empfehlungen:
-
Smoke Test-Suite als CI-Trigger: Definieren Sie in QF-Test eine dedizierte Smoke Test-Suite mit den kritischsten Happy-Path-Szenarien und binden Sie diese als ersten automatisierten Schritt in Ihre CI-Pipeline ein – so erkennen Sie defekte Builds sofort. QF-Test in CI-Systemen einsetzen
-
Smoke Tests als Vorstufe zum Regressionstest: Nutzen Sie Smoke Tests als Eingangsfilter vor dem vollständigen Regressionslauf – schlägt der Smoke Test an, wird die teure Regressionssuite nicht ausgeführt und spart Ressourcen. Regressionstests mit QF-Test
-
UI-basierte Kernfunktionen automatisiert prüfen: Automatisieren Sie mit QF-Test die wichtigsten UI-Interaktionen – Login, Navigation, zentrale Workflows – als stabile Smoke Tests, die nach jedem Build reproduzierbar erfolgreich abgeschlossen werden oder gezielte Warnmeldungen auslösen. UI Testing mit QF-Test
-
Smoke Tests in die Testautomatisierungsstrategie einbetten: Verankern Sie Smoke Tests als festen Bestandteil Ihrer übergeordneten Testautomatisierungsstrategie, damit jeder Release-Zyklus mit einem definierten Qualitätscheck startet. Testautomatisierung mit QF-Test
-
Smoke Tests im Kontext der Gesamtteststrategie positionieren: Verstehen Sie Smoke Tests als erste Stufe im Zusammenspiel der Testarten – von Unit-Tests über Integrationstests bis hin zum vollständigen Systemtest. Software Testing Grundlagen
Ziele von Smoke Tests
Der Einsatz von Smoke Tests verfolgt mehrere zentrale Ziele:
- Schnelle Erkennung kritischer Fehler direkt nach dem Build – bevor aufwändigere Tests gestartet werden
- Absicherung der grundlegenden Kernfunktionalität (Happy Path) bei jedem Deployment
- Funktion als automatischer Quality Gate in CI/CD-Pipelines
- Ressourcenschonung durch frühzeitigen Abbruch defekter Builds vor kostspieligem Regressionslauf
- Erhöhung der Teststabilität und Verkürzung der Feedback-Schleife für Entwickler:innen
- Schaffung von Vertrauen in jeden neuen Release Candidate noch vor der vollständigen Testausführung
Diese Ziele helfen Tester:innen, Entwickler:innen und Entscheider:innen, Testaufwand und Release-Sicherheit effizient in Einklang zu bringen.
Wie funktioniert ein Smoke Test?
Der Smoke Test folgt einem klaren, schlanken Ablauf, der auf maximale Geschwindigkeit bei minimalem Scope ausgelegt ist:
- Auswahl der kritischsten Kernfunktionen der Anwendung (z. B. Login, Hauptnavigation, zentrale Workflows)
- Erstellung einer dedizierten Smoke Test-Suite mit repräsentativen Happy-Path-Szenarien
- Automatische Ausführung der Suite nach jedem neuen Build oder Merge in der CI/CD-Pipeline
- Auswertung des Ergebnisses: Besteht der Build den Smoke Test, werden weitere Teststufen (Regressionstests, Integrationstests) freigegeben – schlägt er fehl, wird der Build als instabil markiert und zurückgewiesen
- Benachrichtigung des Teams bei Fehlschlag, damit die Ursache unmittelbar behoben werden kann
Smoke Tests sind bewusst schmal gehalten: Sie prüfen nicht alle Funktionen, sondern nur die unverzichtbaren. In Kombination mit Testautomatisierung und CI/CD-Integration bilden sie das Fundament einer effizienten, schnellen Qualitätssicherung.
Interessiert an QF-Test?
Erzählen Sie uns von sich und wir stellen Kontakt zu QF-Test-Expert:innen her, die Ihnen mehr über unser Produkt erzählen können.
Durchführung von Smoke Tests
Für die operative Umsetzung empfiehlt sich ein strukturiertes Vorgehen:
Einsatzgebiete
- Nach jedem Software-Build oder Merge-Request in der CI/CD-Pipeline
- Vor dem Start umfangreicher Regressionstests oder Systemtests als Eingangsfilter
- Bei Deployments in neue Testumgebungen oder Staging-Systeme
- Nach kritischen Hotfixes, um die grundlegende Lauffähigkeit sofort zu verifizieren
Voraussetzungen
- Ein definierter, stabiler Build-Prozess mit versioniertem Artefakt
- Eine klare Liste der kritischsten Kernfunktionen (Happy Path), die als Smoke Test-Scope dienen
- Eine automatisierungsfähige Testumgebung (z. B. mit QF-Test und CI-Integration)
- Aktuell gepflegte Testdaten für die Kernszenarien
Schrittweise Anwendung
- Scope festlegen: Identifizieren Sie gemeinsam mit dem Team die 5–15 kritischsten Testfälle, ohne die ein Build als unbrauchbar gilt
- Smoke Test-Suite erstellen: Fassen Sie diese Testfälle in einer dedizierten Suite zusammen und halten Sie sie von der Regressionssuite getrennt
- CI-Trigger konfigurieren: Binden Sie die Suite als ersten automatisierten Schritt in die Pipeline ein, der bei jedem Build ausgeführt wird
- Quality Gate definieren: Legen Sie fest, ab welchem Fehlerschwellwert ein Build als fehlgeschlagen gilt und die Pipeline stoppt
- Ergebnis auswerten und kommunizieren: Stellen Sie sicher, dass das Team unmittelbar über Fehlschläge informiert wird
Typische Fallstricke
- Zu breiter Scope: Wenn der Smoke Test zu viele Testfälle umfasst, verliert er seinen Geschwindigkeitsvorteil gegenüber dem vollständigen Regressionslauf
- Fehlende Pflege: Smoke Tests, die bei UI-Änderungen nicht aktualisiert werden, produzieren False Positives und verlieren das Vertrauen des Teams
- Verwechslung mit dem Sanity-Test: Der Smoke Test prüft grundlegende Lauffähigkeit nach dem Build; ein Sanity-Test prüft gezielt einen bestimmten Fix oder eine neue Funktion – beide haben unterschiedlichen Scope und Zeitpunkt
Kombination mit anderen Methoden
- Regressionstests: Der Smoke Test ist der Türöffner – besteht er, startet der vollständige Regressionslauf
- Explorative Tests: Nach bestandenem Smoke Test sinnvoll für neue oder geänderte Funktionen
- End-to-End-Test: Ergänzen den Smoke Test durch tiefergehende Szenarien in späteren Pipeline-Stufen
Vorteile von Smoke Tests
- Schnelles Feedback für Entwickler:innen direkt nach dem Build – Fehler werden in Minuten statt Stunden sichtbar
- Ressourcenschonung durch frühzeitigen Pipeline-Abbruch bei defekten Builds
- Klarer Quality Gate erhöht die Release-Sicherheit ohne hohen Testaufwand
- Einfache Automatisierbarkeit und nahtlose Integration in bestehende CI/CD-Workflows
- Stärkung des Team-Vertrauens in jeden neuen Build durch verlässliche Grundvalidierung
Herausforderungen und Lösungsansätze bei Smoke Tests
Scope-Creep – der Smoke Test wird zu groß: Mit der Zeit tendieren Teams dazu, immer mehr Testfälle in die Smoke Test-Suite aufzunehmen. Die Folge: Die Suite wird langsam und verliert ihren Vorteil als schneller Eingangsfilter. Begrenzen Sie den Smoke Test-Scope aktiv durch einen regelmäßigen Review und halten Sie die Laufzeit unter einem definierten Schwellwert (z. B. 10–15 Minuten).
Instabile Tests (Flaky Tests) im Smoke Test: Wenn Smoke Tests unzuverlässig sind und gelegentlich ohne echten Fehler fehlschlagen, verliert das Team das Vertrauen in das Quality Gate. Investieren Sie in stabile Testautomatisierung – z. B. mit robusten Komponentenerkennungsmechanismen wie sie QF-Test bietet – und eliminieren Sie Flakiness konsequent aus der Smoke-Suite.
Verwechslung von Smoke Test und Sanity-Test: In vielen Teams werden beide Begriffe synonym verwendet, obwohl sie sich in Zweck und Zeitpunkt unterscheiden. Klären Sie teamintern die Definitionen: Smoke Test = Build-Verifikation nach jedem Build; Sanity-Test = gezielte Prüfung nach einem spezifischen Fix oder Feature-Release.
Fehlende Einbindung in die CI/CD-Pipeline: Smoke Tests, die nur manuell ausgeführt werden, verlieren ihren Hauptvorteil – die Geschwindigkeit. Automatisieren Sie die Ausführung konsequent als CI-Trigger und stellen Sie sicher, dass kein Build ohne bestandenen Smoke Test in weitere Teststufen übergeht.
Best Practice
- Halten Sie die Smoke Test-Suite schlank und fokussiert: maximal 10–15 kritische Testfälle, die den Happy Path der wichtigsten Kernfunktionen abdecken.
- Automatisieren Sie den Smoke Test als ersten Schritt in Ihrer CI/CD-Pipeline und definieren Sie ein klares Quality Gate, das bei Fehlschlag den weiteren Build-Prozess stoppt.
- Trennen Sie Smoke Test-Suite und Regressionssuite konsequent – sowohl technisch als auch konzeptionell – um Scope-Creep zu vermeiden.
- Pflegen Sie die Smoke Tests aktiv bei UI- oder Funktionsänderungen und führen Sie regelmäßige Reviews durch, um Flaky Tests zu identifizieren und zu beheben.
Fazit
Smoke Tests sind ein unverzichtbarer Bestandteil moderner Testautomatisierungsstrategien. Als schneller Quality Gate nach jedem Build erkennen sie kritische Fehler frühzeitig, schonen Ressourcen und erhöhen die Release-Sicherheit – ohne hohen Testaufwand. In Kombination mit einer CI/CD-Pipeline und einem zuverlässigen Testautomatisierungstool wie QF-Test lassen sich Smoke Tests stabil, wartungsarm und vollständig automatisiert betreiben. So wird jeder neue Build mit dem notwendigen Vertrauen in die nächste Teststufe entlassen.
Häufig gestellte Fragen (FAQ)
Was ist der Unterschied zwischen Smoke Test und Sanity Test?
Beide Tests sind kurz und fokussiert – aber mit unterschiedlichem Zweck und Zeitpunkt.
Was ist der Unterschied zwischen Smoke Test und Sanity Test?
Beide Tests sind kurz und fokussiert – aber mit unterschiedlichem Zweck und Zeitpunkt.
Wie viele Testfälle sollte ein Smoke Test umfassen?
So wenig wie möglich, so viele wie nötig – der Scope entscheidet über den Nutzen.
Wie viele Testfälle sollte ein Smoke Test umfassen?
So wenig wie möglich, so viele wie nötig – der Scope entscheidet über den Nutzen.
Es gibt keine feste Zahl, aber die Faustregel lautet: Smoke Tests sollten in 10–15 Minuten durchlaufen sein. Das entspricht typischerweise 5–20 Testfällen, die ausschließlich den Happy Path der absolut kritischen Kernfunktionen abdecken. Alles, was über diesen Scope hinausgeht, gehört in den Regressionstest – nicht in den Smoke Test.
Lassen sich Smoke Tests mit QF-Test automatisieren und in CI einbinden?
Ja – QF-Test unterstützt die vollautomatische Ausführung in CI/CD-Pipelines.
Lassen sich Smoke Tests mit QF-Test automatisieren und in CI einbinden?
Ja – QF-Test unterstützt die vollautomatische Ausführung in CI/CD-Pipelines.
Mit QF-Test lassen sich Smoke Tests als dedizierte Testsuite definieren und über den Batch-Modus automatisch in CI-Systeme wie Jenkins, GitLab CI oder TeamCity integrieren. Nach jedem Build wird die Suite automatisch ausgeführt, das Ergebnis als Quality Gate ausgewertet und das Team bei Fehlschlag sofort benachrichtigt – ohne manuellen Eingriff.
Interessiert an QF-Test?
Erzählen Sie uns von sich und wir stellen Kontakt zu QF-Test-Expert:innen her, die Ihnen mehr über unser Produkt erzählen können.
