Release-Smoke-Tests, die Gründer in 10 Minuten durchführen können

Was ein Smoke-Test ist (und warum er nach dem Deploy wichtig ist)

Ein Smoke-Test ist eine schnelle Prüfung, die Sie direkt nach einem Release durchführen, um eine Frage zu beantworten: Funktioniert das Produkt noch in den wichtigsten Bereichen? Es geht nicht darum, jeden Bug zu finden. Es ist ein schneller Pass/Fail-Gate, das zuerst die Fehler auffängt, die echte Nutzer treffen.

Denken Sie daran als die minimale Abfolge von Aktionen, die ein Kunde ausführt: einloggen, die Hauptaktion ausführen (etwas erstellen oder aktualisieren), eine wichtige E-Mail erhalten und (falls kostenpflichtig) eine Zahlung abschließen. Wenn einer dieser Bereiche kaputt ist, wollen Sie das innerhalb von Minuten wissen, nicht erst nachdem Support-Tickets sich stapeln.

Smoke-Tests ersetzen kein komplettes QA. Sie ersetzen keine automatisierten Tests, keine tiefgehenden Edge-Case-Tests, keine Accessibility-Überprüfung oder Sicherheitstests. Und sie sollten auch nicht eine Stunde dauern. Wenn Ihre Release-Prüfung eine Tabelle und ein Meeting braucht, wird sie übersprungen. Der Punkt ist Geschwindigkeit und Wiederholbarkeit.

Viele Fehler treten erst nach dem Deploy auf, weil die Produktion sich anders verhält als Ihr Laptop. Die Ursachen sind meist langweilig, aber brutal: falsche Umgebungsvariablen (API-Keys, E-Mail-Einstellungen, Payment-Webhooks), rotierte Secrets, Berechtigungsunterschiede, Migrationen, die zwar liefen, aber nicht dem entsprechen, was der Code erwartet, oder Caching/CDN-Verhalten, das Routen, Cookies oder Header verändert.

Das ist besonders nützlich für Gründer, die schnell mit kleinen Teams ausliefern, und für alle, die auf AI-generierten Code und schnelle Prototypen setzen. Wenn Sie schnell arbeiten, kann ein einfacher, konsistenter Smoke-Test den Unterschied zwischen einem ruhigen Launch und einer Feuerwehrübung ausmachen.

Bevor Sie starten: 2 Minuten Vorbereitung

Ein 10-Minuten-Smoke-Test funktioniert am besten, wenn Sie nicht improvisieren. Verbringen Sie zwei Minuten damit, ein kleines „Test-Kit“ einzurichten, damit die Ergebnisse klar und wiederholbar sind.

Wählen Sie zuerst die genauen Nutzer, mit denen Sie testen. Verwenden Sie ein normales Konto und ein Admin-Konto (oder welche Rollen Ihre App auch hat). Stellen Sie sicher, dass die Konten in einem sauberen Zustand sind: kein halb abgeschlossenes Onboarding, keine abgelaufene Trial, kein gesperrtes Profil.

Bestätigen Sie als Nächstes, wo Sie testen. Notieren Sie die deployed Umgebung (Production, Staging oder ein Preview) und die exakte URL. Viele „Bugs“ entstehen, weil jemand am falschen Ort testet oder zwei Versionen durcheinanderbringt.

Stellen Sie schließlich sicher, dass Sie die zwei Dinge verifizieren können, die Sie nicht vollständig über die UI sehen: E-Mails und Zahlungen. Öffnen Sie ein Postfach für den Testnutzer (und prüfen Sie Spam/Promotion). Wenn Ihre App Geld verlangt, bestätigen Sie, dass Sie im richtigen Modus sind (Test vs Live) und Zugriff auf den Ort haben, an dem Sie einen erfolgreichen Charge überprüfen.

Halten Sie eine einfache Notiz offen und protokollieren Sie die Ergebnisse, während Sie vorgehen. Verlassen Sie sich nicht auf Ihr Gedächtnis.

Halten Sie diese Dinge bereit:

