Verhaltensgetriebene Entwicklung (Behavior-Driven Development)

Was ist verhaltensgetriebene Entwicklung (Behavior-Driven Development, BDD)?

Verhaltensgetriebene Entwicklung (Behavior-Driven Development, BDD) ist eine agile Entwicklungsmethodik, bei der Software anhand des Verhaltens dokumentiert, entworfen und entwickelt wird, das ein Benutzer bei der Interaktion mit einer App erwartet. Verhaltensgetriebene Entwicklung erweitert die Möglichkeiten der testgetriebenen Entwicklung (Test-Driven Development, TDD) und der akzeptanztestgetriebenen Entwicklung (Acceptance Test-Driven Development, ATDD), indem es die Zusammenarbeit zwischen den Beteiligten fördert und Szenarien in einfacher Sprache verfasst, die sowohl als ausführbare Tests als auch als lebendige Dokumentation verwendet werden können.

Verhaltensgetriebene Entwicklung zielt darauf ab, sicherzustellen, dass jede Softwareversion einen echten Mehrwert bietet, der ein Problem des Benutzers löst oder einen Geschäftsbedarf erfüllt. Der kollaborative Ansatz der Methodik zur Definition von Anforderungen ermöglicht es allen Beteiligten, die Anforderungen auf die gleiche Weise zu verstehen, und die iterativen Sprints der Methodik können die Zeit reduzieren, die zur Identifizierung und Behebung von Problemen benötigt wird.

Vorteile der verhaltensgetriebenen Entwicklung

Der Hauptvorteil der verhaltensgetriebenen Entwicklung besteht darin, dass es die Kommunikation und Zusammenarbeit zwischen Stakeholdern mit unterschiedlichen geschäftlichen Prioritäten und/oder technischem Fachwissen verbessert. Um den Stakeholdern zu helfen, den Zweck und das erwartete Verhalten einer Anwendung zu verstehen, werden Anforderungen immer als reale Szenarien ausgedrückt und in einfacher Sprache verfasst. Dieser Ansatz reduziert Unklarheiten und erleichtert es Teams, den Umfang jedes agilen Sprints aus der Perspektive des Benutzers zu verstehen.

Ein weiterer Vorteil der verhaltensgetriebenen Entwicklung besteht darin, dass ein einmal geschriebenes Szenario automatisiert und viele Male in verschiedenen Kontexten wiederholt werden kann. Dies ist wichtig, da so dasselbe Szenario für die Dokumentation und das Testen sowohl in der Entwicklungs- als auch in der Produktionsumgebung verwendet werden kann. Die Konzentration auf die Bedürfnisse der Benutzer trägt auch dazu bei, überflüssigen Code zu vermeiden. Da bei der verhaltensgetriebenen Entwicklung jede Funktionalität durch eine Verhaltensanforderung gestützt werden muss, können Teams Scope Creep und andere Probleme vermeiden, die den Softwareentwicklungslebenszyklus (Software Development Lifecycle, SDLC) verzögern.

So funktioniert verhaltensgetriebene Entwicklung

Ein typisches Projekt, das verhaltensgetriebene Entwicklung nutzt, beginnt mit einem Gespräch zwischen Softwareentwicklern, Softwaretestern, Produktverantwortlichen und potenziellen Endnutzern. Das Ziel ist es, ein gemeinsames Verständnis der Anforderungen zu entwickeln, das die erwarteten Verhaltensweisen in einfacher Sprache verdeutlicht und Akzeptanzkriterien definiert, bevor Code geschrieben wird.

In der Regel umfasst verhaltensgetriebene Entwicklung folgende Schritte:

• Ermitteln und Sammeln der Anforderungen nach Gesprächen mit allen Beteiligten.
• Definieren potenzieller Szenarien in einfacher, natürlicher (menschlicher) Sprache.
• Umwandeln der Szenarien in automatisierte Testskripte mit Tools wie Cucumber oder Concordion.
• Entwickeln von Quellcode, um die definierten Szenarien zu erfüllen.
• Testen des Codes, um zu überprüfen, ob die Funktionalität wie erwartet funktioniert.
• Verbessern des Codes durch Einbeziehen des Feedbacks der Beteiligten.
• Bereitstellung (Release) der Software, wenn das tatsächliche Systemverhalten dem erwarteten Verhalten entspricht.
• Wartung der Software, wenn sich die Anforderungen im Laufe der Zeit ändern, um sicherzustellen, dass die Funktionalität nicht beeinträchtigt wird.

Beispiele für verhaltensgetriebene Entwicklung

