Diese vier Begriffe werden oft vermischt. Dadurch entstehen unterschiedliche Erwartungen an den Umfang und Diskussionen über Formulierungen. Ein gemeinsames Begriffsverständnis im Team ist praktisch wichtiger als die Debatte über die richtige Lehrbuchdefinition.
Smoke-Tests
Smoke-Tests klären schnell, ob das System grundsätzlich betriebsfähig und für weitere Tests oder Nutzung geeignet ist. Sie umfassen meist die wichtigsten Erfolgsabläufe: Start, Anmeldung, grundlegende Navigation, Anlegen einer zentralen Entität und Verfügbarkeit der wichtigsten API.
Sanity-Tests
Sanity-Tests sind eng begrenzte, gezielte Prüfungen einer bestimmten Änderung oder Problemstelle. Nach einer kleinen Änderung der Rabattberechnung prüft das Team beispielsweise verwandte Szenarien und angrenzende Bereiche statt des gesamten Produkts.
Regressionstests
Regressionstests prüfen bestehende Funktionalität erneut, um sicherzustellen, dass neue Änderungen das bisherige Verhalten nicht beschädigt haben. Sie sind meist umfassender als Smoke- oder Sanity-Tests und orientieren sich an bekannten Produktrisiken.
Nachtests
Nachtests, auch Bestätigungstests genannt, prüfen einen konkret behobenen Fehler: Ist der Fehler in dem Szenario beseitigt, in dem er gefunden wurde? Sie ersetzen keine Regressionstests, denn sie zeigen nicht, was sonst betroffen sein könnte.
Praktische Unterschiede
- →Smoke: Eignet sich dieser Build für weitere Tests?
- →Sanity: Verhält sich der konkrete Bereich nach einer lokalen Änderung weiterhin wie erwartet?
- →Nachtest: Wurde genau dieser Fehler behoben?
- →Regression: Haben Änderungen andere Funktionalität beeinträchtigt?
Praktische Hinweise
- →Ein gemeinsames Teamvokabular dokumentieren, damit alle den Umfang einheitlich verstehen.
- →Regressionstests an Risiken ausrichten statt an einer willkürlichen Auswahl alter Fälle.
- →Nachtests allein nicht als ausreichenden Release-Nachweis behandeln, wenn die Änderung abhängige Bereiche betrifft.
Nach Zweck auswählen: ein Release mit Rabattkorrektur
Fiktive Anforderung DISC-1: 10% Rabatt anwenden, wenn die Warenzwischensumme mindestens 10000 Cent beträgt. Ein gemeldeter Fehler verwendete > statt >=, sodass ein Warenkorb mit 10000 Cent keinen Rabatt erhielt. Alle folgenden Beträge ergeben ganze Centwerte; andere Beträge benötigen eine ausdrückliche Rundungsregel. Das Release ändert diesen Vergleichsoperator in einer gemeinsam genutzten Funktion zur Gesamtberechnung.
Prüfung Zweck Auslöser Umfang Beispiel
Smoke Ist der Build für weitere Tests nutzbar? Neues Deployment Kleine Auswahl kritischer Funktionen Anwendung öffnet sich, Anmeldung funktioniert, Katalog lädt, Checkout öffnet sich
Sanity (hier vereinbarter Teambegriff) Verhält sich der geänderte Bereich plausibel? Kleine gezielte Korrektur Unmittelbares Umfeld der Änderung Zwischensummen 9900 / 10000 / 10100 ergeben 9900 / 9000 / 9090
Nachtest / Bestätigung Wurde der gemeldete Fehler behoben? Korrektur eines bekannten Fehlers Ursprüngliche Reproduktion und erwartetes Ergebnis Derselbe Warenkorb über 10000 Cent ergibt jetzt 9000
Regression Hat die Änderung bestehendes Verhalten beschädigt? Änderung mit möglichen Auswirkungen Nach Risiko gewählte verwandte und abhängige Funktionen Gespeicherte Bestellungen, Rechnungen und Erstattungsberechnungen entsprechen weiterhin ihren freigegebenen ErwartungenEin Release, vier verschiedene Fragen
Zuerst den Smoke-Test der Umgebung ausführen. Lässt sich der Checkout nicht öffnen, einen Blocker erfassen; ein fehlgeschlagenes Deployment beweist nicht, dass die Vergleichskorrektur falsch ist. Anschließend die ursprüngliche Fehlerkonstellation mit identischem Konto, gleicher Währung und Eingabe im neuen Build wiederholen: 10000 muss 9000 ergeben. Das ist der Bestätigungstest. Danach die benachbarten Werte 9900 und 10100 mit dem gezielten Testsatz prüfen; das Team kann dies Sanity-Test nennen.
Für die Regression vor der Testauswahl die Aufrufer der gemeinsamen Berechnung untersuchen. Gespeicherte Bestellsummen, Rechnungssummen und jeden Erstattungspfad einbeziehen, der die Funktion tatsächlich aufruft. Jeden Wert mit einem vereinbarten gespeicherten Sollwert nach seinen eigenen Regeln abgleichen; nicht annehmen, eine Erstattung betrage automatisch 90% oder jeder Aufrufer verwende DISC-1. Einen zuvor gültigen Warenkorb ohne Rabatt als Kontrolle ergänzen. Der Umfang folgt Nachweisen zu Abhängigkeiten und Geschäftsrisiken, nicht einer festen Anzahl von Tests.
Eine kleine ausführbare Demonstration
Als release_check_selection.py speichern und python3 release_check_selection.py ausführen. Erwartete Ausgabe: Known defect reproduced; confirmation and three focused checks passed. Das Skript demonstriert nur Arithmetik und Auswahllogik: Es führt weder einen Smoke-Test der Anwendung noch die Regressionssuite abhängiger Funktionen aus.
def old_total(cents):
return cents * 9 // 10 if cents > 10000 else cents
def fixed_total(cents):
return cents * 9 // 10 if cents >= 10000 else cents
# Values below produce whole-cent results; no rounding rule is inferred.
assert old_total(10000) == 10000
assert fixed_total(10000) == 9000
for cents, expected in [(9900, 9900), (10000, 9000), (10100, 9090)]:
assert fixed_total(cents) == expected
print("Known defect reproduced; confirmation and three focused checks passed")Die Grenzen der Nachweise festhalten
Ein Fall kann zu mehreren Suiten gehören: Die Prüfung mit 10000 Cent ist sowohl Bestätigungsnachweis für den Fehler als auch ein sinnvoller künftiger Regressionstest. Doppelte Ausführung nicht als zusätzliche Verhaltensabdeckung zählen. Build, Zweck, tatsächliches Ergebnis und nicht abgedecktes Risiko dokumentieren, damit Leser wissen, was „bestanden“ bedeutet.
Sanity bedeutet in verschiedenen Teams Unterschiedliches und wird manchmal synonym zu Smoke verwendet. Den Umfang lokal definieren, statt diese Tabelle als verbindliche Taxonomie zu behandeln. Bestätigung und Regression beantworten unterschiedliche Fragen; die erfolgreiche Wiederholung des ursprünglichen Fehlers beweist nicht, dass das umliegende Verhalten unverändert ist.
Übung: Der genaue Nachtest mit 10000 Cent besteht, aber Rechnungen zeigen weiterhin 10000, nachdem der Checkout 9000 gespeichert hat. Kann das Release als fehlerfrei gelten? Nein. Der ursprüngliche Fehler kann behoben sein, während ein Regressionstest einer abhängigen Funktion scheitert. Beide Ergebnisse erfassen und die Inkonsistenz untersuchen, statt aus dem bestandenen Nachtest ein Release-Urteil abzuleiten.
Weiterlernen
Eine Regressionsstrategie auf Risiken aufbauen
Kurze operative Checklisten pflegen
ISTQB CTFL 4.0.1: Abschnitt 2.2.3, Bestätigungs- und Regressionstests