Wie kann man Testfälle für ein Spezifikationsdokument erstellen?

Vom „Klick-Klick-Fertig“-Testfall zum strukturierten Testdesign

Ich gebe’s offen zu: Als ich meine ersten Testfälle geschrieben habe, war das eher simpel gestrickt. Dinge wie „Button klicken → Seite lädt → fertig“ – das war mein Daily Business. Und plötzlich lag da dieses funktionale Design-Spezifikationsdokument (FDS) auf meinem Tisch. Ein richtig dickes Ding. Mehrere Abschnitte, Unterkapitel, Diagramme, UI-Prototypen, sogar ein ganzer Anhang mit Mockups. Ich war erstmal überfordert. Wie soll man daraus bitte strukturierte Testfälle ableiten?

Die Antwort ist: Schritt für Schritt. Und genau diesen Weg möchte ich hier mit dir teilen – wie ich gelernt habe, Testfälle aus einem FDS sinnvoll und systematisch zu entwickeln.

Erstmal tief durchatmen: Was ist das Ziel?

Ein funktionales Design-Spezifikationsdokument beschreibt, was ein System tun soll – nicht wie. Es ist also aus Sicht des Nutzers formuliert. Meine Aufgabe als Tester*in ist es, sicherzustellen, dass das System genau das tut, was dort steht. Nicht mehr und nicht weniger.

Struktur verstehen – bevor es losgeht

Das Dokument war in verschiedene Kapitel gegliedert: Eine Einleitung mit Ziel und Zweck, gefolgt von Bereichen wie 3.1, 3.2 usw., die jeweils eine Funktion beschrieben. Zum Beispiel ging es in 3.2.1 um das Hinzufügen eines Produkts in den Warenkorb, in 3.2.2 um das Entfernen eines Produkts. Und im Anhang fand ich dann Screenshots, Prototypen, sogar UI-Flows.

Mein erster Tipp: Diese Gliederung ist Gold wert. Jede Nummer wie 3.2.1 kann später deine Testfall-Grundlage sein. Also: Nicht einschüchtern lassen, sondern Kapitel für Kapitel durchgehen und dabei schon mal Funktionen identifizieren.

Use Cases isolieren – Was tut das System?

Ich habe mir eine Tabelle gemacht, in der ich zu jedem Abschnitt aufgeschrieben habe:

• Was ist die Funktion?

• Was soll passieren?

• Gibt es Sonderfälle?

• Gibt es Bedingungen?

Beispiel:

• Funktion: Produkt zum Warenkorb hinzufügen

• Was soll passieren?: Klick auf „In den Warenkorb“ fügt das Produkt hinzu

• Sonderfälle: Was, wenn ich zweimal klicke? Was passiert bei ausverkauften Produkten?

Diese einfache Übersicht hat mir geholfen, mich nicht zu verzetteln.

Testfälle schreiben – vom Szenario zur Realität

Dann ging’s ans Eingemachte: Die eigentlichen Testfälle. Ich habe mich dabei an ein simples Schema gehalten:

• Titel des Testfalls

• Voraussetzungen (z. B. „Nutzer ist eingeloggt“)

• Testschritte (z. B. „Produktseite öffnen, Button klicken“)

• Erwartetes Ergebnis (z. B. „Produkt erscheint im Warenkorb“)

Das sah dann zum Beispiel so aus:

Testfall: Produkt zum Warenkorb hinzufügen
Voraussetzung: Der Nutzer befindet sich auf der Produktdetailseite
Schritte:

1. Auf „In den Warenkorb“ klicken
2. Seite aktualisieren
   Erwartung: Produkt wird im Warenkorb angezeigt, die Anzahl steigt um 1

Wichtig ist, sowohl Happy Paths als auch Edge Cases zu prüfen. Was passiert, wenn ich 100-mal auf den Button drücke? Oder wenn ich ausgeloggt bin?

UI-Prototypen nutzen – deine heimlichen Verbündeten

Die Screenshots und UI-Mockups aus dem Anhang waren dabei super hilfreich. Ich konnte genau sehen, welche Elemente wie aussehen sollen, welche Texte erscheinen, welche Buttons existieren. Wenn du also visuelle Unterstützung hast – nutze sie! Es macht die Testfälle greifbarer und realistischer.

---

Alles dokumentieren – Rückverfolgbarkeit ist King

Ein Profi-Tipp, den ich gelernt habe: Erstelle eine sogenannte Traceability-Matrix. Klingt nerdig, ist aber Gold wert. Damit zeigst du genau, welcher Testfall welche Spezifikation abdeckt. Das hilft dir nicht nur beim Überblick, sondern auch später bei Reviews oder Audits.

---

Fazit – Von der Spezifikation zum Testfall in 5 Schritten

• Lies das Dokument vollständig, um ein Gefühl für die Struktur zu bekommen

• Extrahiere die Funktionen und notiere dir Inputs/Outputs

• Schreibe zu jeder Funktion mindestens einen Happy Path und ein paar Edge Cases

• Nutze Prototypen und Diagramme, um realistische Tests zu schreiben

• Dokumentiere sauber – damit du nichts vergisst und dein Testreport glänzt

Quellenverzeichnis

(1) https://kluedo.ub.rptu.de/frontdoor/deliver/index/docId/2316/file/Mesut_Ipek_-_Testfallbeschreibung.pdf

(2) https://de.parasoft.com/blog/how-to-write-test-cases-for-software-examples-tutorial

(3) https://clickup.com/de/blog/234502/wie-man-testfaelle-schreibt

(4) https://de.wikipedia.org/wiki/Klassifikationsbaum-Methode

(5)  https://visuresolutions.com/de/Blog/Was-sind-Testf%C3%A4lle%3F-Wie-schreibt-man-softwarebezogene-Testf%C3%A4lle%3F

(6) https://www.justinmind.com/de/blog/funktionale-spezifikation-dokumentation-schnellanleitung-zum-erstellen-eigener-spezifikationen/