Ein Testfall ist laut aktuellem ISTQB-Glossar eine Menge von Vorbedingungen, Eingaben, Aktionen, erwarteten Ergebnissen und Nachbedingungen, die auf Basis von Testbedingungen entwickelt wird. Er legt fest, wie ein testbarer Aspekt eines Systems geprüft wird und welches Ergebnis am Ende stehen muss.

Viele Seiten zitieren noch eine ältere Fassung, die von einem Testziel spricht; die offizielle Version 2 nennt Testbedingungen als Grundlage. Für die Praxis folgt daraus eine feste Reihenfolge: Erst klären Sie, was getestet wird, dann halten Sie Daten, Schritte und Soll-Ergebnis fest. In Banken kommt der Verweis auf die Anforderung dazu, den Sie im Testmanagement organisieren.

Kurz gefasst: Ein Testfall ist nach ISTQB-Glossar (Version 2) eine Menge von Vorbedingungen, Eingaben, Aktionen, erwarteten Ergebnissen und Nachbedingungen, entwickelt auf Basis von Testbedingungen. Die Testanalyse klärt, was getestet wird, der Testentwurf legt fest, wie. Der CTAL-TA-Lehrplan 4.0 nennt 9 Qualitätskriterien dafür, darunter Präzision, Notwendigkeit und Kürze.

Abbildung 1: Der Testfall in der ISTQB-Kette von der Testbasis bis zur Testsuite

Was ist ein Testfall nach ISTQB?

Ein Testfall ist eine dokumentierte Prüfeinheit im Softwaretest, die Vorbedingungen, Eingaben, Aktionen, erwartete Ergebnisse und Nachbedingungen zusammenfasst und aus einer Testbedingung abgeleitet wird. Das offizielle Glossar formuliert in Version 2: „Eine Menge von Vorbedingungen, Eingaben, Aktionen (falls anwendbar), erwarteten Ergebnissen und Nachbedingungen, welche auf Basis von Testbedingungen entwickelt wurden.“ (ISTQB-Glossar, Testfall, 2026)

Die häufig zitierte ältere Fassung mit dem bestimmten Testziel ist veraltet. Sie kursiert über inoffizielle Spiegelseiten des Glossars und landet von dort in KI-Antworten. Der Unterschied hat praktische Folgen: Ein Testziel wie „Zahlungsverkehr prüfen“ bleibt vage, eine Testbedingung benennt genau einen prüfbaren Aspekt. Für Schulungen und Prüfvorgaben zitieren Sie am besten direkt glossary.istqb.org.

Die Testbedingung definiert das Glossar als „Ein testbarer Aspekt einer Komponente oder eines Systems, der getestet werden soll.“ Synonyme sind Testsituation, Testanforderung und Testidee (ISTQB-Glossar, Testbedingung, 2026). Das erwartete Ergebnis ist das beobachtbare, vorhergesagte Verhalten eines Testelements unter festgelegten Bedingungen, abgeleitet aus der Testbasis (ISTQB-Glossar, expected result, 2026).

Die fünf Bestandteile der Definition haben im Alltag klare Aufgaben:

• Vorbedingungen: der Zustand vor dem Test, etwa ein angemeldeter Testkunde mit bekanntem Kontostand.

• Eingaben: die Testdaten, mit denen das System arbeitet.

• Aktionen: die Schritte. Der Zusatz „falls anwendbar“ zeigt, dass nicht jeder Fall Bedienschritte braucht.

• Erwartete Ergebnisse: was nach der Ausführung beobachtbar sein muss.

• Nachbedingungen: der Zustand danach, etwa Kontostand unverändert und Testkunde abgemeldet.

Wo steht der Testfall in der ISTQB-Kette?