• Test-User- und Admin-Zugangsdaten
• Name der Umgebung und die URL, die Sie testen
• Zugriff auf das Test-Postfach (und eine Möglichkeit, darin zu suchen)
• Wo Sie Zahlungsergebnisse verifizieren (falls zutreffend)

Wenn später etwas fehlschlägt, sparen diese Notizen (und ein Screenshot, falls nötig) Stunden an Hin-und-Her.

Der 10-Minuten-Durchlauf: die einfache Schritt-für-Schritt-Route

Stellen Sie einen 10-Minuten-Timer und führen Sie jedes Mal dieselbe Route aus. Das Ziel ist nicht zu beweisen, dass alles funktioniert. Es geht darum, die Fehler zu finden, die reale Nutzer nach einem Deploy blockieren.

Verwenden Sie ein privates Browserfenster, damit Sie keinen falschen Erfolg durch gecachte Sessions erhalten.

Die feste Reihenfolge (nicht improvisieren)

Führen Sie die Prüfungen in strenger Reihenfolge aus. So können Sie Ergebnisse zwischen Releases vergleichen und genau erkennen, wo etwas gebrochen ist.

1. Öffnen Sie die App wie ein neuer Nutzer (Landing Page bis zur App).
2. Loggen Sie sich ein (oder registrieren Sie sich) und bestätigen Sie, dass Sie auf dem erwarteten Startbildschirm landen.
3. Führen Sie die eine Kernaktion aus, auf der Ihr Produkt basiert (etwas erstellen, aktualisieren und ansehen).
4. Lösen Sie eine Benachrichtigung aus, auf die Nutzer angewiesen sind (E-Mail oder In-App).
5. Falls Sie Geld verlangen, führen Sie einen kleinen Zahlungsfluss komplett in Testmodus aus.

Was zu tun ist, wenn etwas kaputtgeht

Behandeln Sie den ersten ernsten Fehler als Stoppschild. Klicken Sie nicht weiter „um mehr Infos zu sammeln“. Sie vermischen dann Symptome und verschwenden Zeit.

Schreiben Sie eine kurze Fehlernotiz, die die Reproduktion erleichtert: was Sie geklickt haben, was Sie erwartet haben, was passiert ist und jede Fehlermeldung. Ein Screenshot ist hilfreich, aber die Schritte sind wichtiger.

Nach einer Behebung testen Sie zuerst den gebrochenen Bereich erneut mit denselben Schritten. Wenn er besteht, fahren Sie in der Reihenfolge fort. Zufälliges Nachprüfen verwirrt und verschleiert die Ursachen.

Go/No-Go in einer Minute

Bevor Sie deployen, entscheiden Sie, was bestehen muss. Halten Sie es klein: Login funktioniert, der zentrale Create/Edit/View-Flow funktioniert, wichtige E-Mails kommen an und Zahlungen gelingen (falls zutreffend). Wenn ein Muss-Punkt fehlschlägt, ist es ein No-Go, auch wenn sonst alles gut aussieht.

Login- und Authentifizierungs-Checks

Die meisten Smoke-Tests sollten mit Auth beginnen, weil eine kleine Änderung alle aussperren kann. Verwenden Sie ein privates Fenster (oder einen anderen Browser), damit Sie nicht versehentlich eine gecachte Session verwenden.

Die 5 Checks, die die meisten Auth-Fehler aufdecken

Führen Sie diese schnell und in der Reihenfolge aus und stoppen Sie, sobald etwas seltsam aussieht:

• Erstellen Sie ein brandneues Konto (falls Anmeldung aktiviert) und bestätigen Sie, dass Sie auf der erwarteten Seite landen.
• Loggen Sie sich aus, und dann wieder mit demselben Benutzer ein.
• Öffnen Sie eine geschützte Seite, während Sie ausgeloggt sind (z. B. Ihr Dashboard-URL) und bestätigen Sie, dass Sie blockiert oder zur Anmeldung weitergeleitet werden.
• Nutzen Sie „Passwort vergessen“ und schließen Sie den Reset ab. Bestätigen Sie, dass die E-Mail ankommt und der Reset-Link in einem privaten Fenster funktioniert.
• Nach dem Zurücksetzen loggen Sie sich erneut ein und bestätigen, dass Sie nach einem Refresh eingeloggt bleiben.

