Fehlerszenario-Generator

Das Problem

Entwickler testen, was passieren soll, aber selten, was nicht passieren soll. Ein Login-Formular wird mit korrekten Zugangsdaten getestet, aber nicht mit SQL-Injection, leeren Passwoertern oder 10.000-Zeichen-Benutzernamen. Fehlerszenarien sind der Ort, an dem sich reale Bugs verstecken, und KI ist hervorragend darin, sie systematisch zu generieren.

Der Prompt

Generiere umfassende Fehler- und Ausfallszenarien fuer das folgende Feature. An alles denken, was schiefgehen kann — von Benutzerfehlern bis zu Infrastrukturausfaellen.

FEATURE:
[Feature beschreiben — z.B. "Checkout-Flow", "Datei-Upload", "Benutzer-Login"]

Fehlerszenarien fuer jede Kategorie generieren:

1. **Benutzereingabefehler** — ungueltige Formate, fehlende Pflichtfelder, zu lange/kurze Werte, Sonderzeichen
2. **Netzwerkausfaelle** — Timeout, Verbindung verweigert, DNS-Fehler, langsame Antwort
3. **Serverfehler** — 500, 502, 503, fehlerhaftes JSON
4. **Authentifizierungsfehler** — abgelaufene Sitzung, entzogene Rechte
5. **Datenzustandsfehler** — referenzierter Datensatz geloescht, parallele Aenderung, veralteter Cache
6. **Ressourcenlimits** — Datei zu gross, Speicher voll, Rate Limit ueberschritten
7. **Geschaeftslogik-Fehler** — ungenuegender Kontostand, abgelaufenes Angebot, nicht vorraetig

Fuer jedes Szenario: Beschreibung, Simulation im Test, erwartetes Anwendungsverhalten, Teststub.

Beispielausgabe

// Netzwerk: API-Timeout beim Checkout
it('soll Retry-Button zeigen bei Zahlungs-API-Timeout', async () => {
  server.use(rest.post('/api/payment', (req, res, ctx) => {
    return res(ctx.delay(30000));
  }));
  await userEvent.click(screen.getByText('Jetzt bezahlen'));
  await waitFor(() => {
    expect(screen.getByText('Zahlung fehlgeschlagen. Bitte erneut versuchen.')).toBeVisible();
  });
});

Wann verwenden

Beim Entwerfen neuer Features, um Fehlerbehandlung von Anfang an einzubauen, bei Sicherheitsreviews oder beim Testschreiben fuer Legacy-Code ohne Fehlerbehandlung.

Profi-Tipps

• Die Benutzernachricht testen, nicht den Fehlercode — Benutzer sehen die Fehlermeldung, nicht den HTTP-Status.
• MSW (Mock Service Worker) verwenden — Netzwerkfehler simulieren, ohne Produktionscode zu aendern.
• Mit Chaos Engineering kombinieren — die generierten Szenarien als Checkliste fuer Chaos-Experimente verwenden.
• Nach Nutzerauswirkung priorisieren — ein Timeout auf der Zahlungsseite ist kritisch, auf der Einstellungsseite nebensaechlich.