Antwort.

Hintergrund der Frage:

Smoke-Testing ("Raucht-Test") entstand als schnelle Methode zur Überprüfung der Funktionsfähigkeit eines Systems nach dem Build. Ziel ist es, sicherzustellen, dass kritische Funktionen funktionieren und die Anwendung im Allgemeinen für weitergehende, tiefere Prüfungen geeignet ist. Im manuellen Testing werden Smoke-Tests in der Regel sofort nach der Bereitstellung einer neuen Version des Produkts durchgeführt.

Problem:

Die Hauptschwierigkeit besteht in der begrenzten Zeit und der Notwendigkeit, wirklich wichtige Überprüfungen auszuwählen. Oft überprüfen Tester entweder zu viel (verschwenden Ressourcen umsonst) oder übersehen kritische Punkte, weshalb im Release "Löcher" zurückbleiben können.

Lösung:

Die richtige Organisation des Smoke-Testings besteht darin, eine streng minimale Menge an Szenarien auszuwählen, die die wichtigsten Benutzerflüsse abdecken. Diese Überprüfungen sollten klar, schnell und reproduzierbar sein. Zum Beispiel:

- Erfolgreicher Login des Benutzers
- Möglichkeit, die Hauptfunktion auszuführen (z. B. einen Kauf tätigen)
- Durchführung der Zahlung und Erhalt einer Bestätigung

Wichtige Merkmale:

Smoke-Tests decken nur lebenswichtige Funktionen ab
Schnelle Ausführung, was bei häufigen Releases kritisch ist
Alle Szenarien werden manuell nach einer vorher genehmigten Checkliste ausgeführt

Trickfragen.

Kann man Smoke-Testing als vollwertigen Ersatz für Regressionstests betrachten?

Nein, Smoke-Tests sind nur auf "funktioniert – funktioniert nicht" für Schlüssel-Features ausgerichtet. Um ernsthafte, aber nicht erkennbare Bugs zu finden, ist immer ein vollständiger Regressionstest erforderlich.

Was tun, wenn mindestens ein Smoke-Test nicht bestanden wurde? Sollte das Testing fortgesetzt werden?

Nein, weiteres Testing macht keinen Sinn — das Team meldet das Problem, der Release wird blockiert, bis der Bug behoben ist.

Sollten Smoke-Tests Überprüfungen von Edge-Case-Szenarien beinhalten?

Nein, Smoke-Tests sind nicht dafür gedacht, Randfälle zu überprüfen. Sie dienen nur der Bestätigung der Funktionsfähigkeit der Hauptfunktionen des Produkts.

Typische Fehler und Anti-Pattern

Durchführung übermäßiger Tests, die für die Funktionsfähigkeit nicht kritisch sind
Fehlende Dokumentation zu Smoke-Tests (Tester "hält alles im Kopf")
Ignorierung offensichtlicher Probleme zu Gunsten der "Berichterstattung"

Beispiel aus dem Leben

Negativer Fall

Der Smoke-Test wurde anhand einer umfangreichen Checkliste durchgeführt, die unbedeutende Funktionen umfasste. Dafür wurde viel Zeit aufgewendet, weshalb der Release um einen halben Tag verzögert wurde.

Vorteile:

Einige nicht erkennbare Bugs wurden gefunden

Nachteile:

Verzögerung des Releases
Ressourcen und Zeit für unwesentliche Überprüfungen verschwendet

Positiver Fall

Der Smoke-Test konzentrierte sich nur auf die kritischsten Szenarien. Ein blockierender Bug wurde schnell identifiziert und dem Team gemeldet — der Release wurde bis zur Behebung ausgesetzt.