Halten Sie die Messlatte einfach. Sie bestätigen, dass die App eine Session erstellen kann, sie halten kann und private Seiten schützt.

Ein häufiger realer Fehler: Nach einem Deploy werden Cookies für die falsche Domain gesetzt oder als „secure“ markiert, sodass sie in Ihrer Umgebung brechen. Das Symptom sieht aus wie „Login funktioniert“, aber bei jedem Refresh wird man ausgeloggt.

Wenn Ihre App Google-/GitHub-Login unterstützt, machen Sie einen schnellen Durchgang damit, aber lassen Sie ihn nicht das E-Mail/Passwort-Check ersetzen. Social-Auth kann funktionieren, während die eigene Session-Verwaltung kaputt ist.

Wenn ein Schritt fehlschlägt, notieren Sie den genauen Bildschirm und die Meldung.

Kern-CRUD-Flows in unter 3 Minuten

CRUD heißt Create, Read/View, Update, Delete. Wenn einer dieser Punkte nach einem Deploy kaputtgeht, merken Nutzer es sofort. Das Ziel ist kein perfekter Test, sondern ein schnelles Signal, dass Ihre App noch benutzbar ist.

Wählen Sie ein „Kernobjekt“, auf dem Ihr Produkt lebt (ein Projekt, eine Aufgabe, ein Kunde, eine Rechnung, ein Listing). Verwenden Sie ein Testkonto und führen Sie jedes Mal dieselbe Schleife aus.

Die 3-Minuten-CRUD-Schleife

Bewegen Sie sich schnell und halten Sie es simpel:

• Erstellen Sie einen neuen Datensatz mit einem kurzen, eindeutigen Namen wie „Smoke 2026-01-16 10:05“. Bestätigen Sie, dass er gespeichert wird und Sie dort landen, wo erwartet.
• Finden Sie ihn erneut in der Hauptliste (oder dem Dashboard). Wenn Suche oder Filter wichtig sind, nutzen Sie sie einmal.
• Bearbeiten Sie ein offensichtliches Feld (umbenennen). Prüfen Sie zwei Stellen, an denen der Wert erscheinen sollte (Detailseite + Listenansicht).
• Löschen Sie ihn. Bestätigen Sie nach einem Refresh, dass er wirklich weg ist, nicht nur verborgen.
• Testen Sie einmal eine „fehlerhafte Eingabe“: lassen Sie ein Pflichtfeld leer, fügen Sie sehr langen Text ein oder special Characters. Sie wollen klare, verständliche Fehlermeldungen.

Wenn etwas fehlschlägt, protokollieren Sie, was Sie getan haben und was Sie gesehen haben. „Klick Save -> ewiges Laden“ ist hilfreicher als „CRUD kaputt“.

Wie ein „guter Fehler“ aussieht

Eine gute App blockiert fehlerhafte Eingaben mit einer kurzen Meldung wie „Name ist erforderlich.“ Eine schlechte App zeigt eine leere Seite, rohen Fehlertext oder verwirft Änderungen stillschweigend.

Wenn Sie einen Datensatz umbenennen und die Detailseite aktualisiert wird, die Liste nach Refresh aber noch den alten Namen zeigt, deutet das oft auf Caching, ein fehlgeschlagenes Hintergrund-Update oder ein partielles Deploy hin.

E-Mail- und Benachrichtigungs-Checks

E-Mail ist der Ort, an dem „in der App sah alles gut aus“ zu „Nutzer denken, es ist kaputt“ wird. Ein schneller E-Mail-Check ist einer der wertvollsten Teile eines Smoke-Tests, weil er fehlende Keys, falsche Templates und blockierten Versand auffängt.

