Sanity-Testing: Was es prüft und wann man es einsetzt

Sanity-Testing ist eine schnelle, gezielte Prüfung, ob ein Bugfix oder eine kleine Änderung wie vorgesehen funktioniert und keine benachbarten Funktionen beschädigt hat. Meist probiert ein Tester die betroffene Funktion und einige verbundene Bildschirme von Hand aus, ohne vorher formale Testdokumente zu erstellen. Das Ziel ist eine schnelle Ja-oder-Nein-Antwort, bevor das Update die Nutzer erreicht.

Jeder kleine Fix zwingt ein Softwareteam zur selben Entscheidung: die Korrektur sofort ausliefern oder tagelang auf eine vollständige Testrunde warten. Wer Prüfungen auslässt, riskiert eine Reparatur, die vor den Augen der Kunden scheitert, während ein kompletter Neutest des Produkts nach jeder kleinen Änderung jedes Release ausbremst. Ein kurzer, gezielter Durchlauf bietet Teams einen Mittelweg.

Sanity-Testing wird oft mit Smoke-Testing verwechselt, und ein weit verbreitetes Branchenglossar führte die Begriffe einst sogar als Synonyme. Im Folgenden erfahren Sie, was jeder Durchlauf umfasst, wie sich die Methode zu ähnlichen Techniken verhält und wann eine schnelle Prüfung ausreicht. Wer das Produkt gut kennt, kommt schneller voran, weshalb viele Unternehmen diese Arbeit einem dedizierten QA-Team übertragen.

Was prüft Sanity-Testing eigentlich?

Ein Sanity-Check beginnt, sobald ein Entwickler einen Bug behoben hat. Der korrigierte Code fließt in einen Build ein, eine neue Version der Software, die zum Testen bereitsteht. Danach prüft der Tester drei Bereiche:

• Den Fix selbst: Wer genau die Schritte wiederholt, die den Bug früher ausgelöst haben, sieht, ob das Ergebnis jetzt stimmt.
• Funktionen, die dieselben Daten nutzen: Jeder Bildschirm, der diese Informationen liest, anzeigt oder versendet, wird kurz angesehen.
• Den nächsten Schritt der Nutzer: Wenn Kunden danach meist eine bestimmte Seite aufrufen, folgt der Tester auch diesem Weg.

Alles außerhalb dieser drei Bereiche bleibt bewusst außen vor. Der kleine Umfang erlaubt es einem Team, nach jedem kleinen Fix eine schnelle Prüfung durchzuführen, ohne Releases aufzuhalten.

Sanity-Durchläufe sind außerdem meist nicht skriptbasiert, das heißt, der Tester arbeitet ohne vorbereitete Schrittliste. Die meiste geplante QA-Arbeit folgt schriftlichen Testfällen, also Anleitungen, die jede Aktion und das erwartete Ergebnis auflisten. Stattdessen entscheidet ein erfahrener Tester, der das Update kennt, spontan, was er ausprobiert, und hält den Durchlauf so kurz.

Ein Beispiel für Sanity-Testing: ein Fix, fünf schnelle Prüfungen

Stellen Sie sich eine Buchungs-App für eine Klinikkette vor. Patienten in anderen Zeitzonen meldeten, dass bestätigte Termine um eine Stunde verschoben angezeigt wurden. Ein Entwickler korrigiert den Code, der Ortszeiten umrechnet, und der neue Build kommt in den Test.

Ein Sanity-Durchlauf für diesen Zeit-Fix könnte fünf Prüfungen umfassen:

1. Zeitzone wechseln. Stellen Sie ein Smartphone auf eine andere Region ein, buchen Sie einen Termin und prüfen Sie, ob der Buchungsbildschirm die richtige Uhrzeit anzeigt.
2. Bestätigungs-E-Mail öffnen. Prüfen Sie, ob die E-Mail dieselbe Terminzeit nennt.
3. Termin in einen Kalender eintragen. Kontrollieren Sie, ob der Eintrag zur richtigen Uhrzeit erscheint.
4. Erinnerung auslösen. Stellen Sie sicher, dass die Benachrichtigung der App denselben Termin nennt.
5. Einmal umbuchen. Das Verschieben des Termins durchläuft die korrigierte Umrechnung erneut, sodass eine einzige Änderung zeigt, ob der Fix auch dort hält.

Bestehen alle fünf Prüfungen, kann das Update mit hinreichender Sicherheit ausgeliefert werden. Jeder Fehlschlag schickt den Fix mit dem genauen fehlgeschlagenen Schritt zurück an den Entwickler. Beachten Sie, was der Tester ausgelassen hat: Zahlungen, Patientenprofile, die Suche und jede andere Funktion, die die Änderung nicht berührt hat. Diese Funktionen werden in der regulären Testrunde vor einem größeren Release vollständig geprüft.