Der Testfall entsteht im Testentwurf. Davor legt die Testanalyse fest, was getestet wird; danach bündelt die Testrealisierung die Entwürfe zu Testabläufen, Testskripten und Testsuiten. Laut CTFL-Lehrplan 4.0.1 identifiziert die Testanalyse testbare Merkmale und definiert priorisierte Testbedingungen; der Testentwurf arbeitet diese Testbedingungen zu Testfällen aus (ISTQB CTFL v4.0.1, 2024).

Ein Testablauf (test procedure) ist nach Glossar eine Folge von Testfällen in Ausführungsreihenfolge, ergänzt um die Aktionen für Vorbereitung und Abschluss (ISTQB-Glossar, test procedure, 2026). Wer diese Ebenen trennt, kann einen Fall in mehreren Abläufen wiederverwenden. Wie Sie Umfang, Teststufen und Verantwortungen vorab festhalten, beschreibt unser Beitrag zum Testplan.

Akzeptanzkriterien sind Testbedingungen

Akzeptanzkriterien einer User-Story liefern die Testbedingungen, aus denen die Tests entstehen. Der deutsche Lehrplan sagt es direkt: „Aus dieser Perspektive können Akzeptanzkriterien als die Testbedingungen betrachtet werden, die durch die Tests ausgeführt werden sollten.“ (ISTQB CTFL-Lehrplan 4.0.2, 2025)

Der Lehrplan nennt zwei Formate: szenarioorientiert im Gegeben/Wenn/Dann-Stil und regelorientiert als Prüfliste oder Tabelle mit Ein- und Ausgaben. Wie Sie Kriterien so schreiben, dass sich daraus eindeutige Tests ableiten lassen, zeigt der Leitfaden Akzeptanzkriterien schreiben.

Was unterscheidet einen logischen von einem konkreten Testfall?

Ein logischer Testfall (High-Level-Testfall) beschreibt, welche Testbedingung unter welchen Umständen geprüft wird, ohne feste Werte; ein konkreter (Low-Level-Testfall) legt exakte Eingaben, Daten und Soll-Werte fest. Der CTAL-TA-Lehrplan 4.0 zeigt das an einer Buchbestellung mit Rabatt: logisch ohne Preise, konkret mit zwei Büchern für $10 und $20 und einem Endpreis von $27 (ISTQB CTAL-TA v4.0, 2025).

Abbildung 2: Logischer und konkreter Testfall am Buchrabatt-Beispiel (CTAL-TA 4.0)

Ein logischer Fall lässt sich laut CTAL-TA in einen oder mehrere konkrete umsetzen, und in der Praxis sind viele Mischformen. Logische Fälle eignen sich für frühe Reviews mit dem Fachbereich, bevor Code existiert. Konkrete Fälle brauchen Sie für die Ausführung, für reproduzierbare Fehlerberichte und für jede Automatisierung.

Das Überweisungsbeispiel ist frei gewählt; Limit und Beträge stammen aus keinem realen Institut. Die Beträge CHF 2.000,00 und CHF 2.000,05 liegen direkt an der Grenze. Solche Werte finden Sie systematisch mit Äquivalenzklassen und Grenzwertanalyse.

Welche Felder gehören in eine Testfall-Vorlage?

Eine praxistaugliche Vorlage enthält neun Felder: ID, Titel mit Ziel, Rückverfolgbarkeit, Priorität, Vorbedingungen, Testdaten, Schritte, erwartetes Ergebnis und Nachbedingungen. Die Norm ISO/IEC/IEEE 29119-3:2021 enthält laut IEEE-Zusammenfassung „templates and examples of test documentation“; die zweite Ausgabe erschien am 28. Oktober 2021 und ersetzt die Fassung von 2013 (IEEE, 29119-3-2021, 2021).