Lösen Sie eine echte transaktionale E-Mail aus dem Produkt aus (nicht aus einem Admin-Tool). Gute Kandidaten sind Passwort-Reset, Einladung oder eine Quittung.

Fokussieren Sie den Check:

• Bestätigen Sie, dass die E-Mail innerhalb weniger Minuten ankommt.
• Bestätigen Sie, dass Absender/From-Adresse korrekt aussieht (kein Platzhalter).
• Prüfen Sie auf offensichtliche Template-Probleme (z. B. {{name}} wird angezeigt).
• Klicken Sie auf die Hauptschaltfläche und bestätigen Sie, dass sie auf die richtige Seite führt und die Aktion funktioniert.

Achten Sie auf Anzeichen, die nach Deploy auftreten, obwohl die UI sauber aussieht: lange Verzögerungen (Worker/Queues), Duplikate (Retries ohne Idempotenz), fehlende Variablen, falsches Branding/Links für die Umgebung oder Links, die öffnen, aber beim letzten Schritt fehlschlagen.

Wenn Sie Invite-E-Mails verwenden, machen Sie einen vollständigen Durchlauf: senden Sie eine Einladung, öffnen Sie sie in einem anderen Browser (oder privaten Fenster), akzeptieren Sie sie und bestätigen Sie, dass Sie im richtigen Workspace/Konto landen.

Beispiel: Sie testen Passwort-Reset, die E-Mail kommt an, aber der Button öffnet eine Seite mit „Token ungültig“. Das deutet oft auf eine Diskrepanz in Ihrer App-URL, Cookie-Domain oder Secret-Keys zwischen den Umgebungen hin.

Zahlungen und Abrechnung prüfen

Zahlungen fallen nach einem Deploy auf vorhersehbare Art aus: Checkout funktioniert nicht mehr, der Erfolgscallback erreicht Ihre App nicht, oder der Nutzer zahlt, sieht aber weiterhin keinen bezahlten Status. Ein kurzer Zahlungs-Check ist einer der wertvollsten Tests.

Die eine erfolgreiche Zahlung

Wählen Sie den günstigsten Plan (oder einen $1-Testartikel) und führen Sie einen kompletten Kauf durch: von Preisübersicht bis Quittung.

• Starten Sie den Checkout und bestätigen Sie Betrag, Währung und Plannamen sind korrekt.
• Schließen Sie die Zahlung ab und prüfen Sie, dass Sie auf einer klaren Erfolgsseite landen.
• Aktualisieren Sie die App und bestätigen Sie, dass sich der Nutzerstatus ändert (aktiver Plan, freigeschalteter Zugriff, gutgeschriebene Credits – je nachdem, was Sie verkaufen).
• Öffnen Sie das Nutzerkonto- oder Billing-Panel und bestätigen Sie, dass der Status mit Ihrem Kauf übereinstimmt.

Wenn Sie Webhooks verwenden, treten hier oft Probleme auf. Ein häufiger Fehler: Die Zahlung gelingt, aber der Zugriff wird nicht aktualisiert, weil Webhook-Secret, Endpoint oder Umgebungsvariable geändert wurde.

Fehler-, Abbruch- und Rückerstattungswege

Führen Sie absichtlich einen „schlechten“ Ablauf durch (Abbruch im Checkout, Karte, die fehlschlägt, oder einen Fehlerzustand, den Ihr Provider unterstützt). Nutzer sollten eine normale Meldung sehen, kein ewiges Laden.

• Brechen Sie die Zahlung ab oder lassen sie fehlschlagen und bestätigen Sie, dass die App erklärt, was passiert ist und was als Nächstes zu tun ist.
• Bestätigen Sie, dass der Nutzer nicht als bezahlt markiert wird (kein freigeschalteter Zugriff, keine gutgeschriebenen Credits).
• Wenn Ihr Produkt Rückerstattungen oder Kündigungen unterstützt, testen Sie diesen Flow einmal und bestätigen Sie, dass sich der Status nach dem Refresh aktualisiert.

