Neue Tester hören diese beiden Begriffe oft so, als ob sie dasselbe bedeuten würden. Das tun sie nicht. Der Unterschied zwischen einem Testfall und einem Testszenario liegt hauptsächlich im Detaillierungsgrad. Wenn Sie ihn verstehen, können Sie entscheiden, wie viel Sie schreiben müssen, bevor Sie mit dem Testen beginnen.

In diesem Leitfaden werden die einzelnen Funktionen erläutert und anschließend eine einzelne Funktion zum Zurücksetzen des Kennworts beschrieben, von der Anforderung über Szenarios bis hin zu vollständigen Testfällen. Das Feature und seine Regeln sind ein erfundenes Beispiel. Auch die Terminologie unterscheidet sich ein wenig zwischen den Teams und Tools, also einigen Sie sich darauf, was diese Wörter in Ihrem eigenen Team bedeuten.

Die kurze Antwort

Ein Testszenario beschreibt eine zu überprüfende Situation, wie zum Beispiel „Überprüfen Sie, ob ein Benutzer ein vergessenes Passwort zurücksetzen kann“. Es ist normalerweise eine Zeile und überlässt die Details dem Tester.

Ein Testfall beschreibt genau, wie eine Bedingung innerhalb dieser Situation überprüft wird: Vorbedingungen, Schritte, Testdaten und das erwartete Ergebnis. Zwei darauffolgende Tester dürften zum gleichen Urteil kommen.

Denken Sie darüber nach, eine Reise zu planen. Das Szenario ist „Reise von Pune nach Delhi“. Der Testfall ist der vollständige Reiseplan mit Flugnummer, Abflugzeit und den in den einzelnen Etappen zu erledigenden Schritten.

Testfall vs. Testszenario nebeneinander

Was ist ein Testszenario?

Ein Testszenario ist eine kurze Beschreibung einer Aktion, die ein Benutzer ausführen könnte, oder einer Situation, mit der das System umgehen muss. Es konzentriert sich auf das, was von außen wichtig ist, und kommt normalerweise direkt aus einer Anforderung oder User Story.

Szenarien sind wertvoll, weil sie schnell sind. In der Zeit, die zum Schreiben von drei detaillierten Fällen benötigt wird, können Sie dreißig auflisten, was sie zu einer großartigen Möglichkeit macht, die Abdeckung mit einem Produktbesitzer zu besprechen: „Haben wir an alles gedacht?“ Ein technisch nicht versierter Leser kann einer Liste von Szenarien problemlos folgen.

Was ist ein Testfall?

Ein Testfall besteht aus einer Reihe spezifischer Bedingungen und Schritte, mit denen festgestellt wird, ob etwas funktioniert. Ein typischer Testfall enthält:

• Eine eindeutige ID und ein eindeutiger Titel
• Vorbedingungen, d. h. was wahr sein muss, bevor Sie beginnen
• Nummerierte Schritte
• Spezifische Testdaten
• Ein erwartetes Ergebnis
• Das tatsächliche Ergebnis und der Status, die bei der Ausführung ausgefüllt werden

Testfälle glänzen, wenn es auf Konsistenz ankommt. Ein neues Teammitglied kann sie ausführen, die Ergebnisse können über mehrere Releases hinweg verglichen werden und Sie haben eine Aufzeichnung dessen, was überprüft wurde. In unserem Leitfaden erfahren Sie ausführlicher, wie man Testfälle schreibt.

Eine Funktion, vom Anfang bis zum Ende

Schritt 1: Die Anforderung

Benutzer, die ihr Passwort vergessen haben, können per E-Mail einen Link zum Zurücksetzen anfordern. Der Link funktioniert einmal und läuft nach 30 Minuten ab. Ein neues Passwort muss mindestens 8 Zeichen lang sein.

Schritt 2: Die Testszenarien

Schauen Sie sich TS-02 an. Die Anforderung besagt nie, was mit einer unbekannten E-Mail passieren soll, und das Schreiben des Szenarios hat diese Lücke offengelegt. Sollte auf der Seite stehen, dass die Adresse nicht registriert ist? Aus Sicherheitsgründen sollte dies normalerweise nicht der Fall sein, da Angreifer dadurch die Möglichkeit haben, gültige Konten zu entdecken. Das frühzeitige Erkennen dieser Fragen ist einer der größten Vorteile beim Schreiben von Szenarien.

Schritt 3: Die Testfälle

Jetzt erweitern wir nur TS-05 in Testfälle. Aus einem Szenario werden mehrere:

Diese Werte waren nicht zufällig. TC-051 und TC-052 liegen auf beiden Seiten des Grenzwerts und verwenden Randwertanalyse, während die anderen aus der Äquivalenzpartitionierung stammen.

Eine Testfallvorlage

