Behavior Driven Development ist ein spezielles Kommunikationskonzept für Produkt-Teams. Ich habe in verschiedenen Teams BDD eingeführt. Warum?
- Einfach, modular und übersichtlich: Alle haben ein ausreichend gleiches Verständnis und zwar schnell.
- Konkrete Beispiele anstatt abstrakter Beschreibungen: Probleme im Verhalten des geplanten Features werden viel häufiger VOR der Entwicklung erkannt.
- Nachhaltig und zeitsparend: Akzeptanzkriterien = Testfälle = Systemdoku
Table of Contents
BDD ist eine Kommunikationstechnik. Durch diese spezielle Art der Kommunikation können Teams effektiv über Softwareprodukte austauschen und ein gemeinsames Verständnis vom Verhalten einer Funktion erreichen (Adzic, 2011). Erfahrungsgemäß ist ein Austausch und ein ausreichend gleiches Verständnis im Team und mit Stakeholdern ein wichtiger Teil erfolgreicher Produktentwickelung.
Behavior Driven Development ist meiner Ansicht nach eine der wichtigsten Techniken für Produkt-Teams, die ich kenne. BDD erleichtert das Leben von Produktmanagern, Testerinnen, Entwicklern, Designerinnen und Stakeholdern.
Wozu dient BDD?
- Schnelle und effektive Kommunikation im Team und mit Stakeholdern (gleiches Verständnis)
- Beschreibungen sind schnell und einfach anpassbar durch Modularität
- Fokus auf Verhalten rückt Detail-Diskussionen VOR die Umsetzungsphase, was insgesamt Zeit spart und technische Schulden minimiert
- Einfaches umwandeln in Testfälle
Während der Product Discovery, also lange bevor die erste Zeile Code geschrieben wird, werden Akzeptanzkriterien in Form von sogenannten Szenarien geschrieben. Diese Szenarien sind konkrete Beispiele, die beschreiben, wie sich das Feature in bestimmten Situationen verhält. Deshalb sind sie leicht verständlich und das konkret beschriebene Beispiel ist gut vorstellbar. Wenn wir etwas verstehen wollen, helfen uns oft konkrete Beispiele.
BDD ist nachhaltig: Die Szenarien haben drei Funktionen. Sie dienen als Akzeptanzkriterien, als Vorlage für (automatisierte) Tests und als Systemdokumentation.
Behavior Driven Development in der Produktentwicklung
Diese unterschiedlichen Funktionen von BDD hängen auch davon ab, in welcher Phase der Software Produktentwicklung sich ein Thema gerade befindet: in der Product Discovery oder der Product Delivery. Zur Erinnerung: in der Discovery wird eine Idee entwickelt und getestet und in der Delivery wird die erfolgreich getestete Idee implementiert.
Währen der Discovery: Fokus auf gleiches Verständnis und Kommunikation:
- alle Beteiligten sollen ein gleiches Verständnis vom Verhalten der Software bekommen
- im crossfunktionalen Team kommunizieren die unterschiedlichen Rollen (Entwickler:in, Product Manager, Testerin, Designer) über diese Szenarien miteinander
- die Szenarien werden anhand der Gherkin Syntax formuliert – siehe Die Gherkin Syntax
- die Gherkin Szenarien dienen nach Eintritt in die Delivery (z.B. in der Sprintplanung) als Grundlage für Testautomatisierung und später als Dokumentation
Während der Delivery: Fokus auf Test Driven Development:
- BDD begünstigt die Verwendung von Test Driven Development: Die Szenarien können als Vorlage für erste automatisierte Tests vor/während der Implementierung verwendet werden
- TDD (Test Driven Development) als Entwicklungsstrategie bedeutet, dass (automatisierte) Tests vor dem eigentlichen Programmcode geschrieben werden
- Die Testfälle schlagen also fehl (rot), bis das Programm soweit fertig ist, dass die Testfälle erfolgreich bestanden werden und fehlerfrei durchlaufen (grün)
- Welches eigentliche Testframework verwendet wird, kann flexibel gewählt werden. Für die Verknüpfung der Implementierung der Testautomatisierung mit den Gherkin-Schritten wird ein Adapter-Framework wie Cucumber gebraucht.
Auch für manuell ausgeführte Testfälle können Gherkin-Beschreibungen eine Basis sein. Nach der Entwicklung dient BDD dann als Systemdokumentation.
BDD ist also in erster Linie eine Strategie zur verbesserten Kommunikation und zur Förderung des gleichen Verständnisses während der Discovery. Es handelt sich um ein Kommunikationsframework, welches die konstruktivistische Sichtweise anerkennt. Die sehr vereinfachten und strukturierten Formulierungen adressieren die Ansicht, dass jeder Mensch die Welt auf seine Weise sieht. Wie genau diese Formulierungen aussehen wird im folgenden Abschnitt beschrieben.
BDD ist keine Teststrategie, kein Testframework und kein Tool zur Testautomatisierung – auch wenn es diese Aspekte unterstützt.
Die Szenarien entstehen immer vor dem Programmcode. Falls sie nach dem Code entstehen, handelt es sich lediglich um eine abstrahierte Testfallbeschreibung (nicht einmal test-driven) und hat seine Vorteile weitestgehend verloren. Es kann dann nicht mehr als BDD bezeichnet werden.
Gherkin – Die Sprache des BDD
Bei Gherkin handelt es sich um eine Beschreibungssprache im Rahmen des BDD. Gherkin hat eine sehr einfache Syntax, die lediglich aus einigen wenigen standardisierten Schlüsselwörtern und einer einfachen Struktur besteht. Mit Gherkin können Akzeptanzkriterien sehr einfach und strukturiert beschrieben werden und zwar anhand konkreter Beispiele. Die zentrale Frage ist:
Wie soll sich das System unter welchen Bedingungen verhalten.
Das Ergebnis ist eine Beschreibung, die perfekt zur Kommunikation über das neue Feature während der Discovery verwendet werden kann.
Alle Mitglieder des crossfunktionalen (agilen) Produktteams können die Beschreibung gleich gut verstehen und über die einzelnen Schritte der Beschreibung diskutieren – und sie während des Refinements/Spezifikations-Workshops gemeinsam final formulieren (siehe Three Amigos Sessions – BDD Leben).
Der Inhalt der Szenarien kann beliebig natürlichsprachlich formuliert werden und muss sich lediglich an eine „Given-When-Then“-Struktur halten.
Die Struktur und Organisation der Beschreibungen sind einfach. Die Szenarien werden als natürlichsprachlicher Text in Feature Files abgelegt. Dabei kann es sich um einfache Textdateien handeln oder auch um Elemente in Projekt- oder Testmanagement-Systemen. Beispielsweise kann in einer „Story‘“ in Jira das Beschreibungsfeld als Feature-File verwendet werden. Ein Feature File enthält genau ein Feature. Ein Feature kann mit einer User Story gleichgesetzt werden. Pro Feature gibt es ein oder mehrere Szenarien. Jedes Szenario ist ein konkretes Anwendungsbeispiel des Features. In einem Szenario gibt es eine Reihe von Szenarien-Schritten (analog zu „Steps“ in Testfällen).
Durch die Beschreibung als User Story ist der Kontext und das Ziel beschrieben. Das Szenario bildet dann die zur User Story gehörenden Akzeptanzkriterien und beschreibt das Verhalten unter bestimmten Voraussetzungen durch die einzelnen Schritte.
Die Syntax der Gherkin Beschreibungssprache gibt einige wenige Schlüsselwörter vor:
- Given/ANGENOMMEN: Beschreibt die Vorbedingung
- When/WENN: die Aktion, die ausgeführt wird
- Then/DANN: die erwartete Reaktion des Systems
- And/UND: ergänzt die anderen Schlüsselwörter
- Not/NICHT: ergänzt die anderen Schlüsselwörter
- Or/ODER: ergänzt die anderen Schlüsselwörter; wird nicht überall zu den Schlüsselwörtern dazu gezählt
Die Sprache der Schlüsselwörter kann beliebig gewählt werden. Auch Groß- und Kleinschreibung ist frei wählbar. Oft wird der Einfachheit und Einheitlichkeit halber das jeweils englische Wort verwendet.
Beispiel für ein Feature mit drei Szenarien:
Feature: Kopierfunktion für Dokumente
Als Datenerfasser:in,
möchte ich Dokumente kopieren,
um meine Effizienz zu steigern.
Szenario: Kopieren über Kontextmenü
ANGENOMMEN ich habe eine Datei erstellt
WENN ich über das Kontextmenü das Dokument kopiere
DANN wird eine Kopie der Datei im Ordner erstellt
UND ich kann sie editieren
Szenario: Kopieren über Tastenkombination
ANGENOMMEN ich habe eine Datei erstellt
WENN ich über eine Tastenkombination das Dokument kopiere
DANN wird eine Kopie der Datei im Ordner erstellt
UND ich kann sie editieren
Szenario: Kopierversuch schlägt fehl durch Kopierschutz
ANGENOMMEN ich habe eine Datei erstellt
WENN ich über eine Tastenkombination das Dokument kopiere
UND der Kopierschutz der Datei ist aktiv
DANN erscheint eine Info-Meldung
UND NICHT Kopie der Datei im Ordner erstellt
Was bei der Formulierung wichtig ist:
Bei der Formulierung von Gherkin-Szenarien ist es wichtig, sich auf das erwartete Verhalten zu fokussieren und nicht auf die Beschreibung von Komponenten des User Interface oder Ähnliches. Für diejenigen, die es gewohnt sind, Testfälle zu beschreiben, kann dies ungewohnt sein. Merke für die Formulierung von Gherkin-Szenarien:
Es handelt sich um Beschreibungen des Verhaltens im Sinne von Akzeptanzkriterien, nicht um Testfälle. (Auch wenn diese Beschreibungen später die Basis für Testautomatisierung und auch für manuelle Testfälle sein können/sollten.)
Beispiel:
So kann man es machen:
…
WENN ich das Dokument über das Kontextmenü kopiere
…
Und eher nicht:
…
WENN ich rechts klicke
UND „kopieren“ klicke
…
Der Grund dafür ist, dass die Beschreibungen des Verhaltens langlebiger und weniger „Mikromanagement“ sind, als das untere Beispiel. Wir wollen ja das Verhalten besprechen und nicht die Benennung der Oberflächenkomponenten. Dadurch ist es auch viel weniger oft notwendig, die Szenarien umzuschreiben und zu aktualisieren, beispielsweise wenn es im Kontextmenü nicht mehr „kopieren“ sondern „duplizieren“ heißen soll.
Wenn wir uns den Sinn der Gherkin Szenarien vor Augen halten, wird dies ebenso klar: Wir wollen mit den Stakeholdern das Verhalten besprechen und uns nicht in Diskussionen über Details verlieren. Wir wollen das Team „empowern“ und nicht das WIE schon in den Szenarien vorgeben, sondern nur das WAS näher beschreiben.
Hier den passenden Weg für sich zu finden, erfordert Übung und praktische Anwendung.
Immer aktuelle Systemdokumentation:
Wenn die Gherkin-Beschreibungen als automatisierte Tests verwendet werden, hat dies einen entscheidenden Vorteil: Da die Tests an Veränderungen im Programmcode angepasst werden müssen, damit sie fehlerfrei durchlaufen, ist stets eine aktuelle Systemdokumentation vorhanden.
Cucumber – BDD-Testautomatisierung
Da dieses Dokument keine Anleitung zur Testautomatisierung ist, sondern das Produktmanagement als Thema im Fokus hat, soll die konkrete Umsetzung der Testautomatisierung hier nur ansatzweise beschrieben werden. Cucumber ist ein Framework, dass die Umwandlung von Gherkin-Szenarien in automatisierte Tests unterstützt. Cucumber selbst ist dabei kein Testautomatisierungsframework, sondern eher ein Bindeglied zwischen den natürlichsprachlichen Gherkin-Beschreibungen und der Implementierung der Testautomatisierung.
Die eigentliche Automatisierung der Testschritte erfolgt im gewählten Test-Framewort (z.B. Selenium). Das Cucumber Framework ist in allen gängigen Programmiersprachen umgesetzt und steht so in den entsprechenden Entwicklungsumgebungen zur Verfügung (z.B. Behave für Python oder Cucumber-JVM für Java).
Cucumber findet über einen Cucumber-Runner die Gherkin-Feature-Files und sucht anhand der Szenarien-Schritte die dazugehörigen Implementierungen der Testautomatisierung. Damit dies funktioniert, müssen vorher die Testautomatisierungen mit den Gherkin-Ausdrücken verbunden worden sein.
@Given(„^Ich navigiere zur homepage$“)
public void navigateToHomePage() // hier der Aufruf der Testautomatisierung
Daher sollte die Formulierung die Gherkin-Schritte einheitlich sein z.B. „Ich navigiere zur homepage“ sollte nicht woanders „Ich gehe zur homepage“ genannt werden. Dies ist relevant, wenn die Szenarien als automatisierte Tests verwendet werden.
BDD kontinuierlich im Team leben
Es braucht die Gelegenheiten, BDD im Team zu leben. Dies können z.B. die Refinements sein. Hier kommen die drei wichtigen Perspektiven zusammen: Produkt, Tech und Test. Die Vertreter:innen dieser Perspektiven sollten sich die vorformulierten Szenarien gemeinsam Schritt für Schritt durchlesen und zustimmen oder die Formulierung ändern. Wichtig ist auch, dass die zugehörige User-Story liebevoll formuliert wird mit Fokus auf das WARUM.
Zugegeben: Das gemeinsame Formulieren der ungelenken Sätze kann zunächst gewöhnungsbedürftig sein. Doch der Benefit ist riesig: Unterschiedlich verstandene Anfoderungen, zu ungenaue Formulierungen, fehlende wichtige Spezialfälle und unübersichtliche Anforderungsdokumente gehören der Vergangenheit an.
Diese Art der Zusammenkunft nennt sich auch die 3-Amigos-Session. Der Begriff wurde von Georg Dinwidiee geprägt – nach dem gleichnamigen Film – und erstmals von ihm in einem seiner Blogbeiträge verwendet (Adzic, 2011).
Behavior Driven Development – Praxistipps
Und hier noch einige Praxistipps für Behavior Driven Development:
- Falls Screenshots, Wireframes oder andere Prototypen verfügbar sind, kopiere ich diese gern direkt sichtbar unter das jeweilige Szenario. Dabei sollte im Bild jeweils nur der Teil zu sehen sein, der im Szenario beschrieben wird. Damit bleibt das Ganze übersichtlich.
- Wenn ein Feature File (eine Story in Jira) zu komplex und zu groß wird, können die Szenarien einfach auf unterschiedliche Stories aufgeteilt werden. Gherkin macht Anforderungsbeschreibungen extrem modular.
- Der Start kann zäh sein. Oft gibt es Unmut und das Ganze kommt dem Team irgendwie albern vor. Das ist ok. Fokussiert auf die genannten Vorteile und probiert es einfach aus – z.B. für einen Sprint. Seht es als Experiment. Vielleicht hilft es euch ja.
- Was ist die erste Wahrheit, wenn es ein Design UND Gherkin Szenarien gibt? Fokussiert immer wieder auf Verhalten anstatt Oberflächenelemente. Die Oberfläche ist ja oft im Wireframe/Designvorlagen gut ersichtlich. Vermeidet aber, Designs „abzuprogrammieren“. Das führt erfahrungsgemäß an keinen guten Ort. Auch Designer können nicht im Voraus alles Bedenken.
- Szenarien wollen leben. Sprecht immer wieder darüber, wenn es Unklarheiten gibt, auch während der Entwicklung. Dabei solltet ihr unbedingt darauf achten, neue und zusätzliche Inhalte (Scope Changes) in neue Feature Files und Szenarien zu schreiben – ansonsten droht Scope Creep wie in jedem Projekt. Erweitert den Scope nicht während der Umsetzung.
- Fangt klein an – mit einfachen Features. So könnt ihr erst einmal als Team sicher im Gebrach von BDD werden und euch dann an komplexere Features wagen. Ansonsten könnte ggf. Frustration auf die Methode projiziert werden und das wäre schade, da BDD so viel Gutes für ein Produkt-Team beinhaltet.