Der Normtext ist kostenpflichtig und hier nicht wiedergegeben. Eine Testfallspezifikation nach 29119-3 enthält typischerweise Kennung, Ziel, Priorität, Rückverfolgbarkeit, Vorbedingungen, Eingaben und erwartete Ergebnisse (ISO/IEC/IEEE 29119-3:2021, 2021). Unumstritten ist die Normreihe nicht: Kontextgetriebene Tester um die Association for Software Testing wandten sich 2014 mit der Petition „Stop 29119“ dagegen (Wikipedia, ISO/IEC 29119, 2014).

Zwei Felder lohnen einen zweiten Blick. Ohne Nachbedingungen bleiben veränderte Testdaten zurück, und der nächste Lauf startet in einem unbekannten Zustand. Ohne Rückverfolgbarkeit kann niemand zeigen, warum der Test existiert und welche Anforderung ungeprüft bleibt, wenn man ihn löscht.

Wie schreiben Sie einen Testfall Schritt für Schritt?

Sie schreiben einen Testfall, indem Sie von einer benannten Testbedingung ausgehen, mit einem Testverfahren konkrete Werte ableiten und dann Vorbedingungen, Schritte und ein eindeutiges erwartetes Ergebnis festhalten. Diese acht Schritte führen von der Testbedingung zum fertigen Entwurf:

Abbildung 3: Acht Schritte von der Testbedingung zum fertigen Testfall

1. Testbedingung benennen. Lesen Sie die Testbasis und schreiben Sie in einem Satz auf, welcher Aspekt geprüft wird, etwa ein einzelnes Akzeptanzkriterium.

2. Testverfahren wählen. Leiten Sie die Werte mit Äquivalenzklassen, Grenzwerten oder Entscheidungstabellen systematisch ab.

3. Logischen Fall schreiben. Titel, Ziel und erwartetes Verhalten ohne feste Werte, kurz mit dem Fachbereich besprochen.

4. Konkrete Werte festlegen. Pro Fall höchstens eine ungültige Äquivalenzklasse.

5. Vorbedingungen und Testdaten beschreiben. So genau, dass eine zweite Person den Ausgangszustand ohne Rückfrage herstellen kann.

6. Schritte schreiben. Eine Aktion pro Schritt, aktiv formuliert, ohne Verzweigungen wie „falls die Maske erscheint“.

7. Erwartetes Ergebnis und Nachbedingungen festhalten. Beobachtbar, mit konkreten Werten.

8. Rückverfolgbarkeit, Priorität und Review ergänzen. Verweis auf Anforderung und Risiko, danach Gegenlesen durch eine zweite Person.

Schritt 4 stützt sich auf eine Regel, die der deutsche Lehrplan 4.0.2 in Abschnitt 4.2.1 ergänzt hat und die in der englischen Fassung 4.0.1 fehlt: „Ungültige Äquivalenzklassen sollten nicht gemeinsam in einem Testfall getestet werden, um Fehlermaskierung zu vermeiden“ (ISTQB CTFL-Lehrplan 4.0.2, 2025).

Ein Beispiel: Enthält ein Fall einen zu hohen Betrag und eine ungültige IBAN, lehnt das System die Zahlung beim ersten Fehler ab. Ob die Limitprüfung funktioniert, bleibt offen. Zwei getrennte Fälle beantworten beide Fragen.

Erst positive, dann negative Tests

Positive Tests prüfen das vorgesehene Verhalten, negative die Reaktion auf ungültige oder nicht vorgesehene Nutzung. Für die akzeptanztestgetriebene Entwicklung (ATDD) legt der Lehrplan die Reihenfolge fest: „Nachdem die positiven Testfälle abgeschlossen sind, sollte das Team Negativtests durchführen.“ (ISTQB CTFL-Lehrplan 4.0.2, 2025)

Akzeptanzkriterien sollen laut Abschnitt 4.5.2 beide Seiten abdecken, positive und negative Szenarien. Welche ungültigen Eingaben sich lohnen und wie Sie diese Fälle automatisieren, zeigt der Beitrag zum Negativtest mit Beispielen aus dem Banking.

Woran erkennen Sie einen guten Testfall?