Hier ist TC-052 vollständig ausgeschrieben. Kopieren Sie dieses Layout, wenn Ihr Team noch keinen Standard hat:

ID:            TC-052
Title:         Reset rejects a password of 7 characters
Scenario:      TS-05 New password rules are enforced
Priority:      High
Preconditions: Account asha@example.com exists
               A valid, unused reset link has been requested
Test data:     New password: abcd123

Steps:
  1. Open the reset link from the email
  2. Enter abcd123 in New password
  3. Enter abcd123 in Confirm password
  4. Click Reset password

Expected:      Error "Password must be at least 8 characters"
               Password is unchanged, and the link stays valid
Actual:        (filled in during the run)
Status:        (Pass / Fail / Blocked)

Beachten Sie, dass das erwartete Ergebnis mehr prüft als die Fehlermeldung. Außerdem wird bestätigt, dass das alte Passwort noch funktioniert und der Link weiterhin verwendbar ist. Schwache Testfälle bleiben oft bei dem, was auf dem Bildschirm sichtbar ist.

Wo sie in das Gesamtbild passen

Traditionell werden Szenarien und Fälle während der Testentwurfsphase des Softwaretestlebenszyklus geschrieben.

Wann jeweils zu verwenden ist

Szenarien reichen oft aus, wenn:

• Das Team ist klein, erfahren und kennt das Produkt gut.
• Die Zeit ist knapp oder die Anforderungen ändern sich häufig.
• Die Funktion weist ein geringes Risiko auf.
• Sie möchten die Berichterstattung schnell mit den Stakeholdern überprüfen.
• Sie leiten explorative Tests.

Detaillierte Testfälle lohnen sich, wenn:

• Ein Ausfall wäre kostspielig, etwa bei Zahlungen, Sicherheits- oder Gesundheitsdaten.
• Aufsichtsbehörden oder Prüfer benötigen Nachweise darüber, was getestet wurde.
• Neue oder ausgelagerte Tester müssen die Tests durchführen.
• Die Ergebnisse müssen exakt wiederholt werden, wie in einer Regressionssuite.
• Die Schritte werden zu automatisierten Tests.

Die meisten erfahrenen Teams verwenden beides. Sie listen Szenarien für alles auf und schreiben vollständige Fälle nur für die höchsten Risiken. Es ist nicht erforderlich, jeden Schritt einer Einstellungsseite mit geringem Risiko wie bei einer Banküberweisung zu dokumentieren.

Szenarien, Fälle und Automatisierung

Ein gut geschriebener Testfall lässt sich fast direkt auf einen automatisierten Test übertragen. Vorbedingungen werden aufgestellt, Schritte werden zu Aktionen und das erwartete Ergebnis wird zu einer Behauptung. Verhaltensgesteuerte Entwicklungsframeworks verwenden sogar das Wort „Szenario“ für ihre ausführbaren Spezifikationen:

Scenario: Reset rejects a short password
  Given I have opened a valid reset link
  When I submit the new password "abcd123"
  Then I see "Password must be at least 8 characters"
  And my password is unchanged

Verwirrenderweise ähnelt das, was BDD ein Szenario nennt, einem Testfall viel näher, da es spezifische Daten und Ergebnisse enthält. Das ist eine gute Erinnerung, sich auf Bedingungen zu einigen. Informationen zur Automatisierung dieser Prüfungen finden Sie in unserem Playwright-Tutorial oder unserem Pytest-Tutorial.

Was sie gut macht

Häufige Fehler

• Nur glückliche Pfade schreiben. Die meisten Fehler liegen in den Fehlerbedingungen, also geben Sie an, was fehlschlagen sollte.
• Unter Verwendung vager erwarteter Ergebnisse. „Es sollte ordnungsgemäß funktionieren“ lässt jeden Tester alles entscheiden.
• Alles vollständig dokumentieren. Tausende Fälle, die niemand behauptet, sind schlimmer als eine nützliche kleine Menge.
• Szenarien überspringen. Wenn man direkt in Fälle einsteigt, kann das dazu führen, dass ganze Bereiche vergessen werden.
• Hüllen veralten lassen. Wenn sich das Produkt ändert, führen alte Hüllen Menschen in die Irre. Überprüfen Sie sie regelmäßig.
• Schritte mit fragilen Details verknüpfen. „Klicken Sie auf die blaue Schaltfläche oben“ bricht bei jeder Neugestaltung ab.

Fazit

Szenarien geben Ihnen Breite und Testfälle geben Ihnen Tiefe. Beginnen Sie mit Szenarien für Ihr nächstes Feature und überprüfen Sie diese mit einem Entwickler und einem Produktbesitzer. Erweitern Sie dann nur die riskanten Fälle zu vollständigen Fällen. Sie werden Lücken früher entdecken und Ihre Schreibzeit dort verbringen, wo es darauf ankommt.

Häufige Fragen

Lerne weiter