Antwort.

Die Automatisierung negativer Szenarien ist ein wesentlicher Bestandteil eines umfassenden Testsystems. Dabei handelt es sich um Prüfungen, bei denen die Widerstandsfähigkeit des Systems gegen fehlerhafte Aktionen, inkorrekte Daten, Ausfälle von Diensten und andere unvorhergesehene Situationen validiert wird.

Hintergrund des Themas:

Früher lag der Schwerpunkt auf positiven Szenarien (happy paths), da diese einfacher zu automatisieren und zu warten sind. Allerdings sind die Anforderungen an die Qualität gestiegen und immer mehr Bugs treten genau an den Grenzen auf, mit fehlerhaften oder offensichtlich inkorrekten Bedingungen. Ihr manuelles Testen veraltet schnell, während die Automatisierung hilft, Abweichungen zu verfolgen.

Probleme:

Bestimmung und Abdeckung aller möglichen negativen Szenarien
Korrekte Überprüfung von Fehlermeldungen und der Gültigkeit des Systemzustands nach dem Fehlschlag der Operation
Pflege der Tests bei Änderungen der Geschäftslogik

Lösungen:

Identifizierung und Systematisierung negativer Szenarien (Boundary Value Analysis, Equivalence Partitioning)
Verwendung von benutzerdefinierten Assertions und Validatoren zur Überprüfung von Fehlermeldungen, HTTP-Codes und Ausnahmen
Automatische "Bereinigung" des Systemzustands nach einem negativen Test

Schlüsselfeatures:

Explizite Formulierung von Tests für Fehler, Ausnahmen, nicht standardisierte Eingabedaten
Überprüfung der Fehlermeldung und des internen Systemzustands
Überwachung der Nebeneffekte: Nach einem negativen Test sollte das System in einem konsistenten Zustand bleiben.

Fangfragen.

Reicht es aus, nur zu überprüfen, welche Fehler bei negativem Testen zurückgegeben werden?

Nein. Es ist wichtig zu überprüfen, dass nach einem Fehler keine Änderung des Systemzustands aufgetreten ist (z.B. kein inkorrekter Datensatz in die DB eingefügt wurde).

Muss man alle möglichen negativen Szenarien automatisieren?

Nein. Es kann unendlich viele geben; man sollte die wahrscheinlichsten und kritischsten (Boundary Value, Null/Empty, falscher Typ, SQL-Injection usw.) hervorheben und die anderen nach Bedarf anpassen.

Kann man die gleiche Verarbeitung für alle negativen Fälle verwenden?

Nein. Verschiedene negative Szenarien erfordern unterschiedliche Prüfungen, Ausnahmebehandlungen und Rollbacks; standardmäßige Assertions sind dafür nicht ausreichend.

Typische Fehler und Anti-Pattern

Ignorieren negativer Szenarien oder deren Abdeckung nur „zum Schein“
Unglaubwürdige Fehlerüberprüfung (z.B. nur Code 500, aber keine Überprüfung des Textes oder der Nebeneffekte)
Unbereinigte Testumgebung nach dem Testausfall

Beispiel aus dem Leben

Negativer Fall

Im System werden nur gültige Registrierungsszenarien getestet. Die Registrierung mit einer leeren E-Mail wird nicht automatisiert überprüft. Daher wird das Problem, dass man einen Benutzer mit einer leeren E-Mail registrieren kann, erst im Live-Betrieb festgestellt.

Vorteile:

Einfache Wartung der Tests
Geringe Anzahl an automatisierten Tests und schneller Durchlauf

Nachteile:

Kritische Bugs gehen in den Live-Betrieb
Erhöhte Kosten für Behebung und Rollback

Positiver Fall

Für jedes negative Szenario (fehlende E-Mail, falsches Format, SQL-Injection) gibt es einen automatisierten Test, der klar die Abwesenheit eines neuen Kontos und den Inhalt der Fehlermeldung überprüft.