Smoke-Test: Definition, Checkliste und Smoke vs. Sanity

Ein Smoke-Test (auch Smoke-Testing oder Rauchtest) ist in der Software eine schnelle Reihe von Checks auf einem neuen Build oder Deployment, die bestätigen, dass die wichtigsten Funktionen laufen, bevor jemand Zeit in tiefergehende Tests steckt. Lädt die App nicht, können sich Nutzer nicht anmelden oder bricht der Hauptablauf, wird der Build abgelehnt. Man spricht auch vom Build-Verifizierungstest (Build Verification Testing).

Dieser Leitfaden ist für Entwickler, QA Engineers und Release-Verantwortliche, die Web-Apps ausliefern, oft ohne eigenes QA-Team. Smoke-Tests sind die erste Hürde im QA-Testing.

Was ist ein Smoke-Test?

Ein Smoke-Test beantwortet eine einzige Frage: Lohnt es sich, diesen Build zu testen, oder kann er bedenkenlos live bleiben? Er prüft die wenigen Dinge, die funktionieren müssen. Er ist bewusst schnell und flach.

Das ISTQB-Glossar nennt Smoke-Testen eine Testart, die dir ausreichendes Vertrauen gibt, dass ein Build für das geplante Testen bereit ist. Sein Eintrag zum Build-Verifizierungstest (BVT) beschreibt die automatisierte Form: einen Test der Kernfunktionen, der Stabilität und der Testbarkeit jedes neuen Builds.

Steve McConnell hat diese Praxis mit Daily Build and Smoke Test (IEEE Software, 1996) populär gemacht. Seine Regel gilt bis heute: Teste das ganze System durchgängig, aber versuch nicht, vollständig zu testen. Das MDN-Glossar nennt einfache Beispiele: Startet das Programm, funktionieren die wichtigsten Buttons, und kannst du einen neuen Testnutzer speichern?

Ein Smoke-Test ist die Eingangskontrolle vor tiefergehenden Tests wie explorativem Testen oder dem Abnahmetest (UAT).

Warum heißt es Smoke-Test?

Der Name stammt aus der Hardware. In Lessons Learned in Software Testing führen Cem Kaner, James Bach und Bret Pettichord ihn auf die Elektronik zurück: Du steckst eine neue Platine ein und schaltest den Strom ein. Wenn du Rauch siehst, schaltest du ab, und weitere Tests erübrigen sich.

Klempner und Mechaniker blasen Rauch durch Rohre und Schläuche, um Lecks zu finden. Deshalb tauchen bei der Suche nach „Smoke-Test“ auch Ergebnisse zu Abwasserkanälen und Autos auf. In der Software ist der Rauch eine Seite, die nicht lädt, oder ein Login, der fehlschlägt.

Wann du einen Smoke-Test machst und wer ihn durchführt

Mach einen Smoke-Test jedes Mal, wenn sich etwas an dem ändert, was bei den Nutzern ankommt:

• Nach jedem Build, der in einer Testumgebung landet.
• Nach jedem Deployment auf Staging und in Produktion.
• Nach Änderungen an Konfiguration oder Infrastruktur, etwa an Feature Flags, Secrets, DNS- oder CDN-Einstellungen. Viele Ausfälle nach dem Motto „wir haben doch nichts geändert“ beginnen genau hier.
• Vor einem Bug Bash, einem UAT-Zyklus oder einer explorativen Session, damit nicht ein ganzer Raum voller Leute denselben Absturz findet.

Die CI fährt die automatisierte Stufe bei jedem Build. Wer deployt, übernimmt den manuellen Durchlauf. Die QA oder der Tech Lead ist für die Liste zuständig und hält sie aktuell.

Google Cloud Tech erklärt dieselbe Idee in einem achtminütigen Video auf Englisch:

Was in einen Smoke-Test gehört (und was nicht)

