Behavior Driven Development (BDD) ist eine spezielle Kommunikationstechnik für Produktteams, die darauf abzielt, ein gemeinsames Verständnis vom Verhalten einer Funktion zu erreichen und die Effektivität der Zusammenarbeit zu verbessern. Durch die konsequente Anwendung von BDD können Teams komplexe Softwareprodukte effizient entwickeln und sicherstellen, dass die entwickelten Features den Anforderungen der Nutzer entsprechen. In diesem Artikel werden die Grundprinzipien von BDD sowie praktische Tipps für die erfolgreiche Implementierung vorgestellt.
Warum BDD?
Einfachheit, Modularität und Übersichtlichkeit: BDD ermöglicht es allen Teammitgliedern, ein ausreichend gleiches Verständnis vom geplanten Feature zu erlangen, und zwar schnell. Durch die Verwendung von konkreten Beispielen anstelle abstrakter Beschreibungen werden Probleme im Verhalten des Features häufiger vor der Entwicklung erkannt.
Nachhaltigkeit und Zeitersparnis: Die Verwendung von Akzeptanzkriterien als Testfälle führt zu einer umfassenden Systemdokumentation, die während des gesamten Entwicklungsprozesses genutzt werden kann.
Grundprinzipien von BDD
BDD ist eine Kommunikationstechnik, die darauf abzielt, ein gemeinsames Verständnis vom Verhalten einer Funktion im Team zu erreichen. Dies geschieht durch die Formulierung von konkreten Beispielen, die beschreiben, wie sich das Feature in bestimmten Situationen verhalten soll. Diese Beispiele dienen als Grundlage für die Entwicklung von Akzeptanzkriterien, automatisierten Tests und Systemdokumentation.
In der Product Discovery, 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 verhalten soll. Sie dienen als Grundlage für die Diskussionen im Team und mit den Stakeholdern und helfen dabei, ein gemeinsames Verständnis vom Verhalten des Features zu entwickeln.
In der Product Delivery, während der Implementierung des Features, dienen die Szenarien als Grundlage für die Entwicklung von automatisierten Tests. Durch die Verwendung von Test Driven Development (TDD) können die Szenarien als Vorlage für erste automatisierte Tests verwendet werden, bevor der eigentliche Programmcode geschrieben wird. Dies ermöglicht es, Probleme im Verhalten des Features frühzeitig zu erkennen und zu beheben.
Die Bedeutung von Gherkin
Bei BDD wird häufig die Beschreibungssprache Gherkin verwendet, um die Szenarien zu formulieren. Gherkin hat eine sehr einfache Syntax, die lediglich aus einigen wenigen standardisierten Schlüsselwörtern und einer einfachen Struktur besteht. Die zentrale Frage lautet: „Wie soll sich das System unter welchen Bedingungen verhalten?“ Die Antworten auf diese Frage werden in Form von Szenarien beschrieben, die als Grundlage für die Entwicklung von Akzeptanzkriterien und automatisierten Tests dienen.
Ein Beispiel für die Verwendung von Gherkin in einem Szenario:
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
Prototypen in Verbindung mit Gherkin
Die Einbindung von Prototypen oder anderen visuellen Hilfsmitteln kann die Verständlichkeit und Akzeptanz der Szenarien weiter verbessern. Unterhalb eines Gherkin-Szenarios kann beispielsweise ein einfacher Wireframe platziert werden, um das erwartete Verhalten des Systems visuell zu verdeutlichen. Diese Bilder können von einem Designer erstellt worden sein und sollten gemeinsam mit den Szenarien und Beschreibungen besprochen und angepasst werden. Dies trägt dazu bei, potenzielle Missverständnisse zu minimieren und sicherzustellen, dass alle Teammitglieder ein einheitliches Bild von den Anforderungen haben.
Praxistipps für die erfolgreiche Implementierung von BDD
Präzise Formulierung: Gewährleiste eine klare und präzise Formulierung von User Stories und Szenarien. Vermeide Abstraktion und konzentriere dich auf das detaillierte Verhalten des Systems unter spezifischen Bedingungen.
Integration von Screenshots und Prototypen: Bereichere die Gherkin-Szenarien durch die Einbindung von Screenshots, Wireframes oder anderen Prototypen, um das Verständnis zu vertiefen und potenzielle Missverständnisse zu minimieren.
Bewahrung der Modularität: Teile komplexe Features in kleinere Module auf, um die Übersichtlichkeit und Verständlichkeit zu erhöhen.
Geduld und Experimentierfreude: Ermutige dein Team zur Geduld und zur Bereitschaft, BDD auszuprobieren, selbst wenn dies anfangs ungewohnt erscheint. Starte mit einfachen Features und steigere dich schrittweise.
Fokus auf Verhalten statt auf Oberflächenelemente: Bei der Formulierung von Gherkin-Szenarien liegt der Fokus auf dem erwarteten Verhalten des Systems, nicht auf der Beschreibung von UI-Komponenten. Vermeide es, sich in detaillierte UI-Beschreibungen zu vertiefen, und konzentriere dich stattdessen auf das „Was“ anstatt auf das „Wie“.
Kontinuierlicher Austausch im Team: Fördere den kontinuierlichen Austausch im Team, insbesondere während der Refinements oder Spezifikations-Workshops. Nutze die Gelegenheit, die vorformulierten Szenarien gemeinsam Schritt für Schritt durchzugehen und sicherzustellen, dass alle Teammitglieder ein gleiches Verständnis haben.
Three Amigos Sessions: Organisiere regelmäßige Three Amigos Sessions, bei denen Vertreter aus den Bereichen Produktmanagement, Entwicklung und Test gemeinsam die Szenarien durchgehen und diskutieren.
Durch die konsequente Anwendung dieser Praxistipps und die Integration von BDD in den Arbeitsalltag deines Teams kannst du die Effektivität der Kommunikation verbessern und sicherstellen, dass die entwickelten Features den Anforderungen der Nutzer entsprechen.
Quelle:
- Adzic, G. (2011). Specification by Example: How Successful Teams Deliver the Right Software (English Edition) (1st Aufl.). Manning.