Ein Testfall ist nur so gut wie seine Beschreibung. Steht dort „Login prüfen“, testet jede Person etwas anderes, und ein Fehler lässt sich später kaum nachvollziehen. Gut geschriebene Testfälle dagegen sind eindeutig, wiederholbar und lassen sich bei Bedarf automatisieren. Dieser Artikel zeigt, wie Sie Testfälle schreiben: welcher Aufbau sich bewährt hat, mit welchen Methoden Sie die richtigen Testfälle finden und worauf es in agilen Teams ankommt.
Ein Testfall beschreibt, unter welchen Voraussetzungen, mit welchen Eingaben und in welchen Schritten ein bestimmtes Verhalten der Software geprüft wird und welches Ergebnis dabei erwartet wird. Der entscheidende Teil ist das erwartete Ergebnis: Erst der Vergleich zwischen Soll und Ist macht aus einer Bedienung der Software einen Test.
Testfälle stehen nicht für sich allein. Welche Bereiche überhaupt und wie gründlich getestet werden, legen Teststrategie und Testkonzept fest. Die Testfälle setzen diese Vorgaben auf der operativen Ebene um.
Ob in Jira, einem Testmanagement-Tool oder einer Tabelle: Ein guter Testfall enthält immer dieselben Bausteine.
Mehr Felder sind möglich, aber selten nötig. Jedes zusätzliche Pflichtfeld kostet bei der Pflege Zeit, und unvollständig gepflegte Felder verwirren mehr, als sie helfen.
Testfälle entstehen aus Anforderungen, User Stories, Prozessbeschreibungen oder Schnittstellenspezifikationen. Unklare oder widersprüchliche Anforderungen fallen beim Schreiben von Testfällen besonders früh auf. Diese Fragen sollten Sie klären, bevor Sie weiterschreiben. Warum das so wichtig ist, beschreibt der Artikel Saubere Anforderungen in IT-Projekten.
Notieren Sie zuerst, was geprüft werden soll, bevor Sie festlegen, wie. Für einen Login sind das etwa: erfolgreiche Anmeldung, falsches Passwort, gesperrtes Konto, Sperre nach mehreren Fehlversuchen, Pflichtfelder leer. Diese Liste zeigt schnell, ob wichtige Fälle fehlen.
Für jede Testbedingung wählen Sie passende Eingabewerte. Dafür gibt es bewährte Verfahren, die im nächsten Abschnitt beschrieben sind. Sie helfen, mit wenigen Testfällen möglichst viele Fehler zu finden.
Schreiben Sie Vorbedingungen, Schritte und erwartete Ergebnisse so, dass eine fachkundige Person ohne Rückfragen testen kann. Eine Aktion pro Schritt, konkrete Werte, keine Interpretationsspielräume.
Lassen Sie Testfälle von einer zweiten Person prüfen, idealerweise aus dem Fachbereich. Ordnen Sie jedem Testfall eine Priorität zu, die sich am Risiko orientiert. So wissen Sie bei knapper Zeit, was zuerst geprüft wird. Das Vorgehen dazu beschreibt der Artikel Risikobasiertes Testen.
Alle denkbaren Kombinationen zu testen ist praktisch nie möglich. Testentwurfsverfahren helfen, systematisch eine kleine, aber aussagekräftige Auswahl zu treffen.
Angenommen, die Anforderung lautet: „Nach drei aufeinanderfolgenden falschen Passworteingaben wird das Konto gesperrt.“ Die Grenze liegt bei drei Fehlversuchen. Sinnvoll sind daher Testfälle für zwei, drei und – als Bestätigung – vier Fehlversuche. Ein Testfall dazu könnte so aussehen:
Der Testfall für zwei Fehlversuche prüft das Gegenstück: Nach dem zweiten Fehlversuch muss die Anmeldung mit korrektem Passwort noch möglich sein.
In Scrum-Teams entstehen Testfälle nicht in einer eigenen Phase, sondern zusammen mit der User Story. Akzeptanzkriterien sind dabei die wichtigste Testbasis. Bewährt hat sich das Format Given-When-Then: „Gegeben ein aktives Konto, wenn dreimal ein falsches Passwort eingegeben wird, dann wird das Konto gesperrt.“ So formulierte Kriterien sind für Fachbereich, Entwicklung und Test gleichermaßen verständlich und lassen sich direkt in automatisierte Tests überführen. Wie das Testen im Sprint insgesamt funktioniert, zeigt der Artikel Agiles Testen in Scrum.
Agil heißt dabei nicht undokumentiert. Testfälle für kritische Abläufe, die vor jedem Release geprüft werden, gehören in eine gepflegte Regressionstest-Suite. Viele davon sind gute Kandidaten für die Testautomatisierung.
Gute Testfälle sind kein Formular, das ausgefüllt wird, sondern das Ergebnis klarer Überlegungen: Was soll geprüft werden, mit welchen Werten, und woran erkennt man Erfolg? Wer Testbedingungen sauber ableitet, Testentwurfsverfahren nutzt und jeden Testfall eindeutig formuliert, findet mit weniger Aufwand mehr Fehler und schafft eine solide Grundlage für Regressionstests und Automatisierung.
Ein guter Testfall hat einen aussagekräftigen Titel, einen Bezug zur Anforderung, klare Vorbedingungen, konkrete Testdaten, kurze nummerierte Schritte und ein präzises, überprüfbares erwartetes Ergebnis. Er prüft genau ein Testziel und ist unabhängig von anderen Testfällen ausführbar.
Ein Testszenario beschreibt grob, was geprüft werden soll, etwa „Kunde bestellt als Gast“. Ein Testfall konkretisiert das mit Vorbedingungen, Testdaten, Schritten und erwartetem Ergebnis. Aus einem Testszenario entstehen meist mehrere Testfälle.
Das hängt vom Risiko und von der Komplexität ab. Jede Anforderung sollte mindestens einen Testfall für den Gutfall haben; Fehleingaben, Grenzwerte und Sonderfälle kommen je nach Bedeutung hinzu. Testentwurfsverfahren wie Äquivalenzklassen und Grenzwertanalyse halten die Zahl dabei überschaubar.
30 Minuten Erstgespräch — kostenlos und unverbindlich. Wir schauen gemeinsam auf Ihre Testfälle und zeigen, wie Sie mit weniger Aufwand mehr Fehler finden.
Jetzt Erstgespräch vereinbarenMehr zu unserer Leistung: Software-Qualitätssicherung und Testmanagement in Hamburg →
Passend dazu: Testmanagement: Aufgaben, Rolle und Vorgehen →