Hier sind sich Teams uneinig. QA Wolf, ein Anbieter von Managed Testing, hält Smoke-Checks auf Infrastrukturebene (die App startet, der Health-Check ist grün, die Datenbank antwortet) und verschiebt Login und Nutzerabläufe in Sanity- oder End-to-End-Tests. LaunchDarklys Leitfaden, MDN und McConnell nehmen dagegen den kritischen Nutzerpfad mit auf: anmelden, die wichtigsten Bedienelemente nutzen, einen Datensatz speichern.

Beide Seiten haben gute Argumente. Infrastruktur-Checks sind schnell und selten flaky, aber ein Build, bei dem sich niemand anmelden kann, ist es nicht wert, getestet zu werden. Nutz deshalb zwei Stufen.

Stufe 1: Läuft die App überhaupt? Das Deployment war erfolgreich, und die erwartete Version ist live. Der Health-Endpoint meldet OK, wichtige Dienste antworten, und die Seite lädt ohne schwerwiegende Konsolenfehler.

Stufe 2: Schafft ein Nutzer das Wichtigste? Ein vorab eingespieltes Testkonto meldet sich an, die Hauptseite lädt mit Daten, und die Kernaktion läuft einmal erfolgreich durch.

Halte beide Stufen breit und flach: 10 bis 15 Checks, jeder mit Ja oder Nein zu beantworten, und jeder Fehlschlag blockiert. Die automatisierte Stufe sollte in unter 5 Minuten durchlaufen, ein manueller Durchlauf in 10 bis 15 Minuten.

Lass Grenzfälle, Validierungsmeldungen, Tests in allen Browsern, Performance und visuellen Feinschliff weg.

Warum sich das lohnt:

• Ein kaputter Build fällt in Minuten auf, nicht erst nach einem Tag Testen.
• Jeder Fehlschlag zeigt auf die letzte Änderung, also ist der Fix schnell gemacht.

Wo die Grenzen liegen:

• Bestanden heißt „lohnt sich zu testen“, nicht „funktioniert“. Die meisten Bugs kommen trotzdem durch.
• Flache Checks übersehen Grenzfälle, schleichende Lecks und alles abseits des Hauptpfads.

Arten von Smoke-Tests

Je nach Methode ist ein Smoke-Test manuell, automatisiert oder hybrid. Beim hybriden Ansatz fährt die CI Stufe 1, und ein Mensch übernimmt Stufe 2. Nach Phase unterscheidet man drei gängige Formen:

• Build-Verifizierung in der CI: Stufe 1 bei jedem Build.
• Nach dem Deployment auf Staging: beide Stufen, bevor die Tester loslegen.
• Smoke-Test in Produktion: Stufe 1 plus eine rein lesende Stufe 2, direkt nach dem Release.

Smoke-Test-Checkliste für ein Web-App-Release (zum Kopieren)

Jeder Punkt hat eine ID, damit in einem Bericht „S7 fehlgeschlagen“ stehen kann und alle wissen, welcher Check kaputt ist. Füll zuerst den Kopfbereich aus: Build, Umgebung, ein Testkonto pro Rolle und die Uhrzeit in UTC.

## Smoke-Test · Build [Version oder Commit-SHA] · [URL der Umgebung] · [Datum, Uhrzeit UTC]
Tester: [Name] · Konten: [eins pro Rolle]

### Verfügbarkeit
- [ ] S1 Deployment grün, erwartete Version live
- [ ] S2 Startseite liefert 200 und wird gerendert
- [ ] S3 Health-Endpoint meldet OK
- [ ] S4 Keine 404-Fehler bei JS-, CSS- oder Font-Dateien

### Frontend
- [ ] S5 Keine neuen roten Konsolenfehler beim Laden und nach dem Login
- [ ] S6 Keine fehlgeschlagenen API-Aufrufe (4xx oder 5xx) auf der Hauptseite

### Anmeldung
- [ ] S7 Mit dem eingespielten Testkonto anmelden
- [ ] S8 Logout beendet die Session