Sobald die Anforderungen identifiziert wurden, können Entwicklungsteams reale Szenarien schreiben und diese in automatisierte Tests umwandeln. In der Regel wird hierfür Gherkin verwendet, eine domänenspezifische Sprache, für die die Teammitglieder keine erfahrenen Programmierer sein müssen.

Stattdessen verwenden Gherkin-Szenarien ein Given-When-Then-Format, um zu beschreiben, wie sich die Software verhalten soll. Given legt den Ausgangskontext oder die Voraussetzungen fest, When beschreibt eine Aktion oder ein Ereignis, das das Verhalten auslöst, und Then gibt das erwartete Ergebnis an.

Hier sind zwei Beispiele für solche Szenarien:

Szenario: Erfolgreiche Anmeldung

Given: Der Benutzer befindet sich auf der Anmeldeseite der Website.

When: Der Benutzer gibt eine gültige Kombination aus Benutzername und Passwort ein und klickt auf die Schaltfläche Anmelden.

Then: Der Benutzer wird erfolgreich angemeldet.

Szenario: Artikel zum Warenkorb hinzufügen

Given: Der Benutzer befindet sich auf einer Produktseite.

When: Der Benutzer klickt auf Zum Warenkorb hinzufügen.

Then: Der Artikel wird zum virtuellen Warenkorb des Benutzers hinzugefügt.

Verhaltensgetriebene Entwicklungstests

In der Softwareentwicklung wird bei traditionellen Qualitätssicherungstests (QS) überprüft, ob der Code den technischen Spezifikationen entspricht. Bei der verhaltensgetriebenen Entwicklung hingegen wird bei Abnahmetests überprüft, wie sich der Code in verschiedenen Szenarien verhält. Die Betonung funktionaler Spezifikationen anstelle technischer Spezifikationen ist vorteilhaft für die Bereitstellung von Microservices in Continuous Integration- und Continuous Delivery-Pipelines (CI/CD). Microservices sind modulare Softwarekomponenten, die als Teil einer größeren Anwendung zusammenarbeiten. CI/CD-Pipelines sind automatisierte Workflows, die Codeänderungen integrieren, QS-Tests zur Validierung der Änderungen durchführen und akzeptierte Änderungen schnell und zuverlässig in die Produktion überführen.

Bei CI/CD-Bereitstellungen werden verhaltensspezifische Abnahmetests vor Beginn der Codierung geschrieben, sodass sie technisch gesehen zu Beginn eines Projekts, während sich ein Produkt noch in der Entwicklung befindet oder wenn es fertiggestellt ist, ausgeführt werden können. Es ist jedoch wichtig zu verstehen, dass die meisten Abnahmetests zu Beginn eines Projekts fehlschlagen werden, da die Funktionalität noch nicht entwickelt wurde. Im Laufe des Entwicklungsprojekts werden jedoch wahrscheinlich immer mehr Tests bestanden, und sobald alle Akzeptanzkriterien erfüllt sind, kann die Software für die Produktion freigegeben werden.

Um verhaltensgetriebene Tests zu erleichtern, sollten Entwicklungsteams Folgendes tun:

• Erwägen Sie die Verwendung des 5-Why-Prinzips, um Stakeholder dabei zu unterstützen, Bedürfnisse mit Prioritäten und Ergebnissen in Einklang zu bringen.
• Üben Sie das Schreiben von benutzerorientierten Szenarien.
• Erwägen Sie den Einsatz von Automatisierung, um benutzerorientierte Szenarien in ausführbare Akzeptanztests umzuwandeln.
• Akzeptanztests auf spezifische Benutzeranforderungen und/oder Geschäftsziele abstimmen.
• Ein zentrales Repository für Stakeholder bereitstellen, um Dokumentationen und den Projektfortschritt zu überprüfen.

Beliebte Tools und Frameworks

Es gibt zahlreiche Tools und Frameworks, die Entwicklungsteams dabei unterstützen, die verhaltensgetriebene Entwicklung einzuführen und seine vielen Vorteile zu nutzen. Zu den beliebtesten Tools gehören:

