Specification by Example ist eine Methode, Anforderungen in zwei Richtungen zu präzisieren. Zum einen in Richtung der Kommunikation zwischen Stakeholdern (oder Kunden) und Entwicklern und zum anderen in Richtung Testung. In diesem Blogbeitrag beschäftigen wir uns etwas näher mit den Vor- und Nachteilen dieser Methode und dem Unterschied zu den sogenannten Job Stories.

Worum geht’s genau?

Bei Specification by Example geht es vor allem darum, Herausforderungen von User Stories zu eliminieren, mit denen viele Teams zu kämpfen haben. Unklare Anforderungen und Missverständnisse. Dafür nutzt man einerseits das klassische User-Story-Format und andererseits eine spezielle Form der Akzeptanzkriterien. Die Methode folgt dabei 5 Grundprinzipien.

  • Scope von Zielen ableiten

  • Kollaboration

  • Konkrete Beispiele

  • Lebende Dokumentation

  • Wiederkehrende Validierung

Ein nicht zu unterschätzender Vorteil von Specification by Example ist es, dass man hierdurch Missverständnisse nahezu vollständig vermeiden kann. Denn wie der Name schon sagt, nutzt man die Methode, um die User Story (was ist das Ziel?) anhand von konkreten Beispielen zu spezifizieren. Diese werden als Akzeptanzkriterien verwendet, die man bestenfalls mit den Stakeholdern gemeinsam formuliert.

Die Beispiele sollten das Verhalten der Anforderung in allen Varianten beschreiben. Dies gelingt besonders gut durch den Einsatz einer festgelegten, immer gleichen Struktur, dem die Akzeptanzkriterien folgen sollten. Hierfür verwendet man das sogenannte Gherkin Schema.

Das Gherkin Schema

Das Grundgerüst einer User Story, die via Specification by Example und nach dem Gherkin Schema geschrieben ist, sieht demnach wie folgt aus:

Als [User] möchte ich [Anforderung], um [Ziel]
Akzeptanzkriterien:

  1. Gegeben [Ausgangszustand], wenn [Aktion], dann [Ergebnis]
  2. Gegeben [Ausgangszustand], wenn [Aktion], dann [Ergebnis]
  3. Gegeben [Ausgangszustand], wenn [Aktion], dann [Ergebnis]

Im ersten Moment wirkt dieser Aufbau sehr gestelzt. Nichtsdestotrotz hilft er, denn er bringt Euch und Eure Stakeholder in einen Rhythmus, der zum Beispiel auch durch Daily Standups entstehen soll. (Ihr erinnert Euch sicherlich: immer die selbe Zeit und der selbe Ort.)

Eure Tester werden Euch danken

Die in diesem Format geschriebenen Akzeptanzkriterien bringen Euren Testern einen großen Vorteil. Denn sie dienen als Vorlage, um gute automatisierte Tests zu schreiben, die nicht jedes Mal komplett umgeschrieben werden müssen, wenn sich etwas an der Funktionalität ändert.

Desweiteren könnt ihr dieses Format nutzen, um einen „Test first“ Ansatz zu verfolgen. Hiernach werden den Akzeptanzkriterien folgend erst automatisierte Tests geschrieben und dann der Code entwickelt. Dies ermöglicht einen sehr hohen Qualitätsstandard.

Job Stories oder Specification by Example?

Die Antwort auf diese Frage lautet: Was für Euch besser passt!

Job Stories ermöglichen eine sehr hohe Kundenzentrierung und richten den Fokus auf deren Jobs to Be Done. Wenn ihr den Eindruck habt, dass Euer Team sich zu weit weg vom Kunden befindet, empfehlen wir Euch diese Methode einzusetzen.

Seid Ihr bereits sehr nahe am Kunden und arbeitet mit Methoden wie zum Beispiel einer Value Proposition, dann können auch gemeinsam erstellte User Stories via Specification by Example vollkommen ausreichend sein.