### Kernablauf
- [ ] S9 Dashboard oder Hauptliste lädt mit Daten
- [ ] S10 Kernaktion läuft einmal erfolgreich durch (Zahlungen nur im Testmodus)
- [ ] S11 Suche oder Hauptnavigation funktioniert

### Integrationen
- [ ] S12 Transaktionsmail kommt im Test-Postfach an
- [ ] S13 Drittanbieterdienste antworten (Zahlungen, Karten, Auth)

### Monitoring
- [ ] S14 Kein neuer Fehleranstieg im Error-Tracker

Ergebnis: BESTANDEN (an die Tester übergeben oder Deployment behalten) / NICHT BESTANDEN bei S__ (stoppen, festhalten, melden, ablehnen oder zurückrollen)

Füg die Checkliste in ein GitHub-Issue, einen Pull Request oder Notion ein, dann werden die Kästchen anklickbar. Die letzte Zeile ist die wichtigste: Ein einziger fehlgeschlagener Punkt stoppt den Durchlauf.

Pass die Liste an dein Produkt an:

• SaaS: Ergänze einen Login pro Rolle.
• E-Commerce: Ergänze Warenkorb, Steuern und Versand, mit Zahlungen im Testmodus von Stripe.
• Reine API: Ersetze die Seiten-Checks durch Aufrufe der Endpoints.
• Mobile App: Prüf, ob sie sich installieren lässt, mit ihrem ersten Bildschirm startet, das Backend erreicht und den eingespielten Login akzeptiert.

Mach dann aus jedem Punkt einen Testfall mit ID, Schritten und erwartetem Ergebnis. Eine Testfall-Vorlage hilft dabei.

Beispiele für Smoke-Tests

Drei Beispiele für Smoke-Tests aus verschiedenen Arten von Software:

1. E-Commerce, Staging-Build. Start- und Produktseiten laden, der Checkout akzeptiert eine Stripe-Testkarte, und die Bestellmail kommt im Test-Postfach an.
2. B2B-SaaS, Deployment in Produktion. Ein SSO-Testnutzer meldet sich an. Das Dashboard lädt mit Daten, und ein CSV-Export lässt sich herunterladen.
3. API-Dienst nach einer Konfigurationsänderung. Der Health-Check liefert 200, ein Token wird ausgestellt, und je ein Lese- und ein Schreibzugriff auf einem Testmandanten gelingen.

Speichere das Skript als smoke.sh, setz API auf die Basis-URL von Staging und nutz die Client-Credentials eines Testmandanten:

#!/usr/bin/env bash
set -euo pipefail
curl -fsS "$API/health"
TOKEN=$(curl -fsS -u "$CLIENT_ID:$CLIENT_SECRET" -d grant_type=client_credentials \
  "$API/oauth/token" | jq -r .access_token)
curl -fsS -H "Authorization: Bearer $TOKEN" "$API/v1/projects?limit=1"
curl -fsS -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"smoke-check"}' "$API/v1/projects"

Das Flag -f lässt curl bei jedem 4xx oder 5xx mit einem Fehler abbrechen, und set -euo pipefail stoppt das Skript beim ersten fehlgeschlagenen Aufruf, auch bei der Token-Anfrage innerhalb der Pipe.

Smoke-Test vs. Sanity-Test vs. Regressionstest

So unterscheiden sich die drei.

Warum gibt es beim Sanity-Test so viel Uneinigkeit? Googles SRE-Buch sagt, Smoke-Tests seien auch als Sanity-Tests bekannt, und das sagen auch die englischsprachige Wikipedia und ältere ISTQB-Glossare. Die meisten QA-Teams meinen damit etwas Engeres: eine schnelle Nachprüfung des Bereichs, den ein Fix berührt hat.

Das aktuelle ISTQB-Glossar hat keinen Eintrag für Sanity-Tests. Sein formaler Begriff für das erneute Testen eines Fixes ist der Fehlernachtest (englisch Confirmation Testing). Keine der beiden Lesarten ist falsch: Entscheide dich für eine und schreib sie in deinen Testplan, damit das ganze Team dasselbe meint.

