Specification by Example: Wie bekomme ich genaue Anforderungsvorgaben?

Anbieter zum Thema

MicroConsult Academy GmbH

emlix GmbH

Parasoft® Deutschland GmbH

SOFTWARE QUALITY LAB GmbH

Specification by Example: Ein konkretes Beispiel

Bild 2: Akzeptanzkriterien werden als konkrete Beispiele nach dem Gherkin-Schema („Gegeben … wenn … dann“) spezifiziert.
(Bild: Software Quality Lab GmbH)

Ziel: Bauen eines Smart Home, das einer kleinen Familie das Leben erleichtert.

User Story: Als arbeitender Papa möchte ich rechtzeitig geweckt werden, damit ich pünktlich in der Arbeit bin.

Akzeptanzkriterien in Form von Beispielen:

„Szenario ‚normaler Arbeitstag‘: Gegeben es gibt keine Verkehrsbehinderungen, wenn ich ‚Arbeitstag‘ aktiviere, dann ist die Weckzeit 8:15“

„Szenario ‚Stau‘: Gegeben ich brauche normalerweise 30 Minuten zur Arbeit und ich habe um 9 Uhr das Daily Scrum Meeting und es gibt 20 Minuten Stau, wenn ich ‚gemütlich Frühstücken‘ aktiviere, dann ist die eingestellte Weckzeit 6:10.“

„Szenario ‚Party am Vorabend‘: Gegeben ich brauche 30 Minuten zur Arbeit und ich habe um 9 Uhr das Daily Scrum Meeting und es gibt keine Verkehrsbehinderungen, wenn ich ‚lange schlafen‘ aktiviere, dann ist die eingestellte Weckzeit 8:15.“

Die konkreten Beispiele in den Akzeptanzkriterien sollen das Verhalten des Systems in allen Varianten beschreiben. Man spricht deshalb oft auch von „Behaviour Driven Development“.

Best-Practice-Erfahrungen für Specification by Example

Beim Schreiben von User Stories und Akzeptanzkriterien nach diesem Ansatz haben sich einige Best Practices herauskristallisiert:

Halte die Szenarien kurz.

Teile ein komplexes Szenario in mehrere einfache auf.

Beschriebe Szenarien aus Sicht des Anwenders.

Halte alle Szenarien auf der gleichen Abstraktionsebene.

Verwende Keine technischen Begriffe (u.a. UI, REST).

Verwende Begriffe aus der Fachdomäne.

Verwende konkrete Zahlen, Daten, Fakten. (also statt „Wert eingeben“ die konkrete Zahl, z.B. „5.212,65 eingeben“)

Tools als hilfreiche Unterstützung

Durch die Verwendung einer standardisierten Satzstruktur können User Story und Akzeptanzkriterien als Andockpunkt für automatisierte Tests verwendet werden. Tools wie Cucumber und Fitnesse ermöglichen es, User Stories und Akzeptanzkriterien zu verwalten und sie um Testcode zu ergänzen.

Feature: User authentication
 User Story: In order to protect access to the HMI
 As a system administrator
 I want that all users need to be authorized
 
 Scenario: Autologin after 60 seconds
 Given HMI started with default configuration
 When user waits for 60 seconds at the login screen
 Then Default user should be logged in automatically
 
 [Given("HMI started with default configuration")]
 public void GivenTheStartedHMIWithMachineConfiguration()
 {
     TestBase.loginForm = TestBase.app.Start();
 }
 
 [Then("(.*) user should be logged in automatically")]
 public void ThenLoggedInUser(string user)
 {
     Assert.That(frameFunctions.UserGroup,Is.EqualTo(user));
 }

Bild 3: Es hilft, bereits bei der Anforderungsgrundlage konkrete Werte anhand von Tabellen darzustellen.
(Bild: Software Quality Lab GmbH)

Manche Tools erlauben es auch, die konkreten Werte für die Szenarien in einer Tabelle darzustellen. Das Szenario selbst beinhaltet dann Platzhalter. Dies ist kürzer und übersichtlicher, als würde man für jedes Szenario den vollen Satz nach dem Gherkin-Schema schreiben. Durch das Auslagern der Werte in eine Tabelle geht allerdings auch eine Spur Konkretheit in der Formulierung der Akzeptanzkriterien verloren.

Eine lebende Spezifikation

Sind Anforderungen auf diese Weise mit automatisiert ausführbaren Testfällen verbunden, spricht man von einer „lebenden Spezifikation“. Der gesamte Ablauf der Erstellung einer solchen von der Anforderung bis zum Test besteht aus 6 Schritten:

1. Spezifizieren

2. Test-Schritte implementieren

3. Test ausführen

4. Programmcode schreiben

5. Kontinuierliches Feedback von den Tests einholen

6. Fertig!

Dieses Vorgehen unterstützt also einen „Test-First“ Ansatz, bei dem zuerst ein vollständiges Set an automatisierten Tests geschrieben wird, welche die Anforderung vollständig abdecken. Danach erst wird solange Programmcode geschrieben, bis alle Tests grün sind.

Fazit: Durch konkretisierte Beispiele Fehler von Anfang an unterbinden

Richtig angewandt ermöglicht es Specification by Example, Sonderfälle früher und vollständiger zu beachten und dadurch Fehler zu vermeiden. Durch die Beteiligung von Kunde, PO und Team bei der Erstellung wird ein gemeinsames Verständnis der Anforderungen gefördert. Die Automatisierung der Tests schließlich ermöglicht es, auch bei Änderungen an Anforderungen jederzeit sicher zu sein, dass noch alle Szenarien einwandfrei funktionieren.

Der Autor

Markus Unterauer, Leiter des Beraterteams bei Software Quality Lab.
(Bild: Software Quality Lab GmbH)

* Markus Unterauer hat Wirtschaftsinformatik studiert. In seiner Berufspraxis war er in vielen Bereichen der Softwareentwicklung, wie Architektur, Entwurf, Entwicklung, Testen und Testautomatisierung, tätig. Er lernte dabei sowohl klassische als auch agile Methode intensiv kennen. Seit 2012 arbeitet Markus Unterauer bei Software Quality Lab und leitet dort das Beraterteam. Er ist zertifizierter Scrum Master und hat sich auf die Bereiche Softwareprozesse und Anforderungsmanagement spezialisiert. Markus Unterauer ist als Vortragender in diesen Themenbereichen immer wieder auf Konferenzen tätig.

(ID:45533548)