Specification by Example – Was ist das?

Eine weitere Projektmanagement-Methode und schon wieder ein englischer Begriff, unter dem man sich vage etwas vorstellen kann, aber bei dem es sicher nicht schadet, nochmal genauer nachzulesen, was das eigentlich ist: Specification by Example. 
Bei dieser Technik geht es darum, Anforderungen in jeweils zwei Richtungen zu detaillieren. Eine der beiden vordefinierten Richtungen ist die Kommunikation mit den Kunden – oder je nach Projekt den verschiedenen Stakeholdern sowie die Kommunikation mit den Entwicklern. Die andere Richtung ist die Testung. Specification by Example wird oft in einem Atemzug mit der Methode der Job Stories genannt. Was also sind die Unterschiede und welche Vorteile hat die Technik der Specification by Example?

Das Grundthema dieser Methode sind die Aufgaben und Herausforderungen, welche durch User Stories zu erkennen sind, um dann in diesem Bereich Missverständnisse und Fehler zu vermeiden. Oft sind Teams ständig damit beschäftigt, Probleme zu beheben, die durch unklare Anforderungen entstehen und die zu Fehleinschätzungen führen. Klassisch ist hier der Einsatz von User Stories.
 
Nutzen Sie Akzeptanzkriterien und folgen Sie den fünf grundlegenden Prinzipien:
 

Der wichtigste Vorteil dieser Methode ist sicherlich, dass sie ein unschätzbares Hilfsmittel ist, um Missverständnisse in einem sehr frühen Stadium fast vollständig auszuschließen. Wenn Sie nach den Vorgaben von Specification by Example vorgehen, exerzieren Sie eine User Story von Anfang bis Ende – und das an einem ganz konkreten Beispiel. Es gibt keine abstrakten Ideen oder Zielformulierungen, die interpretiert werden müssen, sondern nur das Beispiel, anhand dessen das Ziel, welches aus der User Story stammt, verfolgt wird. Durch dieses Beispiel erhalten Sie ein Akzeptanzkriterium, welches Sie dann wiederum mit den Stakeholdern oder Nutzern abstimmen. Missverständnisse werden früh erkannt und Sie sparen enorm Zeit, indem Sie Durchgänge und Entwicklungsprozesse, die nicht zum gewünschten Ziel führen, gar nicht erst beginnen. Durch das Durchspielen anhand von Beispielen wird die Anforderung klarer und auch das Verhalten der jeweiligen Anforderung kann in unterschiedlichen Ausprägungen erkannt und beschrieben werden. Wenn Sie immer nach einer vorher gemeinsam festgelegten Struktur vorgehen, fallen Ihre Akzeptanzkriterien einheitlich aus und sind besonders gut beschreibbar.

Gehen Sie dabei nach dem sogenannten Gherkin Schema vor, dem Gurkenschema. Dieses Schema in Kombination mit Specification by Example beschreibt das Grundgerüst der jeweiligen User Story. Der Nutzer formuliert (mit Ihrer Hilfe) konkrete Akzeptanzkriterien: Auf den Ausgangszustand erfolgt eine Aktion erfolgt und schließlich wird ein Ergebnis erzielt. Das wirkt nun sehr theoretisch, es mag nicht direkt ersichtlich sein, warum dieser Extraschritt nötig ist. Aber wenn alle Akzeptanzkriterien nach diesem Schema aufgelistet werden, entsteht ein Rhythmus, der es Ihnen ermöglicht, enger und fehlerfreier mit den Nutzern zusammenzuarbeiten. Es ist ein Ansatz, der zum Beispiel auch durch die Daily Stand Up Meetings beim Scrum verfolgt wird. Täglich, selbe Zeit, selber Ort, selber Ablauf. Wenn Sie es schaffen, auch Ihre User Stories so zu organisieren, dass durch kontinuierliches und systematisches Durchexerzieren von Beispielen Akzeptanzkriterien entwickelt werden, die von allen angenommen werden, haben Sie einen riesigen Schritt in Richtung Erfolg getan.

Jetzt kommen die Tester ins Spiel: Sie werden mit den auf diese Weise ermittelten und protokollierten Akzeptanzkriterien schneller und besser arbeiten können. Auf der Grundlage der Kriterien können Tests hervorragend automatisiert werden. Das ständige Umschreiben entfällt oder wird auf ein Minimum reduziert, was wiederum in dieser Phase Zeit spart. Zudem ermöglicht diese Vorgehensweise, die Tests schon vor dem Schreiben der Codes zu machen. Das nennt sich ganz einfach Test-first-Ansatz und bedeutet eigentlich nur, dass aufgrund der Akzeptanzkriterien automatisierte Tests geschrieben werden und erst im Anschluss der Code. Die Qualitätsstandards können durch diesen Ansatz erheblich erhöht werden.

Ist also Specification by Example oder doch der Ansatz der Job Stories die bessere Alternative? Hier gehen die Meinungen auseinander und letztendlich ist es eine Frage des Geschmacks und der Vorliebe. Die einen arbeiten gut mit Specification by Example, andere ziehen Job Stories vor. Im Grunde verfolgen beide Methoden dasselbe Ziel und sie sind beide vielversprechend. Die Job Stories haben vielleicht den kleinen Vorteil, dass die Kundenzufriedenheit hier in den Fokus gestellt wird und dass der Schwerpunkt darin liegt, die Jobs to be done zu definieren und abzuarbeiten. Viele Unternehmen setzen die Job Stories immer dann ein, wenn sie das Gefühl haben, dass die Entwicklerteams sich zu weit von den Kunden und deren Wünschen entfernt haben. Letztendlich ist es aber wirklich eine Frage der Gewohnheit, denn ein eingespieltes Team kann mit beiden Methoden zum Erfolg gelangen. Unternehmen, die bereits über die gewünschte Nähe zum Kunden verfügen, wählen oft die Specification by Example und konzentrieren sich auf diese Weise weniger auf die Kundenzusammenarbeit, die ja schon gut funktioniert, sondern legen den Schwerpunkt auf die Verbesserung der Prozesse und auf die Verschlankung der Testung.