Zwischen Smoke-Test und UAT verläuft die Grenze einfacher: Ein Smoke-Test dauert nach jedem Deployment ein paar Minuten, UAT dagegen Tage fachlicher Tests vor der Abnahme. Regressionstests gehen dort in die Tiefe, wo der Smoke-Test flach geblieben ist, und Visual Regression Testing ergänzt Screenshot-Vergleiche für die UI.

Von den Machern dieser Seite

Genug von langweiligen Screenshots? Probier ScreenSnap Pro.

Schöne Hintergründe, professionelle Anmerkungen, GIF-Aufnahme und sofortiges Teilen in der Cloud, alles in einer App. Einmal 39 $ zahlen, für immer besitzen.

Preis und Funktionen ansehen

So führst du Smoke-Tests durch: manuell und automatisiert

Die meisten Teams starten mit einem manuellen Durchlauf und automatisieren dann Stufe 1.

Ein manueller Smoke-Durchlauf

Eine Person, ein Build, eine Checkliste. Halte die Checkliste in einem zweiten Fenster oder auf einem zweiten Monitor offen, mit Build-ID und Startzeit (UTC) ganz oben.

Markiere jeden Punkt der Reihe nach als bestanden oder fehlgeschlagen, denn spätere Checks hängen von früheren ab. Hör beim ersten Blocker auf: Wenn der Login bei S7 fehlschlägt, sagen dir S8 bis S14 nichts Brauchbares, also halte den Fehler fest und melde ihn.

Stufe 1 in der CI mit Playwright automatisieren

Fang mit zwei Checks an: dem Health-Endpoint und einem Test-Login. In Playwright fügst du dafür in den Testdetails ein Tag hinzu:

import { test, expect } from '@playwright/test';

test('health endpoint is OK', { tag: '@smoke' }, async ({ request }) => {
  const res = await request.get('/api/health');
  expect(res.ok()).toBeTruthy();
});

test('test login shows the dashboard', { tag: '@smoke' }, async ({ page }) => {
  const errors: string[] = [];
  page.on('pageerror', (err) => errors.push(err.message));
  await page.goto('/login');
  await page.getByLabel('Email').fill(process.env.SMOKE_USER!);
  await page.getByLabel('Password').fill(process.env.SMOKE_PASS!);
  await page.getByRole('button', { name: 'Sign in' }).click();
  await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();
  expect(errors).toEqual([]);
});

Setz in playwright.config.ts den Eintrag baseURL: process.env.BASE_URL und füg unter use die Optionen screenshot: 'only-on-failure' und trace: 'retain-on-failure' hinzu (siehe die Testoptionen). Ein fehlgeschlagener Lauf hinterlässt dann einen Screenshot und einen Trace für den Bericht. Mit npx playwright test --grep @smoke führst du nur die getaggten Tests aus.

Mach den Smoke-Job in GitHub Actions zum ersten Job nach deinem Deploy-Job für Staging:

jobs:
  smoke:
    needs: deploy-staging
    runs-on: ubuntu-latest
    env:
      BASE_URL: ${{ vars.STAGING_URL }}
      SMOKE_USER: ${{ secrets.SMOKE_USER }}
      SMOKE_PASS: ${{ secrets.SMOKE_PASS }}
    steps:
      - uses: actions/checkout@v7
      - run: npm ci && npx playwright install --with-deps chromium
      - run: npx playwright test --grep @smoke
      - uses: actions/upload-artifact@v7
        if: failure()
        with: { name: smoke-results, path: test-results/ }
  deploy-production:
    needs: smoke
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: ./deploy.sh production

