Test cases: Warum nicht mal einfach?

Vor einigen Wochen hatten wir uns an dieser Stelle die Anwendungsfälle („Use Cases“) in der Softwareentwicklung angeschaut. Heute gehen wir den nächsten Schritt.

Keine Angst, es wird einfacher.

Use Cases stellen nämlich die größte Hürde bei der Erstellung von Software und ihrer Dokumentation dar, denn ohne ein Produkt vor Augen zu haben, muss sich der Entwickler (und der ihn begleitende Technikredakteur) in die Rolle eines durchschnittlichen Anwenders versetzen können, dessen „mentales Modell“ erahnen und dann in einem Use Case umsetzen. Auch aus diesem Grund ähnelt es sehr dem Scripten eines Drehbuchs oder eines Theaterstücks: Eine Idee muss in einem Script oder Exposé soweit verfeinert werden, dass der Plot erkennbar ist. Das sind die Anwendungsfälle. Hier ist viel Gesprächsbedarf erforderlich, um die Grundidee des Stücks zu erhalten oder herauszustellen, die Anzahl der Protagonisten (in den Use Cases sind das die „Aktoren“) zu ermitteln und vor allem auch das Zeitbudget und den Finanzierungsbedarf zu ermitteln. Noch ist ja nichts erstellt und es wurde kein Ticket und keine Lizenz verkauft.¹

Steht das Script aber, dann geht es ans Drehbuch. Und je besser die Use Cases ermittelt wurden, desto einfacher ist es, sie in „Test Cases“ umzusetzen.²

Der Testfall

Der Test Case ist eigentlich nur die Aufteilung der Aktoren und ihrer Handlungen in parallele „Handlungsstränge“. Das geht am leichtesten mit einer Tabelle.³

Das obige Beispiel eines einfachen Testfalls ist die Umsetzung des Anwendungsfalls in eine handlungsfähige Vorlage, die einer Benutzeranleitung sehr nahe kommt. Es geht in erster Linie darum, in einer zweidimensionalen Übersicht die jeweiligen Prozesse der Aktoren zu ordnen, damit die Programmentwickler eine klare Vorstellung davon bekommen, welches Ergebnis eine bestimmte Handlung haben soll und in der Testsituation tatsächlich hat.

Wie in einem Drehbuch für eine Szene muss diese meist mehrmals geprobt werden, sprich: der Testfall besitzt deshalb Platz für Testdatum und -zeitpunkt, weil die Testperson mit Hilfe der Vorlage diesen Fall so oft durchspielt, bis er fehlerfrei funktioniert. Stellen sich Abweichungen heraus, muss entweder der Anwendungsfall angepasst werden und in der Folge dann auch der Testfall (das ist die schlechtere Lösung, denn das bedeutete ja, dass man bei den Anwendungsfällen geschlampt hat) – oder aber die Entwicklung hat etwas übersehen.

Was aber ist mit den Optionen?

Wer sich mit Anwendungsfällen beschäftigt, stellt  – nicht nur in der Software – häufiger fest, dass es bei manchen Prozessen mehrere Wege zum Ziel gibt: entweder mit einer anderen Benutzerrolle (mehr Rechte), in einem anderen Umfeld – oder schlicht weil man dem Benutzer Optionen zur Hand geben möchte. Im Anwendungsfall sind dies die „alternativen Pfade“ (alternative paths).

Was macht man damit im Testfall?

Ganz einfach: es ist ein neuer Testfall. Jeder Testfall stellt einen alternativlosen, geradlinigen Weg zum Ziel dar. Optionen müssen in einem eigenen Testfall erfasst werden.

Außer natürlich, man möchte sich das Leben selbst schwerer machen…

1. An dieser Stelle endet normalerweise die Leidensgeschichte der „Vaporware“, die mit viel Idealismus angekündigt, aber nie realisiert werden kann. ↩

2. Wohlgemerkt: es handelt sich nicht darum, die Entwickler in ein Korsett zu zwängen. Der Anwendungsfall und der daraus folgende Testfall müssen daher so allgemein gewählt werden, dass die Entwickler genügend Spielraum erhalten, eleganten Code zu schreiben und eine „saubere“ Benutzerführung umzusetzen. ↩

3. Selbstredend funktioniert diese Vorgehensweise auch außerhalb der Software-Entwicklung – das macht ja gerade ihren Charme aus. Denn ob es um das Drucken eines digitalen Dokuments handelt oder das Wechseln eines Staubsaugerbeutels ist für den Prozess weitgehend egal. ↩