Ein guter Testfall erfüllt die neun Qualitätskriterien des CTAL-TA-Lehrplans 4.0: Korrektheit, Durchführbarkeit, Notwendigkeit, Verständlichkeit, Rückverfolgbarkeit, Konsistenz, Präzision, Vollständigkeit und Kürze. Der Lehrplan warnt, dass vernachlässigte Qualität zu hohen Wartungskosten, schlechterer Lesbarkeit und Verzögerungen bei der Ausführung führen kann (ISTQB CTAL-TA v4.0, 2025).

Abbildung 4: Die 9 Qualitätskriterien für Testfälle nach CTAL-TA 4.0

Fünf der Kriterien hängen direkt an der Formulierung:

• Präzision: Der Fall lässt nur eine Lesart zu. Der Lehrplan nennt als zu meidende Begriffe „suitable“, „as needed“ und „several“, auf Deutsch etwa „geeignet“, „nach Bedarf“ oder „mehrere“.

• Notwendigkeit: Jeder prüft etwas, das kein anderer prüft. Duplikate sind zu vermeiden.

• Rückverfolgbarkeit: Jeder lässt sich auf Testbedingungen, Anforderungen und Risiken zurückführen.

• Vollständigkeit: Die Attribute nach ISO/IEC/IEEE 29119-3 sind befüllt, inklusive Testdaten und eines klaren erwarteten Ergebnisses.

• Kürze: Kleinere Fälle, die sich auf wenige Überdeckungselemente konzentrieren, sind laut Lehrplan vorzuziehen.

Was zeigt die Forschung über Smells in manuellen Tests?

Hauptmann et al. untersuchten mehr als 2.800 manuelle Tests aus 7 industriellen Testsuiten und beschrieben 7 Smells: fest codierte Werte, lange Testschritte, bedingte Tests, schlecht strukturierte Suiten, Testklone, mehrdeutige Tests und uneinheitliche Wortwahl (Hauptmann et al., ICSE, 2013). Mehrdeutige Tests und Testklone verletzen direkt die CTAL-TA-Kriterien Präzision und Notwendigkeit.

Soares et al. bauten ein Werkzeug, das solche Smells mit 92 % Präzision und 95 % Recall findet, und zählten 13.169 Vorkommen. 80,7 % von 24 befragten Testprofis stimmten dem Smell-Katalog zu (Soares et al., ESEM, 2023). Ein Folge-Preprint fand in 973 natürlichsprachlichen Tests 8.386 Smell-Vorkommen, rund 8,6 pro Test (arXiv-Preprint, 2024).

Für automatisierte GUI-Tests fanden Alégroth et al. bei Siemens und Saab 13 Faktoren, die den Wartungsaufwand beeinflussen, darunter die Komplexität der Tests. Häufige kleine Wartung war dort günstiger als seltene Großreparaturen (Alégroth et al., IST, 2016).

Wie hängen Testfall, Testszenario und Definition of Done zusammen?

Ein Testszenario fasst mehrere Testfälle zu einem Ablauf aus Nutzersicht zusammen; die Definition of Done legt fest, wann ein Increment als fertig gilt, und kann ausgeführte Tests als Bedingung enthalten. Beide Begriffe stammen aus verschiedenen Quellen.

Testszenario: verbreitet, im ISTQB-Glossar nicht definiert

„Testszenario“ hat im offiziellen ISTQB-Glossar keinen Eintrag; eine Abfrage am 27. September 2026 ergab „Term not found“ (ISTQB-Glossar, 2026). Am nächsten liegen Testbedingung und Testablauf. Der CTAL-TA-Lehrplan 4.0 beschreibt szenariobasiertes Testen mit Hauptszenario, Alternativen und Ausnahmen. Die genaue Abgrenzung finden Sie im Vergleich Testszenario oder Testfall.

Definition of Done: Qualitätsstand des Increments