Der Produktions-Job hängt über den needs-Eintrag vom Smoke-Job ab, also überspringt GitHub ihn, wenn ein Smoke-Test fehlschlägt. Wenn zusätzlich ein Mensch die Produktion freigeben soll, füg eine Umgebung mit erforderlichen Reviewern hinzu. Diese manuelle Freigabe reagiert nicht auf einen fehlgeschlagenen Job, also behalte die Zeile mit needs.

Optionen für Screenshots innerhalb von Tests findest du im Playwright-Screenshot-Leitfaden oder im Selenium-Screenshot-Leitfaden.

Smoke-Tests in der Produktion

Fahr Stufe 1 direkt nach einem Deployment in Produktion, plus eine rein lesende Stufe 2. Nutz ein eigenes Testkonto in einem eigenen Testmandanten und halte jeden Check rein lesend oder umkehrbar.

In Produktion sind Live-Schlüssel für Zahlungen aktiv, also nutz ein internes Testprodukt oder hör vor dem Bezahlschritt auf. Beobachte den Error-Tracker 10 bis 15 Minuten lang, und wenn ein Check fehlschlägt, roll zuerst mit deinem Runbook zurück.

Best Practices und häufige Fehler beim Smoke-Testing

• Die Suite wächst zu einem Regressionslauf an. Begrenze sie auf 10 bis 15 Checks und verschieb den Rest in die Regressions-Suite.
• Flaky Checks werden ignoriert. Repariere oder lösche einen flaky Check noch in derselben Woche. Wiederhol einen Lauf nie so lange, bis er grün ist.
• Ergebnissen fehlt die Build-ID. Vermerke die Version oder den Commit-SHA bei jedem Lauf und in jedem Bericht.
• Checks in Produktion erzeugen echte Bestellungen oder E-Mails. Nutz einen Testmandanten und rein lesende oder umkehrbare Checks.
• Die Liste veraltet. Überprüf sie nach jedem Incident und jedem neuen Kernfeature.

Was du festhältst, wenn ein Smoke-Check fehlschlägt

Wer den Fehler behebt, braucht vier Dinge: den Build, die Umgebung, den fehlgeschlagenen Check und den ersten Fehler.

Die Grundlagen sind dieselben wie bei jedem Bug: Schneide auf den fehlerhaften Bereich zu und ergänze dann einen Pfeil und ein Callout mit Check-ID und Ergebnis, etwa „S7 · erwartet Dashboard · erhalten 502“. Nummerierte Zähler (1, 2, 3) brauchst du nur bei Fehlern über mehrere Schritte, und wenn es um Ablauf oder Timing geht, nimm stattdessen 10 bis 20 Sekunden auf. Leg über Secrets, Tokens, Test-E-Mails und Kundendaten einen deckenden, undurchsichtigen Kasten, denn Weichzeichnen und Verpixeln lassen sich rückgängig machen (der UAT-Leitfaden oben erklärt das ausführlich).

Ein Smoke-Fehlschlag braucht außerdem Nachweise, die an den Build gebunden sind. Sammle diese sechs Punkte:

