Behavior Driven Development

Behavior Driven Development, abgekürzt BDD, ist eine relativ neue Methodik zur Entwicklung von Software durch kontinuierliche Beispiel-basierte Kommunikation zwischen Entwicklern, QA und BA. Beim Behavior Driven Development handelt es sich im Kern um eine Softwareentwicklungsmethodik, die Methoden aus der testgetriebenen Entwicklung (Test Driven Development, TDD) und dem Domain-gesteuerten Design (Domain Driven Design, DDD) kombiniert.

Der Hauptzweck der BDD-Methodik besteht darin, die Kommunikation zwischen den Projektbeteiligten zu verbessern, sodass jedes Merkmal von allen Mitgliedern des Teams vor Beginn des Entwicklungsprozesses richtig verstanden wird. Dies hilft, Schlüsselszenarien für jede Geschichte zu identifizieren und Mehrdeutigkeiten aus den Anforderungen zu beseitigen.

Die Prinzipien des Behavior Driven Development

In BDD werden Beispiele als Szenarien bezeichnet. Szenarien werden in einem speziellen Format namens Gherkin geschrieben. In den Szenarien wird erläutert, wie sich ein bestimmtes Feature in verschiedenen Situationen mit unterschiedlichen Eingabeparametern verhalten sollte. Sie werden “ausführbare Spezifikationen” genannt, weil Gherkin strukturell ist und sowohl die Spezifikation als auch die Eingabe in automatisierte Tests ermöglicht.

Die verhaltensorientierte Entwicklung wurde vom Amerikaner Dan North als Antwort auf die folgenden Fragen entwickelt:

• Wo kann ich den Prozess starten?
• Was wird getestet und was nicht?
• Wie sollen die Tests genannt werden?
• Wie kann man verstehen, warum ein Test fehlschlägt?

Das Herzstück von Behavior Driven Development ist ein sich veränderndes Konzept für Komponententests und Akzeptanztests, das North bei der Lösung dieser Probleme entwickelt hat. Dan North sagt zum Beispiel, dass die Testnamen ganze Sätze sein sollten, die mit dem Wort “sollte” beginnen und in der Reihenfolge des Geschäftswerts geschrieben werden müssen. Akzeptanztests sollten unter Verwendung des agilen Standard-Frameworks einer User Story geschrieben werden.

Ubiquitäre Sprache des BDD

Behavior Driven Development betont die Bedeutung einer allgegenwärtigen Sprache, die auch als domänenspezifische Sprache oder DSL (Domain Specific Language) bezeichnet wird. Die DSL sollte von allen Teammitgliedern zu Beginn des Entwicklungslebenszyklus klar definiert und vereinbart werden. DSL ermöglicht eine einfache Kommunikation über die Domäne des Projekts und sollte sowohl einfach als auch robust genug sein, um die Diskussion zwischen allen Arten von Mitarbeitern, von Entwicklern und Teamleitern bis hin zu Kunden und Führungskräften, zu unterstützen.

Welche Werkzeuge werden beim Behavior Driven Development verwendet?

Was sind die Vorteile des Behavior Driven Development?

Behavior Driven Development bindet Produktteams, Stakeholder, QA-Team und Entwickler auf derselben Seite ein und bietet eine Plattform, um die unterschiedlichen Sichtweisen aufzulösen. Dadurch wird sichergestellt, dass alle Beteiligten die gleichen Erwartungen haben. Diese Zusammenarbeit zwischen den Beteiligten führt wiederum zu klaren, eindeutig definierten Abnahmekriterien. Das Ziel von BDD ist eine lesbare und domänenspezifische Sprache, mit der das Verhalten eines Systems beschrieben werden kann, ohne zu erklären, wie dieses Verhalten implementiert wird.

Tests werden in Form von Beschreibungen in Klartext geschrieben, wobei die Szenarien in der Regel vor allem anderen geschrieben und von den nicht technischen Stakeholdern verifiziert werden. Für die Erstellung von Tests sind keine Entwicklungsfähigkeiten erforderlich, da Tests in der Alltagssprache geschrieben werden. So können beispielsweise auch Business Analysten aktiv an der Überprüfung von automatisierten Testfällen teilnehmen und Feedback geben, um sie zu verbessern.

Behavior Driven Development ist stark von testgetriebener Entwicklung abgeleitet und beeinflusst, daher gelten viele der Vorteile, die für TDD gelten, auch für BDD. Da eine ganze Reihe von Tests kontinuierlich ausgeführt wird und immer neue Tests hinzugefügt werden, reduziert BDD die Wahrscheinlichkeit von Regressionsfehlern, da die Codebasis ständig überwacht und getestet wird.

Zudem verbessert Behavior Driven Development die Teamkommunikation. Die Abhängigkeit von einer ubiquitären Sprache bedeutet, dass BDD die Kommunikation über das gesamte Team oder sogar zwischen Unternehmen verbessern kann, da es bei der Diskussion der Begriffe eine gemeinsame Basis für Phrasen und Terminologie gibt.

Hinzu kommt, dass sowohl die Kosten als auch die Risiken bei BDD im Vergleich zu vielen anderen Methoden sehr niedrig sind. Ein weiterer attraktiver Aspekt ist, dass Behavior Driven Development leicht rückgängig zu machen ist, wenn es den Anforderungen nicht gerecht wird, und Entwicklerteams ohne großen Aufwand zu den gewohnten Methoden zurückkehren können. Daher sind sowohl die Kosten als auch die Risiken bei BDD im Vergleich zu vielen anderen Methoden sehr niedrig.

Die Nachteile des Behavior Driven Development

BDD erfordert, dass sich das Team vor der Entwicklung zusammensetzt und sowohl die DSL- als auch die detaillierte Spezifikationsdokumentation (User Stories) für jedes Szenario oder Feature ausgibt. Für viele Teams, insbesondere für größere Projekte, ist diese Einschränkung möglicherweise kein Problem, aber für kleinere Teams und schnelle Projekte kann dieser zusätzliche Aufwand und diese zusätzliche Anforderung eher ein Hindernis als Hilfe sein.

Während der Kontakt zu Benutzern, Kunden oder Analysten für einige Teams kein Problem darstellt, kann diese Anforderung des ständigen Kontakts mit externen Mitarbeitern für viele Unternehmen negative Auswirkungen auf die Entwicklungszeit haben. In Fällen, in denen Feedback benötigt wird, wenn eine neue User Story oder ein neues Szenario vor dem Schreiben von Tests oder Funktionscode erforderlich ist, kann der Entwicklungsprozess zum Stillstand kommen.