Prüfen Sie abschließend, was Ihre App anzeigt und sendet. UI und E-Mails sollten keine vollständigen Kartennummern, Sicherheitscodes, API-Keys oder rohe Fehlermeldungen zeigen. Eine gute Regel: Wenn Sie es nicht in einen Support-Chat kopieren würden, zeigen Sie es keinem Kunden.

Kurze Checkliste (kopieren und wiederverwenden)

Kopieren Sie das in Ihre Release-Notes, damit Sie jedes Mal dieselben Checks ausführen. Halten Sie es konsistent. Ziel ist, die häufigen „es funktionierte gestern noch“-Fehler direkt nach dem Deploy zu fangen.

Release: __________ Datum/Zeit: __________ Umgebung: __________

Was sich in diesem Release geändert hat (1–2 Zeilen):

Wenn etwas fehlschlägt, schreiben Sie die kleinste hilfreiche Information für die Fehlerbehebung: den genauen Schritt, die verwendete Nutzer-E-Mail und den Fehlertext.

Go/No-Go: ________ Owner: ________ Falls No-Go, Rollback? ________ Follow-up-Tickets: ________

Häufige Fehler, durch die Smoke-Tests reale Probleme übersehen

Die größte Falle ist, die App zu testen, wie Sie sie sich wünschen, nicht wie Ihre Nutzer sie tatsächlich bekommen. Ein Smoke-Test sollte sich ein bisschen lästig anfühlen: frische Browsersession, echte Domain, echte Daten und dieselben Berechtigungen wie ein normaler Nutzer.

Ein häufiger Fehler ist, als Entwickler oder Admin eingeloggt zu bleiben. Das kann kaputte Berechtigungen, fehlende Onboarding-Schritte und Seiten verbergen, die nur funktionieren, weil Sie bereits Seed-Daten haben. Nutzen Sie ein Inkognito-Fenster und ein gewöhnliches Nutzerkonto oder erstellen Sie jedes Mal ein neues.

Ein weiterer Fehler ist, in der falschen Umgebung zu testen. Wenn Sie in einer Preview bauen, Kunden aber Production nutzen, können Sie genau die Dinge verpassen, die nach Deploy brechen: falsche Umgebungsvariablen, fehlende Migrationen oder eine falsch konfigurierte Callback-URL.

E-Mail ist besonders tückisch. Lokal mag alles mit einem Dev-Postfach funktionieren, in Produktion fällt es, weil ein Provider-Key fehlt, eine Sending-Domain nicht verifiziert ist oder Nachrichten im Spam landen. Behandeln Sie jedes Deploy so, als könnte E-Mail kaputt sein, bis Sie eine echte Nachricht sehen.

Auth ist ein weiterer häufiger Bruchpunkt. Wenn Sie nur testen, dass „Einloggen funktioniert“, können Sie trotzdem mit kaputtem Logout, Passwort-Reset oder Session-Expiry ausliefern.

Einige Gewohnheiten machen Ihren Smoke-Test treffsicherer:

• Testen Sie als brandneuer Nutzer und als normaler bestehender Nutzer (nicht nur als Admin).
• Testen Sie in der echt deployed Umgebung, nicht nur lokal oder in einer Preview.
• Verifizieren Sie, dass eine tatsächliche E-Mail ankommt (und der Link darin funktioniert).
• Vergessen Sie Logout und Passwort-Reset nicht bei jeder Prüfung.
• Wenn etwas fehlschlägt, ändern Sie nur eine Sache, testen erneut und notieren Sie, was anders war.

Ignorieren Sie nicht „es ist heute nur langsam“. Nutzer treffen Timeouts, klicken doppelt und refreshen mitten im Laden. Wenn eine Seite während Ihres 10-Minuten-Checks flaky ist, ist das oft der erste echte Produktionsfehler.

Beispiel: Einen Post-Deploy-Fehler in Minuten finden

Maya betreibt eine kleine SaaS. Sie deployed eine Änderung am Freitag, die „nur UI betrifft“. Bevor sie das Update ankündigt, führt sie ihren Smoke-Test in einem privaten Fenster aus.

