Was ist Smoke Testing? Die fünf Minuten, die entscheiden, ob weitergetestet wird

Ein Smoke Test ist ein kurzer, flacher Durchgang über die Dinge, die ein Build können muss, bevor jemand Zeit hineinsteckt. Startet er. Kann sich jemand anmelden. Wird die Hauptseite gerendert. Lässt sich ein Datensatz speichern. Fällt eines davon aus, wird der Build abgelehnt und niemand schaut weiter, denn alles danach hieße, einen Build zu testen, der das Testen nie wert war.

Er ist mit Absicht nicht gründlich. Für Gründlichkeit ist der Rest der Suite da, und sie gegen einen kaputten Build laufen zu lassen verschwendet einen Tag damit, auf vierzig Arten zu beweisen, dass die Anmeldung nicht funktioniert.

Woher der Name kommt

Aus der Hardware, und die Geschichte ist wörtlich zu nehmen. Man baut eine Platine zusammen, schaltet den Strom ein und wartet auf Rauch. Raucht es, hat das Messen keinen Sinn mehr: der Fehler ist grob und unmittelbar, und die Platine geht zurück. Klempner benutzen dieselbe Redewendung dafür, Rauch durch Rohre zu pumpen und Lecks zu finden, bevor die Wände zugemacht werden.

Die Software hat den Begriff aus demselben Grund übernommen. Ein Build, der keinen Benutzer anmelden kann, hat Rauch erzeugt, und die richtige Reaktion ist anzuhalten.

Was ein Smoke Test nicht ist

Drei Begriffe werden im Daily synonym verwendet, und sie meinen drei verschiedene Dinge.

Smoke Test

Ist dieser Build überhaupt das Testen wert? Breit und flach, zuerst ausgeführt, bei jedem Build

Regressionstest

Hat etwas aufgehört zu funktionieren, das vorher funktionierte? Tief und langsam, ausgeführt wenn Zeit ist

Ein Sanity Test ist das dritte: eine enge Prüfung, ob eine bestimmte Korrektur wirklich wirkt, ausgeführt nachdem eine Änderung eingeht statt bevor das Testen beginnt. Smoke ist breit und flach, Sanity ist eng und flach, Regression ist breit und tief.

Der praktische Unterschied liegt darin, was bei einem Fehlschlag passiert. Ein fehlgeschlagener Regressionstest ist ein Fehler, der gemeldet wird. Ein fehlgeschlagener Smoke Test ist eine Entscheidung: dieser Build endet hier.

Was hineingehört

Die Regel, die eine Smoke-Suite brauchbar hält, lautet: alles darin muss etwas sein, dessen Ausfall weiteres Testen sinnlos macht. Das ist eine viel kürzere Liste, als es zunächst aussieht.

Eine typische Suite für eine Webanwendung:

1. Die Anwendung startet und die Startseite antwortet mit 200
2. Ein bekannter Benutzer kann sich anmelden
3. Die Hauptliste lädt und zeigt Daten
4. Ein Datensatz lässt sich anlegen und wieder auslesen
5. Ein angemeldeter Benutzer kann sich abmelden

Fünf Prüfungen, ein bis zwei Minuten, und keine Aussagen über Verhalten jenseits von “das ist überhaupt passiert”. Keine Randfälle, keine Validierungsmeldungen, keine Berechtigungsmatrizen. Jedes davon gehört in die Suite, die danach läuft.

Zwei Fehlerbilder sind es wert, benannt zu werden, denn beide sind häufig. Eine Suite, die auf achtzig Prüfungen anwächst, ist kein Smoke Test mehr, sondern eine langsame Regressionssuite unter falschem Namen, und die Leute fangen an, sie zu überspringen. Eine Suite, die nur die Startseite prüft, ist auch keiner: sie läuft auf einem Build durch, auf dem sonst nichts funktioniert.

Wann er läuft, und wer hinsieht

Bei jedem Build, vor allem anderen, und automatisch. Ein Smoke Test, an den sich jemand erinnern muss, ist einer, den an dem Nachmittag niemand ausführt, an dem er etwas gebracht hätte.

Üblich ist eine Stufe in der Continuous Integration, die nach dem Deployment in eine Testumgebung läuft und alles Nachgelagerte absichert. Schlägt sie fehl, hält die Pipeline an, der Build wird nicht weitergereicht, und das Team erfährt es sofort - innerhalb von Minuten nach dem Commit, während die Person, die ihn geschrieben hat, noch weiß, was sie geändert hat.

Diese Unmittelbarkeit ist der größte Teil des Nutzens. Derselbe Defekt, einen Tag später gefunden, kostet jemanden eine Stunde Rekonstruktion, bevor er überhaupt anfangen kann.

Den ersten schreiben

Fangen Sie beim kürzesten Weg an, den ein echter Benutzer durch Ihr Produkt nimmt, und prüfen Sie nur, dass jeder Schritt durchläuft.

• Nehmen Sie fünf Dinge, nicht fünfzig. Wenn Sie nicht begründen können, dass ein Ausfall weiteres Testen sinnlos macht, ist es keine Smoke-Prüfung.
• Nehmen Sie ein bekanntes Konto und bekannte Daten. Ein Smoke Test, der davon abhängt, was gerade in der Datenbank steht, schlägt aus Gründen fehl, die nichts mit dem Build zu tun haben.
• Prüfen Sie Existenz, nicht Korrektheit. “Die Rechnungssumme ist 45,00” gehört woanders hin. “Eine Rechnungsseite wurde gerendert” gehört hierher.
• Halten Sie ihn unter fünf Minuten. Sobald er mehr kostet, verschiebt ihn jemand aus dem kritischen Pfad, und dann sichert er nichts mehr ab.
• Scheitern Sie laut. Eine rote Pipeline, von der niemand erfährt, ist eine grüne Pipeline mit zusätzlichen Schritten.

Wenn er fehlschlägt

Ein fehlgeschlagener Smoke Test ist kein Fehlerbericht. Er ist das Signal, dass einer gebraucht wird, und die beiden sind leicht zu verwechseln: “Smoke Test 3 fehlgeschlagen” sagt der Person, die ihn aufnimmt, nichts darüber, was passiert ist.

Was sie braucht, ist dasselbe, was jeder Defekt braucht - was erwartet wurde, was stattdessen geschah, in welcher Umgebung, mit allem, was der Browser oder der Runner in dem Moment aufgezeichnet hat. Unser Leitfaden zum Schreiben eines Fehlerberichts, der behoben wird ist die lange Fassung, und seine Vorlage ist eine Datei, die Sie an die Triage weitergeben können.

Bei einem Fehler, auf den jemand von Hand stößt, statt eines, den die Pipeline gefangen hat, ist der Kontext der Teil, der meistens fehlt.

Die kurze Fassung

Ein Smoke Test beantwortet eine Frage: ist dieser Build die Zeit von irgendjemandem wert? Fünf Prüfungen, zuerst ausgeführt, immer ausgeführt, und ein Fehlschlag hält das Band an, statt den Tracker zu füllen. Alles andere, was Sie über den Build wissen wollen, ist eine Frage, die sich erst zu stellen lohnt, wenn diese eine mit Ja beantwortet ist.