Was ist Smoke Testing?

Was ist Smoke Testing?

Smoke Testing ist eine schnelle, flache Reihe von Checks, die gegen einen frischen Build läuft, um zu bestätigen, dass das System stabil genug ist, um tieferes Testing zu verdienen. Der Name kommt aus der Hardware-QA: Board einschalten; wenn Rauch herauskommt, stoppen. In Software beantwortet es eine einzige Frage: hat der Build etwas so Fundamentales kaputt gemacht, dass kein weiterer Test nützliches Signal liefert?

Ein Smoke Test übt nur die kritischsten Pfade aus. Homepage rendert. Login funktioniert. Ein Core-API-Endpoint gibt 200 zurück. Die Datenbankverbindung öffnet. Wenn irgendeines davon scheitert, wird der Build abgewiesen und der Rest der Test-Suite übersprungen, was CI-Minuten spart und die Regression in Sekunden statt nach einem 40-minütigen Full Run aufdeckt.

Smoke Testing vs Regression Testing vs Full QA

Drei konzentrische Kreise der Abdeckung, jeder beantwortet eine andere Frage:

• Smoke Testing: ist der Build überhaupt lauffähig? Sekunden bis ein paar Minuten. Läuft zuerst.
• Regression Testing: hat diese Änderung etwas kaputt gemacht, das vorher funktionierte? Minuten bis eine Stunde. Läuft nach bestandenem Smoke.
• Full QA / Acceptance Testing: erfüllt jedes Feature noch die Spec? Stunden, oft manuell. Läuft seltener.

Smoke ist das Gate. Es zu überspringen bedeutet, dass eine kaputte-Deploy-Regression in die Regression-Suite rutscht und das volle CI-Budget verbrennt, bevor der Fehler überhaupt gemeldet wird.

Was ein Smoke Test abdeckt

• Applikations-Start. Der Prozess bootet ohne Crash. Health-Endpoint gibt 200 zurück.
• Kritische User-Flows. Sign-in, der Haupt-Feature-Pfad, Checkout (falls Commerce), ein API-Call gegen den meistgenutzten Endpoint.
• Integrations-Handshake. Die App verbindet sich mit ihrer Datenbank, ihrem Cache, ihrer Message Queue. Keine Timeouts beim Boot.
• Statischer-Asset-Verfügbarkeit. Das Haupt-JS-Bundle und CSS laden vom CDN mit einer 200, nicht einer 404 von einem veralteten Hash-Mismatch.
• Konfigurations-Sanity. Erforderliche Env-Vars lösen auf. Kein undefined im gerenderten HTML.

Was ein Smoke Test nicht abdeckt: Edge Cases, Validierungsfehler, jeden Branch eines Workflows, Performance unter Last. Diese gehören in Regression oder in einen Load Test.

Wann einen Smoke Test ausführen

1. Bei jedem CI-Build. Erste Stufe der Pipeline. Wenn es scheitert, stoppt die Pipeline und nichts anderes läuft.
2. Post-Deploy zu Staging oder Production. Bestätigt, dass der Deploy tatsächlich hochgekommen ist, bevor Traffic dorthin geroutet wird. Blue-Green-Deploys gaten den Cut-over auf Smoke-Pass.
3. Nach Infrastruktur-Änderungen. Neuer DNS, neues TLS-Cert, neues Datenbank-Failover-Target. Smoke verifiziert, dass die Integration end-to-end noch funktioniert.
4. Vor einem Release-Day-Load-Test. Kein Punkt darin, einen 30-minütigen Load Test gegen einen Build auszuführen, dessen Login kaputt ist. Smoke zuerst, Load danach.

Wichtige Smoke-Test-Eigenschaften

• Schnell. Sekunden, nicht Minuten. Wenn Smoke 10 Minuten braucht, hört es auf Smoke zu sein und wird eine Mini-Regression-Suite.
• Deterministisch. Flaky Smoke Tests zerstören das Vertrauen in die Pipeline. Eliminieren Sie Timing-Abhängigkeiten, retry nur auf transientem Netzwerk.
• Build-blockierend. Ein gescheiterter Smoke Test stoppt die Pipeline. Kein "gelber" Smoke-Status.
• Billig zu autorisieren. Fünf bis fünfzehn HTTP-Checks plus ein paar JS-Assertions. Nicht überengineeren.

Wie einen Smoke Test ausführen

Für HTTP-basierte Services ist ein kurzes JMeter- oder k6-Skript mit 5-15 Critical-Path-Requests ein solides Smoke-Harness. In k6 setzen Sie vus: 1, iterations: 1 und fügen check()-Assertions auf Status und Body hinzu. In JMeter verwenden Sie eine Thread Group mit 1 User, 1 Loop und Response Assertions auf jedem Sampler.

Für Browser-seitiges Smoke ist ein 60-Sekunden-Playwright- oder Cypress-Skript, das sich einloggt, auf dem Hauptfeature landet und auf ein bekanntes DOM-Element assertet, ausreichend. Alles länger gehört in Regression.

Für Deploy-Time-Smoke gegen eine echte Cloud-Umgebung, führen Sie von LoadFocus aus. Smoke Tests, die auf einem Entwickler-Laptop liefen, sagen Ihnen nicht, ob die Production-CDN-, DNS- und TLS-Chain funktionieren; Smoke aus einer Cloud-Region gegen den öffentlichen Endpoint schon.

Wenn Ihr Team keine Zeit hat, Smoke-Harnesses über mehrere Services zu designen und zu warten, bietet LoadFocus Load Testing Services, wo Ingenieure die Smoke-Skripte bauen, sie in Ihre CI/CD verdrahten und sie gewartet halten, während sich die API-Surface entwickelt.