Alles sieht gut aus, bis sie Passwort-Reset testet. Das Formular akzeptiert ihre E-Mail und zeigt eine Erfolgsmeldung, aber keine Reset-E-Mail kommt an.

Statt zu raten, prüft sie systematisch. Sie erstellt ein brandneues Testkonto, um die Willkommens-E-Mail auszulösen. Diese kommt an. Dann testet sie „E-Mail ändern“ (falls die App eine Bestätigung sendet). Auch diese kommt an. Also ist nicht „alles E-Mail ist kaputt“. Es ist spezifisch der Passwort-Reset-Pfad.

Das deutet auf einen häufigen Post-Deploy-Fehler hin: ein Template, ein Endpoint oder ein Hintergrundjob ist defekt, während der Rest gesund aussieht. In Mayas Fall war die Password-Reset-Nachricht auf eine neue Template-ID umgezogen, aber die Production-Umgebungsvariable zeigte noch auf die alte.

Jetzt trifft sie eine einfache Entscheidung:

• Wenn Nutzer sich nicht einloggen können, rollbacken Sie zuerst und beheben dann.
• Wenn nur Passwort-Resets betroffen sind und der Fix sicher ist, shippen Sie einen Hotfix.
• In jedem Fall posten Sie eine kurze Statusmeldung, damit der Support nicht überrascht ist.

Sie entscheidet sich für einen Hotfix, aktualisiert die Template-ID, deployed neu und führt den Reset-Schritt erneut aus. Die E-Mail kommt unter einer Minute an.

Zum Schluss ergänzt sie ihre Checkliste für das nächste Mal: „Passwort-Reset auslösen und E-Mail bestätigen“ plus „das spezifische E-Mail-Template/Worker prüfen, nicht nur generellen Versand“.

Nächste Schritte, wenn etwas fehlschlägt (und wie FixMyMess helfen kann)

Wenn ein Smoke-Test fehlschlägt, behandeln Sie es als Stoppschild, nicht als kleines Hindernis. Wenn derselbe Fehler zweimal auftritt, Anmeldungen oder Zahlungen blockiert oder ein Sicherheitsproblem (exponierte Daten, merkwürdiger Admin-Zugang, geleakte Keys) vorliegt, stoppen Sie das Release und rollen Sie zurück, wenn möglich.

Eine einfache Regel: Wenn Nutzer sich nicht einloggen, keine Daten erstellen oder nicht bezahlen können, testen Sie nicht länger — Sie liefern ein defektes Produkt aus.

Sammeln Sie vor dem Weiterleiten an jemanden ein kleines Paket an Infos. Das spart Stunden und beschleunigt die Reparatur:

• Exakte Schritte, die Sie durchgeführt haben (1, 2, 3), angefangen von einem frischen Browser-Tab
• Was Sie erwartet haben vs. was passiert ist (inklusive Fehlermeldungen)
• Screenshot oder kurzes Screen-Recording
• Zeitstempel und Zeitzone
• Umgebungsdetails (Production vs Staging, Browser, Account-E-Mail)

Machen Sie dann die Checkliste zur Gewohnheit. Führen Sie sie direkt nach dem Deploy aus und erneut nach jedem Hotfix. Wenn Sie Issues tracken, taggen Sie sie konsistent (login, CRUD, email, payments), damit Muster sichtbar werden.

Wenn Ihre App mit Tools wie Lovable, Bolt, v0, Cursor oder Replit generiert wurde, sind Post-Deploy-Fehler oft Symptome tieferer Probleme: kaputte Auth, exponierte Secrets, unordentliche Architektur oder unsichere Datenbankabfragen. In solchen Fällen reicht das Flicken einer einzelnen Fehlermeldung oft nicht aus.

Wenn Sie einen AI-generierten Codebestand geerbt haben, der nach Deploy immer wieder bricht, kann FixMyMess (fixmymess.ai) ein kostenloses Code-Audit durchführen und anschließend die Ursachen beheben — von Auth- und Logikfixes bis zu Security-Härtung und Deployment-Vorbereitung.