Der Scrum Guide definiert: „Die Definition of Done ist eine formale Beschreibung des Zustands des Increments, wenn es die für das Produkt erforderlichen Qualitätsmaßnahmen erfüllt.“ (Scrum Guide 2020, 2020). Akzeptanzkriterien und eine Definition of Ready kommen im Scrum Guide 2020 nicht vor. Was in eine DoD gehört, erklärt der Einsteigerbeitrag zur Definition of Done.

Warum brauchen Banken Rückverfolgbarkeit?

Rückverfolgbare Testfälle belegen, welche Anforderung mit welchem Test geprüft wurde, mit welchem Ergebnis und mit welchem Fehler. Für Finanzunternehmen in der EU stützt dieser Nachweis die Änderungskontrolle an IKT-Systemen nach DORA. Der CTFL-Lehrplan 4.0.1 beschreibt Rückverfolgbarkeit zwischen Elementen der Testbasis, der zugehörigen Testmittel wie Testbedingungen, Risiken und Testfällen, den Testergebnissen und den Fehlern (ISTQB CTFL v4.0.1, 2024).

Für Finanzunternehmen in der EU gilt seit dem 17. Januar 2025 der Digital Operational Resilience Act (DORA). Artikel 9 Absatz 4 Buchstabe e verlangt Richtlinien für das IKT-Änderungsmanagement: Alle Änderungen an IKT-Systemen sollen kontrolliert erfasst, getestet, bewertet, genehmigt, umgesetzt und überprüft werden (Verordnung (EU) 2022/2554, 2022). Ein Test mit Anforderungs-ID, Version und protokolliertem Ergebnis ist ein Teil dieses Nachweises.

Ein nachvollziehbarer Datensatz zu einem Test enthält:

• den Verweis auf Anforderung, Akzeptanzkriterium und Risiko,

• seine Version und wer ihn wann geändert hat,

• jede Ausführung mit Datum, Umgebung und Ergebnis,

• die Verknüpfung zu gemeldeten Fehlern,

• die Freigabe durch eine berechtigte Person.

Wie Sie diese Verknüpfungen als Tabelle pflegen und bei Prüfungen vorlegen, zeigt der Beitrag zur Traceability-Matrix.

Können KI-Tools Testfälle schreiben?

KI-Tools können Testfälle entwerfen, und laut dem World Quality Report 2025-26 führen Testfallentwurf und Anforderungsverfeinerung die GenAI-Nutzung in der Qualitätssicherung an. Der Bericht ist eine Herstellerumfrage von Capgemini, OpenText und Sogeti unter mehr als 2.000 Führungskräften in 22 Ländern (World Quality Report 2025-26, 2025).

Die Zahlen daraus sind gemischt. 89 % der Befragten pilotieren oder betreiben GenAI-Workflows (37 % in Produktion, 52 % als Pilot), unternehmensweit sind es nur 15 %. Der durchschnittliche Produktivitätsgewinn liegt bei 19 %, ein Drittel meldet kaum Effekte, und 60 % nennen Halluzinationen und Zuverlässigkeit als Hürde (World Quality Report 2025-26, 2025).

Die Qualität eines KI-Entwurfs hängt stark von der Spezifikation ab, aus der er entsteht. In einem Preprint erreichten LLM-generierte logische Fälle für eine Bluetooth-Spezifikation einen Macro-Recall von 0,81, für eine Mozilla-Spezifikation nur 0,37 (Masuda et al., arXiv-Preprint, 2025). Hasan et al. befragten 26 Praktiker; als größte Hürde nannten sie, die Testarbeit mit den fachlichen Anforderungen in Deckung zu bringen (Hasan et al., MSR, 2025).

