Testfälle

Wie Testfälle die Qualität verbessern, statt aufwendige Dokumentation mit geringem praktischem Nutzen zu werden.

Aktualisiert:

Inhalt

Ein Testfall beschreibt eine konkrete Prüfung strukturiert. Er soll sie eindeutig, reproduzierbar und für das Team nützlich machen, statt nur etwas zu dokumentieren.

Was ein guter Testfall üblicherweise enthält

  • →Einen klaren Titel, der den Zweck der Prüfung ausdrückt.
  • →Vorbedingungen: der erforderliche Ausgangszustand des Systems.
  • →Testschritte: Aktionen des Testers oder Systems.
  • →Erwartetes Ergebnis: was genau geschehen soll.
  • →Bei Bedarf Testdaten, Priorität, Anforderungslinks und Hinweise.

Was einen guten Testfall ausmacht

  • →Er prüft eine konkrete Regel oder ein Risiko statt alles gleichzeitig.
  • →Sein erwartetes Ergebnis ist messbar und eindeutig.
  • →Er enthält genügend Schritte für Klarheit, ohne unnötige Details.
  • →Bei einem Fehlschlag wird klar, was nicht funktioniert hat.

Häufige Fehler

  • →Überlange Fälle schreiben, die mehrere verschiedene Ideen gleichzeitig abdecken.
  • →Vage erwartete Ergebnisse wie „funktioniert korrekt“ verwenden.
  • →Vorbedingungen und Schritte nicht trennen.
  • →Dutzende fast identischer Fälle duplizieren, obwohl eine Checkliste oder Parametrisierung besser wäre.

Wann ein eigener Testfall unnötig ist

Nicht jede Prüfung braucht einen eigenen Testfall. Bei schnellen Smoke- oder Sanity-Tests, instabilen Funktionen und explorativen Sitzungen kann detaillierte Dokumentation mehr Aufwand verursachen als Nutzen bringen. Gute QA wählt das Format bewusst.

Ausgearbeitete Anmeldefälle mit ausdrücklichen Anforderungen

Diese Fälle verwenden eine fiktive Schulungsspezifikation, keine universellen Anmelderegeln. Das Konto learner@example.test ist aktiv und besitzt ein bekanntes gültiges Passwort. Ein falsches Passwort oder unbekanntes Konto zeigt dieselbe Meldung „Invalid credentials“, ohne eine Sitzung anzulegen. Leere Felder zeigen Feldfehler, ohne eine Anmeldeanfrage zu senden. Das dritte falsche Passwort in Folge sperrt ein bekanntes Konto für 5 Minuten; eine erfolgreiche Anmeldung setzt den Zähler zurück. Ein gesperrtes Konto kann sich auch mit korrektem Passwort nicht anmelden.

Jeden Fall unabhängig ausführen. Vor Beginn den angegebenen Fehlversuchszähler, Sperrzustand und Sitzungszustand wiederherstellen; sonst verändert die Reihenfolge vorheriger Tests das erwartete Ergebnis. Nur synthetische Zugangsdaten verwenden.

plain text
ID	Ausgangszustand	Eingabe / Aktion	Erwartetes Ergebnis
L01	Aktiv, 0 Fehlversuche, abgemeldet	Bekanntes Konto + korrektes Passwort absenden	Sitzung erstellt; Profil öffnet sich; Zähler ist 0
L02	Aktiv, 0 Fehlversuche, abgemeldet	Bekanntes Konto + falsches Passwort absenden	Invalid credentials; keine Sitzung; Zähler ist 1
L03	Unbekanntes Konto, abgemeldet	unknown@example.test + beliebiges Passwort absenden	Invalid credentials; keine Sitzung
L04	Abgemeldet	Beide Felder leer absenden	Zwei Feldfehler; keine Anmeldeanfrage
L05	Aktiv, 2 Fehlversuche, abgemeldet	Bekanntes Konto + falsches Passwort absenden	Keine Sitzung; Konto für 5 Minuten gesperrt
L06	Gesperrt, vor Ablauf, abgemeldet	Bekanntes Konto + korrektes Passwort absenden	Keine Sitzung; Sperre bleibt bestehen

Eine Zeile zu einem ausführbaren manuellen Testfall ausarbeiten

plain text
Testfall: L02 — falsches Passwort ablehnen
Vorbedingungen: aktives Konto, Fehlversuchszähler 0, keine Sitzung.
1. Die Anmeldeseite öffnen.
2. learner@example.test und ein absichtlich falsches Passwort eingeben.
3. Einmal absenden.
Erwartete UI: „Invalid credentials“; das Profil öffnet sich nicht.
Erwarteter Zustand: keine Sitzung; der Fehlversuchszähler des bekannten Kontos steigt auf 1.
Nachweise: Antwort ohne sensible Daten und die in der Testumgebung verfügbare Zustandsbeobachtung.

Der Zähler benötigt einen vereinbarten Beobachtungsmechanismus, etwa eine ausschließlich für Tests verfügbare Verwaltungsansicht oder eine autorisierte Test-Fixture. Ist er nicht verfügbar, die Prüfung als unbestätigt kennzeichnen, statt den Zustand aus einer Meldung abzuleiten. Fälle für Wiederherstellung, Sperrablauf, Nebenläufigkeit und Barrierefreiheit anhand tatsächlicher Produktrisiken ergänzen; die sechs Zeilen sind ein Ausgangssatz, keine vollständige Authentifizierungsprüfung.

Weiterlernen

Fehlerberichte

Grenzwertanalyse

Authentifizierung und Autorisierung

Methodenreferenz: ISTQB-CTFL-Lehrplan, Abschnitte 4.2 und 5.5. Die obigen Beispiele sind eigenständige Schulungsszenarien.