Sanity-Testing vs. Smoke-Testing: zwei unterschiedliche Fragen

Smoke-Testing läuft meist als Erstes auf einem neuen Build und klärt, ob die Software überhaupt stabil genug für eine Prüfung ist. Ein Tester, oder ein Skript, das dieselben Schritte automatisch wiederholt, öffnet die App, meldet sich an und klickt sich durch die Hauptfunktionen. Stürzt etwas ab oder lädt ein zentraler Bildschirm nicht, wird der Build abgelehnt, bevor tiefergehende Tests beginnen. Ein Sanity-Check folgt später und stellt eine engere Frage: Funktioniert dieser konkrete Fix?

Das International Software Testing Qualifications Board (ISTQB), das eine weit verbreitete Zertifizierung für Tester anbietet, führte „Sanity Test“ in seinem Glossar von 2023 als Synonym für „Smoke Test“. Die aktuelle Ausgabe definiert Smoke-Testing als Prüfung, ob Software für geplante Tests bereit ist. Sanity-Testing taucht dort gar nicht mehr auf. Im Arbeitsalltag unterscheiden viele QA-Teams die Begriffe jedoch klar.

Wer Smoke- und Sanity-Checks üblicherweise durchführt, wie viel Automatisierung bringt und was einen Durchlauf typischerweise auslöst, lesen Sie in unserem ausführlichen Artikel zu Smoke-Tests vs. Sanity-Tests.

Welche Rolle spielt Sanity-Testing innerhalb von Regressionstests?

Sanity-Testing ist die engste Form des Regressionstests. Eine Regression ist eine Funktion, die früher funktionierte und nach einem späteren Update kaputtgegangen ist. Vollständige Regressionstests prüfen das bestehende Produkt erneut, um solche Fehler zu finden, eine Aufgabe, die auf einer großen Plattform Tage dauern kann. Ein Sanity-Durchlauf sucht dagegen nach demselben Problem in einem viel kleineren Bereich rund um einen einzelnen Fix.

Die Aufteilung des Aufwands nach Größe ähnelt der Testpyramide, einem gängigen Planungsmodell mit vielen schnellen, günstigen Prüfungen an der Basis und wenigen breiten, langsamen an der Spitze. Dieselbe Logik gilt hier: Sanity-Durchläufe laufen nach fast jedem Fix, während ein vollständiger Regressionslauf auf ein Release wartet.

Ein verwandter Begriff, das Retesting, bedeutet, zu bestätigen, dass ein gemeldeter Bug wirklich verschwunden ist. Jeder Sanity-Durchlauf beginnt dort und schaut dann einen Schritt weiter, auf die Funktionen neben dem Fix.

Die folgende Tabelle stellt die drei in diesem Abschnitt behandelten Prüfungen gegenüber, dazu Smoke-Testing als Referenz:

Wann sollten Sie Sanity-Tests durchführen?

Ein Sanity-Check passt zu Situationen, in denen eine Änderung klein ist, das Risiko begrenzt bleibt und eine vollständige Regressionsrunde das Update ohne nennenswerten Nutzen verzögern würde. Typische Beispiele sind:

• Ein Hotfix: Diese dringende Korrektur wird außerhalb des üblichen Zeitplans ausgeliefert, oft während Kunden betroffen sind, daher muss die Prüfung schnell gehen.
• Ein kleiner Fix zwischen Releases: Ein falsches Preisetikett oder ein defekter Button lässt sich sofort bestätigen, ohne alles neu zu testen.
• Eine geänderte Einstellung: Wird eine Konfiguration angepasst, etwa ein Steuersatz oder ein Schalter, der eine Option aktiviert, verändert sich das Verhalten des Produkts ohne neuen Code. Die betroffenen Bildschirme verdienen trotzdem einen Blick.
• Ein Update eines Drittanbieters: Wenn ein Zahlungsanbieter oder Kartendienst die Tools aktualisiert, auf die Ihre App angewiesen ist, bekommt jede verbundene Funktion einen Sanity-Durchlauf.

Manche Bereiche eines Produkts werden immer wieder repariert, etwa der Checkout oder der Login. Für diese Stellen kann Testautomatisierung die häufigsten Sanity-Checks in Skripte verwandeln, die wenige Minuten nach jedem Update laufen. Tester haben dann mehr Zeit für exploratives Testen von Hand.

Wann sich ein Skript für einen Sanity-Check lohnt: Break-even-Formel, Beispielwerte

Wann ein Sanity-Check nicht ausreicht

