Kundenzentrierte Testfälle und -szenarien mit Fit und FitNesse

Wiki-getriebene Akzeptanztests

von Josef Adersberger

Der Kunde weiß, was er will – mit Fit und FitNesse kann er dies nun auch beweisen. Der Artikel führt in die Welt von Fit ein, grenzt den Ansatz zu JUnit ab und gibt einen Überblick über die Kombination von Fit mit einem Wiki, sprich FitNesse.

Wer kennt diesen Ablauf nicht: In einem Workshop mit dem Kunden werden Anforderungen gesammelt; das Team erstellt den (mehr oder minder) perfekten Quellcode, der alle Anforderungen umsetzt, und präsentiert die Lösung stolz dem Kunden, der entgegnet: „Großartiges Ding, aber eigentlich dachten wir …“ Wurzel des Übels ist, dass die natürliche Sprache, mit der Anforderungen formuliert werden, immer Raum für Zweideutigkeiten und versteckte Unschlüssigkeiten lässt, selbst wenn die Formulierungen noch so ausgefuchst sind. Die Diskrepanz zwischen dem, was die einen sagen, die anderen verstehen und die einen meinen, dass die anderen verstanden haben, ist oft sehr groß – dies lässt viele Projekte scheitern. Doch wohin führt der Weg, Anforderungen ein wenig formaler zu dokumentieren?Was für den Entwickler sein „Boxes and Line“-Diagramm ist, das sind für die Vertreter des Fachbereichs ihre vorzüglich in Excel gestalteten Tabellen. Warum sollte man also nicht den Fachbereich die Kriterien, nach denen er die Umsetzung einer Anforderung wirklich akzeptiert (den so genannten Akzeptanztest) in Tabellenform hinterlegen lassen – also seine Sprache sprechen? Als angenehmer Nebeneffekt könnte dabei auch eine Selbstregulierung der Anforderungsflut aufkommen: Der Fordernde hat nun auch Aufwand, eine Anforderung zu definieren, und muss sich stärker mit dem Innenleben einer Anforderung auseinander setzen bzw. damit, wie sinnvoll (bzw. sinnfrei) eine Anforderung ist.

Abb. 9: Architekturübersicht von Fit und FitNesse
Geschrieben von
von Josef Adersberger
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.