Was ist Smoke Testing?

Was ist Smoke Testing?

Smoke Testing ist eine schnelle, flache Reihe von Checks an einem neuen Build. Sie bestätigt, dass die wichtigsten Funktionen laufen, bevor jemand Zeit in tiefere Tests investiert. Startet die App nicht, schlägt der Login fehl oder liefert ein zentraler Endpoint einen Fehler, wird der Build sofort abgelehnt. Man spricht auch von Build Verification Testing (BVT).

Diese Seite liefert die kurze Definition. Den ausführlichen Leitfaden mit Checkout-Beispiel und einer Anleitung zur Automatisierung finden Sie im Blog (auf Englisch): Smoke Testing in Software Testing.

Was ein Smoke Test prüft

Ein Smoke Test deckt die Breite ab, nicht die Tiefe. Er berührt jeden geschäftskritischen Pfad einmal und geht weiter.

• Die Anwendung startet und der Health-Endpoint antwortet mit 200.
• Ein Nutzer kann sich anmelden.
• Der wichtigste Funktionspfad läuft, zum Beispiel Suche, In den Warenkorb und Aufruf der Checkout-Seite.
• Die App erreicht Datenbank, Cache und Queue ohne Timeout.
• Die zentralen JavaScript- und CSS-Dateien laden mit 200 statt mit 404.

Validierungsregeln, Randfälle, Sicherheitsprüfungen und das Verhalten unter Last gehören nicht in einen Smoke Test. Dafür sind Regressionstests, Funktionstests und Lasttests da.

Wann er läuft

1. Bei jedem CI-Build, als erste Stufe. Schlägt er fehl, läuft der Rest der Pipeline nicht.
2. Nach jedem Deployment auf Staging oder Produktion, bevor Traffic auf die neue Version geleitet wird.
3. Nach Infrastrukturänderungen wie einem neuen DNS-Eintrag, einem TLS-Zertifikat oder einem Datenbank-Failover, auch wenn sich der Code nicht geändert hat.
4. Vor einem Lasttest. Ein 30-minütiger Test gegen einen Build mit kaputtem Login erzeugt nur Rauschen.

Beispiel

Ein Onlineshop spielt ein neues Release aus. Die Smoke-Suite ruft die Startseite auf, führt eine Suche aus, legt ein Produkt in den Warenkorb, öffnet die Checkout-Seite und fragt den Health-Endpoint ab. Fünf Checks, je einmal ausgeführt, fertig in Sekunden bis wenigen Minuten. Liefert die Checkout-Seite einen 500er, stoppt der Rollout und das Team untersucht genau diesen einen Fehler, statt Hunderte roter Ergebnisse aus einem vollen Regressionslauf zu lesen.

Smoke-, Sanity- und Regressionstests

• Smoke Testing ist breit und flach: Lebt dieser Build genug, um weiter getestet zu werden?
• Sanity Testing ist eng: Verhält sich nach einem kleinen Fix genau dieser Bereich richtig?
• Regressionstests sind breit und tief: Hat diese Änderung etwas kaputt gemacht, das vorher funktionierte? Sie laufen, nachdem Smoke bestanden ist.

Smoke Testing für APIs und Web-Apps

Bei einem HTTP-Service kann ein Smoke Test aus ein paar Requests mit Assertions auf Status und Body bestehen. In k6 heißt das: ein virtueller Nutzer, eine Iteration und ein check() pro Request. In JMeter ist es eine Thread Group mit einem Thread und einem Durchlauf plus einer Response Assertion an jedem Sampler. In Java-Projekten ergibt eine TestNG-Gruppe für die kritischen Tests ein Smoke-Set, das sich separat ausführen lässt.

Ein Smoke Test vom Laptop beweist nicht, dass öffentliches DNS, CDN und Zertifikatskette funktionieren. Dieselben Checks aus der Cloud gegen die öffentliche URL tun das. Geplantes API-Monitoring ist im Grunde ein Smoke Test, der nie aufhört: LoadFocus API Monitoring führt Ihre kritischen Requests zeitgesteuert aus der Cloud aus und alarmiert, sobald einer fehlschlägt. Zum Lasttest, der nach dem Smoke Test folgt, siehe k6 Lasttests.

Häufige Fehler

• Die Suite wachsen lassen. Dauert sie zehn Minuten, ist sie eine Regressionssuite und läuft nicht mehr zuerst.
• Instabile Checks dulden. Ein Smoke Test, der zufällig fehlschlägt, bringt das Team dazu, ihn zu ignorieren.
• Grün mit korrekt verwechseln. Bestanden heißt: Der Build ist weitere Tests wert, nicht: er ist fehlerfrei.
• Nur im eigenen Netzwerk laufen lassen. Dabei bleiben DNS-, CDN- und Zertifikatsprobleme unsichtbar.
• Die Suite nie pflegen. Kommt ein neuer kritischer Ablauf hinzu, nehmen Sie ihn auf; wird einer abgeschaltet, entfernen Sie ihn.

Häufige Fragen zum Smoke Testing

Ist Smoke Testing dasselbe wie Build Verification Testing?

Ja. Build Verification Testing (BVT) und Build Acceptance Testing sind andere Namen für dieselbe Praxis: ein schneller Check, ob ein neuer Build stabil genug für tiefere Tests ist.

Wie lange sollte ein Smoke Test dauern?

Sekunden bis wenige Minuten. Braucht Ihre Suite zehn Minuten, teilen Sie sie auf und behalten nur die wirklich kritischen Checks als Smoke.

Sollten Smoke Tests automatisiert sein?

Ja, überall dort, wo es eine Pipeline gibt, denn ein Gate, das Builds blockiert, kann nicht auf einen Menschen warten. Eine Checkliste genügt für ein junges Projekt, aber jeder Check, den Sie bei jedem Release wiederholen, sollte automatisiert werden.

Was ist der Unterschied zwischen Smoke Testing und Sanity Testing?

Smoke Testing ist breit und flach und läuft bei jedem Build. Sanity Testing ist eng und läuft nach einer bestimmten Änderung, um zu bestätigen, dass dieser eine Bereich jetzt funktioniert.

Können Smoke Tests gegen Produktion laufen?

Ja, mit lesenden oder klar gekennzeichneten Testaktionen. Nach einem Deployment oder fortlaufend als geplanter Monitor bestätigen sie, dass das Release tatsächlich Nutzer bedient.

Heißt ein bestandener Smoke Test, dass die Software fehlerfrei ist?

Nein. Er heißt nur, dass der Build stabil genug für tiefere Tests ist. Randfälle, Logikfehler und Performanceprobleme brauchen Regressions-, Funktions- und Lasttests.