Sanity-Testing reicht nicht aus, wenn ein Update groß oder riskant ist, denn die Auswirkungen einer großen Änderung können weit über den bearbeiteten Code hinausreichen. So können eine neue Funktion, ein Redesign oder neue Regeln für Zahlungen oder Kontozugriffe Bildschirme beschädigen, die eine enge Prüfung nie aufrufen würde.

Selbst eine kleine Änderung kann riskant sein, wenn sie ein Kernsystem betrifft, wie der Ausfall von Google Cloud im Juni 2025 zeigt. Ein routinemäßiges Datenupdate mit einigen leeren Feldern löste einen Fehler in Code aus, der zwei Wochen zuvor ohne Schutzmechanismen ausgeliefert worden war. Laut Googles Incident-Bericht fielen dadurch mehr als 60 Produkte von Google Cloud und Workspace für etwa 3 Stunden aus. Änderungen an Kernsystemen brauchen eine vollständige Regressionsrunde und einen schrittweisen Rollout, bei dem ein Update zuerst eine kleine Nutzergruppe erreicht und erst dann alle anderen.

Wie führt QAwerk Sanity-Checks zwischen Releases durch?

In Kundenprojekten besteht ein Sanity-Durchlauf bei QAwerk aus vier Teilen:

1. Die Änderung lesen. Wir sehen uns den Bugreport und die Notizen des Entwicklers an, um Problem und Lösung zu verstehen.
2. Auflisten, was der Fix berührt. Anschließend notieren wir jede Funktion und jede Seite, die Daten mit dem korrigierten Code teilt, und stimmen diese Liste mit dem Entwickler ab.
3. Den neuen Build von Hand prüfen. Der Tester wiederholt die ursprünglichen Bug-Schritte und geht dann jeden verbundenen Bildschirm so durch, wie es ein Kunde tun würde.
4. Ein klares Urteil liefern. Ihr Team erhält eine eindeutige Antwort: das Update ausliefern, den Code zur Nachbesserung zurückgeben oder vollständige Regressionstests einplanen, weil die Änderung weiter reichte als erwartet.

Natürlich gleicht kein Projekt dem anderen. Hier sind zwei Beispiele dafür, wie diese Routine bei echten Kunden aussieht:

• Chirurgische Trainingssimulatoren: VirtaMed baut Virtual-Reality-Simulatoren, an denen Chirurgen minimalinvasive Eingriffe mit haptischem Feedback üben, also mit dem in den Instrumenten nachgebildeten Tastsinn. Realistischen Kontakt zwischen simulierten Instrumenten und Organen zu programmieren ist schwierig. Einer unserer Bugreports beschrieb zum Beispiel eine Gallenblase, die direkt durch das umliegende Gewebe glitt. Wenn ein kleiner Fix eintrifft, bestätigen unsere Tester die Reparatur und gehen dann die Hauptfunktionen des Simulators durch. Diese Mischung aus Sanity- und Smoke-Checks passt zu einem Produkt, bei dem eine einzige Änderung an der Physik einen ganzen Eingriff beeinflussen kann.
• Identitätsprüfung auf dem Smartphone: Thirdfort ersetzte separate iOS- und Android-Apps durch eine einzige plattformübergreifende Version, und neue Builds kamen häufig. Zu den kritischen Bugs gehörten Fehler beim Absenden der Angaben zu Source of Funds, einem Schritt, der zeigt, woher das Geld eines Käufers stammt. Außerdem fror die App ein, während der Bildschirm für die erweiterte Identitätsprüfung lud. Jeder Fix wurde erneut getestet, bevor das nächste Update ausgeliefert wurde. Zusätzlich deckten Regressionszyklen die Bearbeitungs- und Zurück-Navigationsabläufe rund um diesen Schritt ab.

Welche Bildschirme nach einer Korrektur zu prüfen sind, lässt sich nur mit Wissen darüber entscheiden, wie ein Produkt zusammenhängt. Unsere dedizierten QA-Ingenieure bleiben über viele Releases bei einem Kunden, sodass die Tester die Verbindungen zwischen den Funktionen bereits kennen. Erweist sich eine Änderung als größer als erwartet, geht dasselbe Team direkt zu vollständigen Regressionstests über, ohne Übergabe und ohne neues Onboarding.

Lassen Sie Ihren nächsten Fix vor dem Release prüfen.

Häufige Fragen

Sehen Sie, wie wir über 1.100 Testfälle für Granola, einen KI-Notizblock, gebaut und gepflegt und 76 % seiner Regressionssuite automatisiert haben

Bitte geben Sie Ihre Geschäfts-E-Mail ein ist keine Geschäfts-E-Mail

Fallstudie Erhalten