1. Build und Umgebung. Version oder Commit-SHA, URL der Umgebung, Deploy-Zeit in UTC und jedes Flag oder jede Konfiguration, die sich geändert hat.
2. Der Check. Die S-Nummer, plus erwartet vs. tatsächlich in einer Zeile.
3. Der erste Konsolenfehler. Öffne in Chrome oder Edge die Konsole mit Cmd+Option+J auf dem Mac oder Strg+Shift+J unter Windows. Kopier den ersten roten Fehler, oder klick mit der rechten Maustaste und wähl „Speichern unter“ (Save as) für eine .log-Datei (siehe die Referenz zu den Konsolenfunktionen).
4. Die fehlgeschlagene Anfrage. Aus dem Netzwerk-Tab (Network): Methode, Pfad, Status und Request-ID, etwa POST /api/session liefert 502. Schick eine HAR-Datei nur auf Nachfrage: Der Standardexport von Chrome ist bereinigt (ohne die Header Cookie, Set-Cookie und Authorization), aber prüf URLs und Bodys auf Tokens.
5. CI-Artefakte. Der Screenshot (only-on-failure) und der Trace (retain-on-failure) aus dem Smoke-Job.
6. Browser und Konto. Browser und Version (chrome://version), Betriebssystem, Bildschirmgröße und Zoom sowie die Rolle des Testkontos. Niemals das Passwort.

Bug-Recorder als Browser-Erweiterung können Konsolen- und Netzwerk-Logs automatisch anhängen. Mit einem Desktop-Aufnahmetool fügst du sie aus den DevTools hinzu.

Die integrierten Tools decken die Aufnahme ab (siehe Apples Anleitung für Screenshots und die Tastenkürzel unten). Um eine Request-ID zu kopieren, die sich in einem Toast nicht markieren lässt, nutzt du auf dem Mac Live Text in der Vorschau und unter Windows die Textaktionen im Snipping Tool. Weitere Optionen: Text aus einem Screenshot auf dem Mac kopieren und OCR-Software für Windows.

Keine Aufnahme-App auf dem Testrechner? Das kostenlose Tool zur Bildannotation hat ein gefülltes Rechteck für Tokens und E-Mail-Adressen, und du kannst Text aus einem Bild extrahieren, um eine Fehlermeldung oder Request-ID zu kopieren.

ScreenSnap Pro erledigt die Aufnahme in einer App: Nimm den Bereich auf und ergänze dann einen Pfeil, ein Callout mit Check-ID und Ergebnis und nummerierte Zähler (1, 2, 3) für die Reihenfolge der Schritte. Ein gefülltes Rechteck deckt Tokens und Test-E-Mails ab, und OCR kopiert Fehlertexte und Request-IDs. Bei einem Fehler im Ablauf oder Timing nimmst du ein kurzes Video auf (mit Mikrofon, wenn du kommentieren willst), schneidest es im integrierten Video-Editor zu und exportierst es als MP4 oder als GIF, das sich direkt inline abspielt.

Vorlage für die Smoke-Fehlermeldung (zum Kopieren)

Poste diese Stopp-Meldung im Release-Channel, sobald ein Check fehlschlägt. Sie sagt nur, dass der Build blockiert ist und warum. Der vollständige Fehlerbericht folgt danach.

[SMOKE FAIL] S[Nummer] [Check] · [Umgebung] · Build [Version] ([SHA])
Build:        [Version] ([SHA]), deployt um [hh:mm] UTC
Umgebung:     [URL]
Zeit (UTC):   [jjjj-mm-tt hh:mm]
Check:        S[Nummer] [Text des Checks]
Erwartet:     [eine Zeile]
Tatsächlich:  [eine Zeile + Request-ID]
Nachweise:    [angehängte Dateien]
Betroffen:    [alle Nutzer / eine Rolle / ein Browser]
Entscheidung: [abgelehnt / zurückgerollt / Hotfix läuft]
Owner:        [Name]

Für einen schnellen Hinweis reicht ein Share-Link im Release-Channel. Häng danach die Screenshot- und Clip-Dateien an das Jira- oder GitHub-Issue, damit die Nachweise beim Fehler bleiben. Leg den Fehler mit den Feldern einer Bug-Report-Vorlage an, und sieh dir an, wie du Screenshots in Jira anhängst oder dafür ein GitHub Issue Template baust.

Durchgespieltes Beispiel: Login auf Staging liefert 502

Eine geänderte Umgebungsvariable legt den Login auf Staging lahm. Der Tester kopiert die Request-ID aus dem Toast per OCR, findet einen CORS-Fehler in der Konsole und einen 502 bei /api/session im Netzwerk-Tab und lehnt den Build ab:

Häufig gestellte Fragen

Was sind Smoke-Tests?

Smoke-Tests sind eine kurze Reihe von Checks, die bei jedem neuen Build oder Deployment laufen. Sie bestätigen, dass die App startet, die Hauptseite lädt, sich ein Testnutzer anmelden kann und die Kernaktion funktioniert. Schlägt ein Check fehl, wird der Build abgelehnt, bevor tiefergehende Tests beginnen.

Wie lange dauert ein Smoke-Test?

Eine automatisierte Smoke-Suite sollte in unter 5 Minuten fertig sein, damit sie bei jedem Deployment laufen kann. Ein manueller Durchlauf mit 10 bis 15 Checks dauert etwa 10 bis 15 Minuten. Dauert es deutlich länger, ist daraus eine Regressions-Suite geworden.

Was ist der Unterschied zwischen Smoke-Test und Sanity-Test in der Softwareentwicklung?

Ein Sanity-Test ist eine schnelle, eng begrenzte Prüfung, ob ein bestimmter Fix oder eine Änderung funktioniert. Ein Smoke-Test ist breit und flach, prüft nach jedem Build oder Deployment die kritischen Pfade des ganzen Builds und kommt zuerst. Die Vergleichstabelle oben zeigt Umfang, Zeitpunkt und Zuständigkeiten.

Welches Tool wird für Smoke-Tests verwendet?

Für Checks der Web-UI nutzen Teams Playwright, Cypress oder Selenium, und bei APIs decken curl oder Postman Health-Checks und Token-Aufrufe ab. Ein CI-Runner wie GitHub Actions, GitLab CI oder Jenkins führt die Suite nach jedem Deployment aus. Ein manueller Durchlauf braucht nur die Checkliste und die DevTools.

Ist ein Smoke-Test dasselbe wie ein Build-Verifizierungstest?

Im Großen und Ganzen ja: Das ISTQB definiert einen Build-Verifizierungstest als automatisierten Test der Kernfunktionen, der Stabilität und der Testbarkeit jedes neuen Builds. Das ist die automatisierte Stufe eines Smoke-Tests. Smoke-Testing ist der weitere Begriff und umfasst auch manuelle Durchläufe nach Deployments.

Wer führt Smoke-Tests durch?

Die CI-Pipeline fährt die automatisierte Stufe bei jedem Build, und der Entwickler oder Release-Verantwortliche, der deployt, übernimmt den manuellen Durchlauf. Die QA ist für die Checkliste zuständig und aktualisiert sie nach Incidents. In Teams ohne Tester übernimmt das stattdessen der Tech Lead.

Kann man Smoke-Tests automatisieren?

Ja, und Stufe 1 sollte automatisiert sein. Health-Checks, Versions-Checks und ein Test-Login lassen sich mit Playwright oder curl leicht skripten und laufen in unter 5 Minuten. Behalte einen kurzen manuellen Durchlauf für das, was Skripte übersehen, etwa ein kaputtes Layout.

Werden Smoke-Tests in der Produktion durchgeführt?

Ja, direkt nach jedem Deployment in Produktion. Fahr rein lesende oder umkehrbare Checks mit einem eigenen Testkonto in einem Testmandanten und beobachte den Error-Tracker. Leg nie echte Bestellungen an, verschick keine echten E-Mails, und wenn ein Check fehlschlägt, roll zuerst zurück und debugge danach.

Vor deinem nächsten Deployment

Kopier die Checkliste in deine Release-Vorlage, tagge deine ersten beiden Playwright-Checks mit @smoke und einige dich mit deinem Team darauf, was „Sanity“ bei euch heißt. Sobald der Smoke-Test bestanden ist, veröffentlichst du deine Release Notes.

Wenn deine Smoke-Läufe in einem Screenshot und einem kurzen Clip enden, bündelt ScreenSnap Pro alles rund um die Aufnahme in einer App: Bereichsaufnahme, Callouts, nummerierte Zähler, Schwärzen mit deckenden Kästen, OCR und Bildschirmaufnahme. Es ist ein einmaliger Kauf für 39 $: 1 Lizenz für 2 Computer (2 Aktivierungen, Mac oder Windows). Zu den Preisen.