• Cucumber. Entwicklungs- und Testteams können Cucumber verwenden, um Akzeptanztests in einfacher Sprache zu schreiben und sie dann automatisch auszuführen.
• Behave. Behave ist ein Tool für Python-Entwickler. Wie Cucumber ermöglicht Behave Entwicklungsteams, Szenarien in Klartext mit Gherkin zu schreiben und sie automatisch über Schrittdefinitionen auszuführen. (Eine Schrittdefinition ist ein Snippet, das eine einzelne Zeile der Gherkin-Syntax mit dem Automatisierungscode verbindet, der sie ausführt.
• Behave Restful. Python-Entwickler und -Tester können Behave Restful verwenden, um in beliebigen Sprachen implementierte Microservices zu testen und REST APIs zu validieren.
• JBehave. JBehave ist ein Framework zum Schreiben und Ausführen von Java-Tests. Das Framework kann in verschiedene integrierte Entwicklungsumgebungen (IDE), darunter Eclipse, integriert werden, um die Erstellung und Ausführung von Tests zu optimieren, ohne die Entwicklungsumgebung verlassen zu müssen.
• Mocha. Mocha ist ein beliebtes JavaScript-Test-Framework, das auf Node.js und in Webbrowsern ausgeführt wird. Standardmäßig führt Mocha Tests seriell aus, um die Berichterstellung zu vereinfachen und sicherzustellen, dass Fehler den richtigen Testfällen zugeordnet werden. Mocha lässt sich in eine Vielzahl von Tools und Plugins von Drittanbietern integrieren, um kontinuierliche Tests zu unterstützen und agile Workflows mit Echtzeit-Feedback zu ermöglichen.
• Concordion. Concordion ist ein leichtgewichtiges Framework für Java-Entwickler. Tests werden in HTML oder Markdown geschrieben, und Java-Fixtures (Klassen) verknüpfen Spezifikationen mit ausführbarem Testcode.

Bewährte Verfahren für verhaltensgetriebene Entwicklung

Softwareentwicklungsteams können die Vorteile der verhaltensgetriebenen Entwicklung nutzen und gleichzeitig die Herausforderungen minimieren, indem sie die folgenden Best Practices anwenden:

• Schreiben Sie Testszenarien, bevor Sie Code schreiben.
• Ermutigen Sie Entwickler, Tester und Stakeholder zur Zusammenarbeit an Gherkin-Szenarien.
• Schreiben Sie Szenarien aus der Perspektive des Benutzers.
• Halten Sie Szenarien kurz und konzentrieren Sie sich auf das Geschäft, nicht auf die Technologie.
• Stellen Sie sicher, dass jedes Szenario ein einziges, klares Ergebnis überprüft.
• Verwenden Sie Schrittdefinitionen für verschiedene Szenarien nach Möglichkeit wieder.
• Organisieren Sie Szenarien mit Tags, damit sie leicht zu finden und zu verwenden sind.
• Verkürzen Sie Feedback-Schleifen, indem Sie Szenarien in CI/CD-Pipelines ausführen.

Häufige Herausforderungen und Nachteile der verhaltensgetriebenen Entwicklung

Obwohl die verhaltensgetriebene Entwicklung viele Vorteile hat, bringt sie auch einige Herausforderungen mit sich. Eine wichtige Herausforderung besteht darin, dass die Einführung und Anpassung eines Ansatzes der verhaltensgetriebenen Entwicklung mit einem hohen Lernaufwand verbunden sein kann. Entwickler und andere Stakeholder müssen lernen, wie man Szenarien in einfacher Sprache schreibt, die reale Probleme widerspiegeln. Außerdem müssen sie sich mit der Verwendung von Gherkin in Feature-Dateien vertraut machen, die als lebendige Dokumentation und automatisierte Abnahmetests dienen.

Eine weitere Herausforderung besteht darin, dass es für technisches Personal schwierig sein kann, mit nicht-technischem Personal zusammenzuarbeiten (und umgekehrt). In Organisationen mit klaren Trennlinien zwischen diesen beiden Teams kann die Überwindung der kulturellen Unterschiede zwischen verschiedenen Abteilungen fast genauso schwierig sein wie die Berücksichtigung unterschiedlicher technischer Fähigkeiten.

Verhaltensgetriebenes Design kann auch für Entwicklungsteams, die traditionell Wasserfall-Entwicklungsstrategien verwendet haben, eine Herausforderung darstellen. Verhaltensgetriebene Entwicklung erfordert, dass Szenarien (und damit Abnahmetests) vor dem Code geschrieben werden, was eine erhebliche Veränderung des Arbeitsablaufs mit sich bringt. Größere oder komplexere Projekte können auch den gesamten Softwareentwicklungslebenszyklus verlangsamen, da die Entwicklung und Pflege von Hunderten von benutzerorientierten Szenarien zeitaufwendig sein kann.

Da verhaltensgetriebene Entwicklung die Komplexität und Latenz im SDLC erhöhen kann, ist es möglicherweise nicht für jedes Entwicklungsprojekt der richtige Ansatz. Bei kleinen Projekten, Prototypen oder hochtechnischen Bibliotheken können die zusätzlichen Herausforderungen von verhaltensgetriebenen Implementierungen die Vorteile überwiegen, insbesondere in CI/CD-Pipelines, bei denen Geschwindigkeit und Einfachheit Vorrang vor der Kommunikation mit den Stakeholdern haben.