Autemos, die KI-gestützte Testautomatisierung der selementrix GmbH aus Baar, setzt genau dort an. Der AI Recorder von Autemos entwirft aus einem Jira-Ticket, einer User-Story oder einem Klartext-Testfall einen ausführbaren Test-Workflow. Jeder KI-generierte Schritt muss vom Team freigegeben werden, bevor er läuft. Web-Tests lassen sich als Playwright-Code (Java oder TypeScript) exportieren, mobile Tests als Appium (Java); die exportierten Tests laufen unabhängig von Autemos.

Autemos schreibt keine Akzeptanzkriterien und entscheidet nicht über Ihre Definition of Done; es macht vorhandene Stories, Kriterien und Testfälle mit menschlicher Freigabe ausführbar. Über Jira/Xray synchronisiert es Testfälle und Ausführungen in beide Richtungen, ein Audit-Trail protokolliert Änderungen.

Häufig gestellte Fragen

Was gehört in einen Testfall?

In einen Testfall gehören nach ISTQB-Glossar Vorbedingungen, Eingaben, Aktionen, erwartete Ergebnisse und Nachbedingungen. In der Praxis ergänzen Sie ID, Titel, Priorität und den Verweis auf Anforderung oder Akzeptanzkriterium. Die Norm ISO/IEC/IEEE 29119-3:2021 enthält Vorlagen für solche Spezifikationen.

Was ist der Unterschied zwischen Testfall und Testszenario?

Ein Testfall prüft eine Testbedingung mit festgelegten Daten und einem erwarteten Ergebnis, ein Testszenario beschreibt einen längeren Ablauf, der mehrere davon umfassen kann. „Testszenario“ ist kein Begriff des offiziellen ISTQB-Glossars (Stand 27. September 2026), sondern Branchensprache.

Wie lang sollte ein Testfall sein?

Ein Testfall sollte so kurz sein, dass er wenige Überdeckungselemente prüft; der CTAL-TA-Lehrplan 4.0 (2025) bevorzugt kleinere, fokussierte Fälle. Eine feste Schrittzahl nennt er nicht. Lange Testschritte zählen in der Studie von Hauptmann et al. (2013) zu den 7 Smells manueller Tests.

Gibt es eine offizielle Vorlage für Testfälle?

Die Norm ISO/IEC/IEEE 29119-3:2021 enthält Vorlagen und Beispiele für Testdokumentation, darunter die Testfallspezifikation. Der Normtext ist kostenpflichtig. Der CTAL-TA-Lehrplan verweist für die Vollständigkeit auf deren Attribute; die Vorlage oben zeigt die typischen Felder mit einem Beispiel.

Darf ein negativer Testfall mehrere ungültige Werte kombinieren?

Nein, laut deutschem ISTQB-Lehrplan 4.0.2 (2025) sollten ungültige Äquivalenzklassen nicht gemeinsam in einem Fall getestet werden. Sonst verdeckt der erste Fehler den zweiten: Das System lehnt die Eingabe ab, und Sie wissen nicht, welche Prüfung gegriffen hat.

Fazit

Ein Testfall ist nach dem aktuellen ISTQB-Glossar eine Menge von Vorbedingungen, Eingaben, Aktionen, erwarteten Ergebnissen und Nachbedingungen, entwickelt auf Basis von Testbedingungen. Gute Testfälle entstehen in einer festen Reihenfolge: Testbedingung benennen, Werte per Testverfahren ableiten, logisch entwerfen, konkret ausformulieren, rückverfolgbar ablegen.

Die Vorlage mit neun Feldern und die neun CTAL-TA-Kriterien geben Ihnen einen Maßstab für jedes Review. Negative Fälle kommen nach den positiven und prüfen je eine ungültige Klasse. In Banken gehört zu jedem Test der Verweis auf Anforderung, Ergebnis und Fehler. KI kann Entwürfe liefern; die Freigabe jedes Schritts bleibt beim Team.

Wenn Sie prüfen möchten, wie aus Ihren bestehenden Testfällen und Jira-Stories freigegebene, ausführbare Tests werden, sprechen Sie mit dem Autemos-Team.