Artikel: Dan North: What’s in a Story?
zu finden: http://dannorth.net/whats-in-a-story/

 

Dan North beschreibt ein Schema für User Stories, welches in akzeptanztestgetriebener Entwicklung (BDD, ATDD) zum Einsatz kommt.
Im Folgenden wird der Aspekt der szenarienbasierten Beschreibung von Akzeptanzkriterien betrachtet.

 

Analyse: ☆☆☆☆☆ 

 

Konzeption: ★★★★★ 

Dan North empfiehlt zunächst das folgende Schema für User Stories: [Title, Narrative, Scenarios]

Title (one line describing the story)

Narrative:
As a [role]
I want [feature]
So that [benefit]

Acceptance Criteria: (presented as Scenarios)

Scenario 1: Title
Given [context]
And [some more context]…
When  [event]
Then  [outcome]
And [another outcome]…

Scenario 2: …

Die Titel helfen, Szenarien voneinander zu unterscheiden und geben einen guten Überblick über das VErhalten der Story:

The scenario title should say what’s different
You should be able to line up the scenarios side by side, and describe how they differ using only the title. In our example, we can see that the scenario descriptions say only what’s different between each scenario

Szenarien werden im “Given, When, Then”-Format beschrieben:

The scenario should be described in terms of Givens, Events and Outcomes

Die Vorbedingungen jedes Szenarios sollten minimal, d.h. nur für das beschriebene Verhalten definiert sein. Gleichzeitig müssen aber alle notwendigen Vorbedingungen vorhanden sein:

The givens should define all of, and no more than, the required context
Any additional givens are distracting [...] . Similarly any missing givens are really assumptions. If you can get a different outcome from the givens provided, then there must be something missing.

Das Event (das WHEN)  eines Szenarios beschreibt i.d.R. die eine Funktion, die durch die User Story behandelt wird. Alle Szenarien fokussieren ein Feature und beschreiben somit seine unterschiedlichen Ausprägungen.

The event should describe the feature
The event itself should be very simple, typically only a single call into the production code.

Durch diese frühe Kommunikation des Kunden (repräsentiert durch PO oder Product Manager) mit Entwicklern und Stakeholdern über das Verhalten einer Funktion werden allen Beteiligten die Anforderungen und Erwartungen an die Story transparent, evtl. Lücken werden frühzeitig sichtbar.

Summary
[...] The acceptance criteria are an intrinsic part of the story – in effect they define the scope of its behaviour, and give us a shared definition of “done”. They are also used as the basis for estimation when we come to do our planning.

Most importantly, the stories are the result of conversations between the project stakeholders, business analysts, testers and developers.

Implementierung: ★☆☆☆☆ 


Die Szenarien dienen als Blaupause für Akzeptanztests, sie können direkt in cumumber, jBehave, bhat o.ä. implementiert werden.

Betrieb: ★★☆☆☆ 


Die implementierten Akzeptanztests können später im Betrieb für die Regression automatisiert werden.