·
8 min
Testszenario vs. Testfall: Unterschied, ISTQB-Einordnung und Bankbeispiel
Roman Kirchmeier - Autemos
Ein Testszenario beschreibt einen fachlichen Ablauf, den Sie prüfen wollen, etwa „Dauerauftrag anlegen und freigeben“. Ein Testfall legt für eine Variante dieses Ablaufs Vorbedingungen, Eingaben und erwartete Ergebnisse fest. Ein Szenario bündelt meist mehrere Testfälle. Den Begriff „Testszenario“ führt das offizielle ISTQB-Glossar nicht (geprüft am 27.09.2026). Der Lehrplan für Advanced Test Analysts von 2025 behandelt szenariobasiertes Testen mit Haupt-, Erweiterungs- und Ausnahmeszenarien. Für Banken kommt DORA hinzu: Art. 25(1) nennt szenariobasierte Tests als Beispiel geeigneter Tests im Testprogramm. Wie ein einzelner Testfall aufgebaut ist, zeigt unser Leitfaden zum Testfall nach ISTQB.
Kurz gefasst: Ein Testszenario ist ein fachlicher Ablauf, ein Testfall eine konkrete Prüfung mit Eingaben und erwartetem Ergebnis. „Testszenario“ ist kein Eintrag im ISTQB-Glossar; der CTAL-TA-Lehrplan 4.0 teilt Szenarien in Haupt-, Erweiterungs- und Ausnahmeszenario ein (ISTQB CTAL-TA v4.0, 2025). Automatisieren Sie wenige geschäftskritische Szenarien und viele kleine Testfälle.
Abbildung 1: Testszenario und Testfall auf einen Blick
Was ist der Unterschied zwischen Testszenario und Testfall?
Ein Testszenario beantwortet die Frage „Welchen Ablauf prüfen wir?“, ein Testfall die Frage „Mit welchen Daten und welchem erwarteten Ergebnis prüfen wir eine Variante davon?“. Das Szenario ist die gröbere Einheit und steht nah an der User Story. Der Testfall ist feiner, wiederholbar und endet mit einem eindeutigen Ergebnis: bestanden oder nicht bestanden.
Kriterium | Testszenario | Testfall |
|---|---|---|
Ebene | Fachlicher Ablauf, nah an Story oder Prozess | Konkrete Prüfung einer Variante |
ISTQB-Status | Kein Glossarbegriff; CTAL-TA 4.0 lehrt szenariobasiertes Testen | Glossarbegriff (Version 2) |
Inhalt | Ziel, Akteure, Abfolge von Schritten | Vorbedingungen, Eingaben, Aktionen, erwartete Ergebnisse, Nachbedingungen |
Menge | Wenige pro Feature | Mehrere pro Szenario |
Beispiel | „Dauerauftrag erfassen und durch zweite Person freigeben“ | „Startdatum in der Vergangenheit wird mit Fehlermeldung abgelehnt“ |
Abdeckung | Ausgeführte geteilt durch identifizierte Szenarien | Je nach Technik, etwa Äquivalenzklassen oder Grenzwerte |
Automatisierung | Längerer Ablauf über mehrere Systeme und Rollen | Kurze, gezielte Prüfung, oft auf API- oder Komponentenebene |
Beide Artefakte ergänzen sich. Ein Szenario ohne Testfälle sagt nicht, welche Beträge, Daten oder Rollen geprüft werden. Testfälle ohne Szenario zeigen nicht, ob der Geschäftsprozess als Ganzes funktioniert, etwa ob eine freigegebene Zahlung im Kernbankensystem ankommt.
Was ist ein Testszenario?
Ein Testszenario ist eine Beschreibung eines realistischen Ablaufs durch ein System, die mehrere Testfälle zu einer fachlich zusammenhängenden Geschichte verbindet. Der Begriff stammt aus der Praxis. Im offiziellen ISTQB-Glossar liefert die Suche nach „test scenario“ die Meldung „Term not found“ (ISTQB-Glossar, 2026).
Ältere Fassungen des deutschsprachigen Glossars ordneten das Wort anders ein. Ältere Glossarversionen führten „Testszenario“ als Synonym der Testablaufspezifikation, eines Dokuments mit einer Abfolge von Aktionen zur Testdurchführung (GTB-Glossar 3.21, 2019).
Eine brauchbare Arbeitsdefinition stammt von Cem Kaner. Er beschreibt ein Szenario als hypothetische Geschichte, die einer Person hilft, ein komplexes Problem oder System durchzudenken (Kaner, An Introduction to Scenario Testing, 2003). Ein gutes Szenario hat nach Kaner fünf Eigenschaften:
Es erzählt eine Geschichte mit Akteur, Ziel und Ablauf.
Es motiviert: Ein Stakeholder würde einen Fehler darin ernst nehmen.
Es ist glaubwürdig und könnte im echten Betrieb passieren.
Es ist komplex und verbindet mehrere Funktionen oder Daten.
Es ist leicht auszuwerten.
Im agilen Umfeld taucht das Wort an einer dritten Stelle auf. Der CTFL-Lehrplan nennt für Akzeptanzkriterien ein Format „Szenarioorientiert (z. B. das Gegeben/Wenn/Dann-Format …)“ (ISTQB CTFL Lehrplan 4.0.2, 2025). Ein solches Gherkin-Scenario prüft ein einzelnes Beispiel und liegt damit näher am Testfall. Mehr dazu in den Beiträgen zu testbaren Akzeptanzkriterien und zu Behavior-Driven Development.
Wo stehen Testszenario und Testfall in der ISTQB-Hierarchie?
Die ISTQB-Kette reicht von der Testbasis über Testbedingung, Testfall und Testablauf bis zur Testsuite. Ein Testszenario hat darin keinen eigenen Platz und deckt fachlich die Strecke von der Testbedingung bis zum Testablauf ab. Der Foundation-Lehrplan ordnet die Arbeitsergebnisse drei Tätigkeiten zu: Testanalyse liefert Testbedingungen, Testentwurf liefert Testfälle, Testrealisierung liefert Testabläufe, Testskripte und Testsuiten (ISTQB CTFL v4.0.1, 2024).
Abbildung 2: Wo das Testszenario in der ISTQB-Kette liegt
Testbasis: User Story, Prozessbeschreibung oder regulatorische Vorgabe.
Testbedingung: „Ein testbarer Aspekt einer Komponente oder eines Systems, der getestet werden soll.“ (ISTQB-Glossar, 2026). Akzeptanzkriterien lassen sich laut CTFL §4.5.2 als Testbedingungen betrachten.
Testfall: Vorbedingungen, Eingaben, Aktionen, erwartete Ergebnisse und Nachbedingungen, „welche auf Basis von Testbedingungen entwickelt wurden“ (ISTQB-Glossar, 2026).
Testablauf: „Eine Folge von Testfällen in der Reihenfolge ihrer Durchführung“, mit den nötigen Vor- und Nacharbeiten (GTB-Glossar 3.21; deckt sich mit der aktuellen englischen Definition nach ISO 29119-1).
Testsuite: die Testabläufe und Skripte, die gemeinsam laufen.
Das Szenario tritt in dieser Kette zweimal auf. Beim Entwurf liefert es die Idee, welche Testbedingungen zusammengehören. Bei der Realisierung wird es zum Testablauf, einer festen Reihenfolge von Testfällen mit Vor- und Nacharbeiten. Ein automatisiertes Szenario entspricht in ISTQB-Sprache einem Testskript.
Vorsicht bei Definitionen aus dem Netz. Viele Seiten zitieren für den Testfall die Formulierung „for a particular test objective“. Sie stammt aus einer älteren Version und kursiert über eine inoffizielle Glossar-Kopie. Die aktuelle Version 2 im offiziellen Glossar bindet den Testfall an Testbedingungen.
Wie behandelt der ISTQB-Lehrplan szenariobasiertes Testen?
ISTQB lehrt szenariobasiertes Testen seit 2025 im Advanced-Lehrplan für Test Analysts (CTAL-TA 4.0, veröffentlicht am 02.05.2025), nachdem der Foundation-Lehrplan 4.0 den Anwendungsfalltest gestrichen hat. Der Lehrplan fasst die Technik in einem Satz: „Scenario-based testing evaluates the test item’s behavior in realistic scenarios.“ (ISTQB CTAL-TA v4.0, 2025)
Grundlage ist ein Szenariomodell aus Abfolgen von Aktionen, die Workflows durch das Testobjekt bilden, angelehnt an ISO/IEC/IEEE 29119-4 (2021). Als Modelle nennt der Lehrplan Aktivitätsdiagramme und Use Cases. Innerhalb eines Use Case gibt es drei Szenariotypen:
Hauptszenario („happy path“): der Standardweg zum Ziel.
Erweiterung (alternatives Szenario): eine Abweichung vom Hauptweg.
Ausnahme: eine Abfolge, in der eine unerwartete Aktion, etwa eine ungültige Eingabe, das Ziel des Hauptszenarios verhindert.
Für die Abdeckung gibt der Lehrplan eine einfache Formel vor: ausgeführte Szenarien geteilt durch alle identifizierten Szenarien. Wer vier Szenarien identifiziert und drei ausführt, erreicht 75 Prozent Szenarioabdeckung. Für einfache Schleifen nennt der Lehrplan vier Durchläufe: null Mal, einmal, eine typische Anzahl und das Maximum.
Szenarioabdeckung ist eine Zählgröße aus Ihrem Testmanagement und hat mit Codeabdeckung nichts zu tun. Welche Abdeckungsmetriken es gibt und was jede aussagt, erklärt der Beitrag zur Testabdeckung in der Praxis.
Wie wird aus einem Bankprozess ein Testszenario mit Testfällen?
Ein Bankprozess wird in fünf Schritten testbar: Testbasis lesen, Testbedingungen ableiten, Szenarien benennen, Testfälle ausformulieren und einen automatisierten Ablauf bauen. Das Beispiel ist ein Dauerauftrag im E-Banking für ein Firmenkonto mit Kollektivunterschrift zu zweien.
Abbildung 3: Haupt-, Erweiterungs- und Ausnahmeszenarien im Dauerauftrag-Beispiel
Testbasis: Die User Story lautet „Als Buchhalterin möchte ich einen monatlichen Dauerauftrag erfassen, damit die Büromiete pünktlich bezahlt wird.“ Die Akzeptanzkriterien: Beträge über dem Einzellimit brauchen die Freigabe einer zweiten zeichnungsberechtigten Person, das Startdatum liegt nicht in der Vergangenheit, die IBAN ist gültig.
Testbedingungen: Jedes Akzeptanzkriterium wird zur Testbedingung, dazu kommt „gültiger Auftrag wird gespeichert und ist aktiv“.
Szenarien: Hauptszenario „Erfassen unter dem Limit“. Erweiterung „Erfassen über dem Limit mit Freigabe durch eine zweite Person“. Ausnahmen „ungültiges Startdatum“, „ungültige IBAN“ und „Freigabe abgelehnt“.
Testfälle: Pro Szenario mindestens ein Testfall mit festen Daten, siehe Tabelle.
Automatisierter Ablauf: Das Erweiterungsszenario wird ein automatisierter Test über zwei Benutzersitzungen und eine API-Prüfung.
ID | Szenariotyp | Vorbedingung und Eingabe | Erwartetes Ergebnis |
|---|---|---|---|
TF-01 | Hauptszenario | CHF 1850, monatlich am 1., Start nächsten Monat, gültige IBAN, Einzellimit CHF 5000 | Auftrag gespeichert, Status „aktiv“ |
TF-02 | Erweiterung | CHF 12 000, sonst wie TF-01 | Status „Freigabe ausstehend“, nach Freigabe durch zweite Person „aktiv“ |
TF-03 | Ausnahme | Startdatum gestern, sonst gültig | Fehlermeldung am Datumsfeld, kein Auftrag gespeichert |
TF-04 | Ausnahme | IBAN mit falscher Prüfziffer, sonst gültig | Fehlermeldung am IBAN-Feld, kein Auftrag gespeichert |
TF-05 | Ausnahme | Wie TF-02, zweite Person lehnt ab | Status „abgelehnt“, Erfasserin sieht den Status |
TF-03 und TF-04 prüfen je genau eine ungültige Eingabe. Das folgt dem deutschen Lehrplan 4.0.2: „Ungültige Äquivalenzklassen sollten nicht gemeinsam in einem Testfall getestet werden, um Fehlermaskierung zu vermeiden“ (ISTQB CTFL Lehrplan 4.0.2, 2025). Weitere Muster für solche Prüfungen zeigt der Beitrag zum Negativtest in der Software.
Für die UI-Automatisierung eignet sich vor allem TF-02, der vollständige Freigabeweg. Sitzung A (Erfasserin im Browser) legt den Auftrag an. Eine API-Abfrage prüft den Status „Freigabe ausstehend“. Sitzung B (Freigeber in der Mobile App) gibt frei, und Sitzung A sieht den Status „aktiv“. TF-03 und TF-04 laufen schneller als kurze Tests auf Formular- oder API-Ebene.
Was meint DORA mit szenariobasierten Tests?
DORA verlangt von Finanzunternehmen ein Testprogramm für die digitale operationale Resilienz, und Art. 25(1) nennt szenariobasierte Tests und E2E-Tests als Beispiele geeigneter Tests; die Verordnung gilt seit dem 17. Januar 2025 (Verordnung (EU) 2022/2554, 2022). Art. 25(1) zählt als geeignete Tests unter anderem auf:
Schwachstellenbewertungen und -scans
Quellcodeprüfungen, wo machbar
szenariobasierte Tests
Kompatibilitätstests
Performancetests
E2E-Tests
Penetrationstests
Art. 9(4)(e) ergänzt die Änderungsseite: Änderungen an IKT-Systemen sollen kontrolliert erfasst, getestet, bewertet, genehmigt, umgesetzt und überprüft werden. Ein kleiner Satz stabiler, fachlicher Regressionsszenarien liefert dafür bei jeder Änderung nachvollziehbare Ergebnisse; Autemos protokolliert Teständerungen im Audit-Trail.
„Szenario“ hat in der Bankenaufsicht eine zweite Bedeutung. Bei TIBER-EU, dem Rahmenwerk der EZB für Red-Teaming auf Basis von Threat Intelligence, beschreiben Szenarien Angriffe (EZB, TIBER-EU, 2026). Funktionale Szenarien prüfen, ob ein Geschäftsprozess fachlich korrekt läuft. Angriffsszenarien prüfen, ob sich derselbe Prozess missbrauchen lässt. Beides verlangt andere Teams und Werkzeuge.
Wie viele E2E-Szenarien sollten Sie automatisieren?
Automatisieren Sie über die Oberfläche nur die Szenarien, deren Ausfall geschäftskritisch wäre, und prüfen Sie Varianten als kleinere Testfälle darunter. Jeder lange Ablauf hat mehr Stellen, an denen ein Test ohne Codefehler scheitern kann. Google meldete (Stand 2016), dass rund 1,5 Prozent aller Testläufe ein flaky Ergebnis lieferten und fast 16 Prozent der Tests eine gewisse Flakiness zeigten (Google Testing Blog, 2016).
Abbildung 4: Flaky Tests bei Google, Stand 2016. 84 % der Wechsel von Grün auf Rot betrafen einen flaky Test.
Die dritte Zahl aus derselben Quelle: Rund 84 Prozent der beobachteten Wechsel von bestanden zu fehlgeschlagen betrafen einen flaky Test. Ein roter Lauf sagt dann wenig über den Code. Die erste große empirische Studie zu flaky Tests analysierte 201 Fix-Commits aus 51 Open-Source-Projekten (Luo et al., FSE, 2014).
Als Faustregel schlug Google 2015 eine Verteilung von 70 Prozent Unit-Tests, 20 Prozent Integrationstests und 10 Prozent E2E-Tests vor (Google Testing Blog, 2015). Google nannte die Verteilung als Empfehlung, ohne Messdaten dahinter. Wie Sie lange Abläufe schneiden und pflegen, steht im Leitfaden zum E2E-Test.
Autemos ist eine KI-gestützte Plattform für Testautomatisierung, die funktionale Tests für Web, Mobile, API und Desktop automatisiert. Ein visueller Test-Workflow kann mehrere Browser, Geräte, API-Aufrufe und Benutzersitzungen umfassen. Das passt zur Form eines Bankszenarios mit Erfasserin und Freigeber. Fachleute bauen den Ablauf per Drag and Drop, Testingenieure ergänzen Code-Blöcke oder binden bestehende Playwright-Tests ein. Details zeigt die Seite zu visuellen Test-Workflows.
Ändert sich ein Locator, repariert Autemos ihn per Self-Healing, und jede Heilung ist dokumentiert und lässt sich zurücknehmen. Einmal verwendbare Testdaten markiert Autemos, damit parallele Läufe sie nicht doppelt nutzen. Bei instabilen Testumgebungen hilft eine kleine Zahl gut geschnittener UI-Szenarien: Jedes zusätzliche Szenario ist eine weitere Stelle, an der die Umgebung einen Lauf rot färben kann.
Häufig gestellte Fragen
Ist „Testszenario“ ein ISTQB-Begriff?
Nein, das offizielle ISTQB-Glossar hat keinen Eintrag „test scenario“ (geprüft am 27.09.2026). Am nächsten liegen Testbedingung und Testablauf. Ältere GTB-Glossare wie Version 3.21 von 2019 führten „Testszenario“ als Synonym der Testablaufspezifikation. Szenariobasiertes Testen als Technik steht seit 2025 im CTAL-TA-Lehrplan 4.0.
Wie viele Testfälle gehören zu einem Testszenario?
Eine feste Zahl gibt es nicht; jedes identifizierte Haupt-, Erweiterungs- und Ausnahmeszenario braucht mindestens einen Testfall. Dazu kommen Varianten aus Äquivalenzklassen und Grenzwerten. Im Dauerauftrag-Beispiel ergeben fünf Szenarien fünf Testfälle. Mit Grenzwerten rund um das Einzellimit wären es mehr.
Ist ein Gherkin-Scenario dasselbe wie ein Testszenario?
Meist nicht: Ein Gherkin-Scenario beschreibt ein konkretes Beispiel im Given/When/Then-Format und liegt damit näher am Testfall. Mehrere Gherkin-Scenarios zusammen können ein fachliches Testszenario abdecken.
Was ist Szenarioabdeckung?
Szenarioabdeckung ist die Zahl der ausgeführten Szenarien geteilt durch die Zahl aller identifizierten Szenarien, so definiert im CTAL-TA-Lehrplan 4.0 von 2025. Vier identifizierte und drei ausgeführte Szenarien ergeben 75 Prozent. Die Kennzahl sagt nichts über Code- oder Anforderungsabdeckung aus.
Kann Autemos Testszenarien automatisieren?
Ja, Autemos automatisiert funktionale Szenarien als visuelle Test-Workflows über Web, Mobile, API und Desktop, bei Bedarf über mehrere Benutzersitzungen hinweg. Der AI Recorder erstellt aus einem Jira-Ticket oder einem Testfall im Klartext einen Entwurf, und jeder Schritt braucht die Freigabe Ihres Teams. Last- und Sicherheitstests bietet Autemos nicht.
Fazit
Testszenario und Testfall beschreiben zwei Ebenen derselben Arbeit. Das Szenario sagt, welcher Geschäftsablauf funktionieren muss, der Testfall prüft eine Variante davon mit festen Daten und einem erwarteten Ergebnis. Das ISTQB-Glossar kennt nur den Testfall; szenariobasiertes Testen mit Haupt-, Erweiterungs- und Ausnahmeszenario lehrt seit 2025 der CTAL-TA-Lehrplan 4.0. Für Banken nennt DORA Art. 25(1) szenariobasierte Tests. Halten Sie die Zahl der UI-Szenarien klein, wählen Sie geschäftskritische Abläufe und prüfen Sie Varianten darunter. Dann bleibt ein roter Lauf ein Hinweis auf einen echten Fehler. Wenn Sie sehen möchten, wie ein Freigabe-Szenario über zwei Sitzungen als visueller Workflow aussieht, vereinbaren Sie eine Demo mit dem Autemos-Team.
