Einführung in Behavior-Driven Development (BDD)

Wir hatten das Vergnügen, Michel Estermann von der bbv Software Services AG bei uns zu haben, der uns eine Einführung in das Thema Behavior-Driven Development (BDD) gab.

Behavior-Driven Development (BDD)

BDD ist eine fortschrittliche Methode der Softwareentwicklung, die besonders darauf ausgerichtet ist, die Zusammenarbeit zwischen den technischen Teams und dem Business zu verbessern. Durch die Verwendung von klaren und strukturierten Szenarien, die in Alltagssprache verfasst sind, ermöglicht BDD ein tieferes gemeinsames Verständnis für die zu entwickelnde Software. Michel Estermanns Expertise bot uns wertvolle Einblicke in die Praxis von BDD und wie es dazu beiträgt, die Qualität und den Wert der Softwareentwicklung zu steigern.

From TDD to BDD

Test Driven Development (TDD) ist vielen sicherlich bekannt. Behavior-Driven Development (BDD) und Acceptance Test Driven Design (ATDD) sind Methoden, die auf TDD aufbauen. TDD unterstützt uns hauptsächlich dabei, gute Software zu schreiben, die leicht lesbar, wartbar und veränderbar ist. Um sicherzustellen, dass wir das Richtige entwickeln, kann ATDD genutzt werden. Dabei werden Akzeptanztests aus der Kundenperspektive formuliert, um die gesamte Software oder einzelne Teile davon zu überprüfen.

Die Weiterentwicklung von TDD zu BDD begann mit der Erkenntnis, dass der Begriff "Test" im Zusammenhang mit TDD oft zu Missverständnissen führte, denn oft liegt der Fokus darauf eine bereits angedachte Lösung zu verifizieren. Dan North bemerkte, dass es für viele einfacher ist, Tests aus einer Verhaltensperspektive zu schreiben, anstatt direkt mit Fokus auf den Test. Daher begann er, TDD als BDD, also Behavior-Driven Development, zu bezeichnen. BDD zielt darauf ab, die Kommunikationslücke zwischen technischen und geschäftlichen Stakeholdern zu schliessen, indem es eine gemeinsame Sprache und strukturierte Gespräche fördert.

BDD - mehr als einfach nur Tests in Gherkin-Sprache ausführen

Behavior-Driven Development (BDD) ist weit mehr als nur die Ausführung von Tests in der Gherkin-Sprache. Es ist ein kollaborativer Ansatz, der darauf abzielt, die Kommunikation zwischen Business- und IT-Experten zu verbessern und ein gemeinsames Verständnis der Anforderungen zu schaffen. BDD fördert die Zusammenarbeit über verschiedene Rollen hinweg und versucht dabei zu helfen, die richtige Software auf die richtige Weise zu entwickeln. Durch die Verwendung von verständlichen Szenarien, die das erwartete Verhalten des Systems beschreiben, ermöglicht BDD eine klare Kommunikation über die Funktionalität, die das Endprodukt bieten soll. Dies führt zu einer präziseren und effizienteren Entwicklung, da von Anfang an klar ist, was das System leisten soll und wie es sich verhalten wird. BDD geht über die reine Testautomatisierung hinaus und bietet einen Rahmen für die Entdeckung, Formulierung und anschliessende Automatisierung von Anforderungen, wodurch die Qualität und der Wert der Software gesteigert werden. Ein zentraler Aspekt von BDD ist die Verwendung einer gemeinsamen Sprache, die auf einfachen, strukturierten Sätzen basiert und von allen Stakeholdern verstanden wird. Dies erleichtert die Kommunikation innerhalb des Projektteams und mit den Geschäftsinteressenten. Die Dokumentation des Systems, die automatisch gegen das Verhalten des Systems geprüft wird, ist ein weiteres wichtiges Ergebnis von BDD.

BDD-Praktiker arbeiten häufig von aussen nach innen, beginnend mit einem fehlschlagenden Akzeptanztest, der das Verhalten des Systems aus der Sicht des Kunden beschreibt. Diese Akzeptanztests werden als Beispiele formuliert, die jeder im Team lesen kann, und tragen zur Entwicklung einer gemeinsamen, allgegenwärtigen Sprache bei, um über das System zu sprechen.

Mit den Schritten Discovery, Formulation und Automatisierung der Anforderungen, wird versucht sicher zu stellen, dass das Team nicht nur die Software richtig baut, sondern auch die richtige Software entwickelt, die auf die Geschäftsziele ausgerichtet ist.

Zusätzlich gibt es weitere Ansätze wie Feature Injection (siehe auch: “BDD in Action” by John Ferguson Smart) und Impact Mapping , die dabei helfen, die minimalen Funktionen zu identifizieren, die den grössten Nutzen für die Stakeholder bieten, und sicherzustellen, dass die entwickelten Funktionen einen echten Einfluss auf die Geschäftsziele haben.

Im Nachfolgenden schauen wir uns die einzelnen Schritte noch etwas vertiefter an:

Discovery

Ziel der Discovery Phase ist es ein gemeinsames Verständnis einer User Story zu erarbeiten. Die Anforderungen dürfen hier hinterfragt werden und Beispiele sowie Edge-Cases werden aufgestellt. Am besten geht dies von Angesicht-zu-Angesicht. In einem Workshop können die User Stories diskutiert werden. Wichtig ist, dass die “Three Amigos” (Businessanalyst, Entwickler und Tester) dabei sind.

Um Struktur in den Workshop zu bringen empfiehlt sich “Example Mapping”. Zuerst werden zu einer User Story die Akzeptanzkriterien definiert. Danach werden Beispiele und Edge-Cases zur Veranschaulichung dieser Akzeptanzkriterien gesucht und aufgeschrieben. Allfällige Fragen werden separat gesammelt, um die Diskussion nicht aufzuhalten. Wenn die Diskussion zur Story nach 20-25 Minuten nicht fertig ist, oder zu viele Fragen aufgetaucht sind ist die User Story zu gross oder zu ungenau formuliert.

Formulation

Nach der erfolgreichen Discovery geht es zur nächsten Phase. Die gesammelten Beispiele werden in einer strukturierten Sprache wie Gherkin dokumentiert. Diese erlaubt es, dass die Beispiele sowohl vom Entwickler für die Automatisierung verwendet werden können als auch, dass der Businesspartner diese in Prosa versteht. Im folgenden Beispiel sieht man, wie ein nach Gherkin strukturierter Text aussehen kann.

 1  Feature: Pick process teach menu: Pick die 
 2  In order to verify the die pick teach settings 
 3  As an operator 
 4  I want to pick a die from the wafer 
 5
 6  Scenario: Pick a die with the die sensor activated 
 7  Given the machine is adjusted and ready to use 
 8  When the operator picks a die after teaching the die picker 
 9  Then a die should be on the pickup tool 
10  And no die should be at the current wafer position

Automation

In diesem Schritt werden die Beispiele bzw. Akzeptanzkriterien in automatisierte Tests umgewandelt. Hierzu eignen sich verschiedene Programme und Tools:

• Cucumber: Ein Tool, das Gherkin-Szenarien in automatisierte Tests umwandelt.
• SpecFlow: Ähnlich wie Cucumber, aber für .NET-Umgebungen.
• JBehave: Ein Framework für Java, das BDD unterstützt.
• Behat: Ein BDD-Framework für PHP.
• FitNesse: Ein Tool, das als Testsystem und Wiki dient und die Zusammenarbeit fördert.
• Relish: Eine Plattform, um BDD-Spezifikationen zu veröffentlichen und zu teilen.

Implementation

Nun wird der eigentliche Programmcode erstellt, um die zuvor in den Tests beschriebenen Anforderungen zu erfüllen.

Story Mapping

Ohne eine gute User Story ist der vorhin beschriebene Prozess nur schwer zu durchlaufen. Story Mapping (Konzept von Jeff Patton) hilft im BDD-Prozess ein gemeinsames Verständnis für die Anforderungen und das gewünschte Verhalten eines Systems zu entwickeln und dadurch User Stories zu strukturieren sowie zu visualisieren. Somit ermöglicht es Teams, den Überblick über die Anforderungen zu behalten und sicherzustellen, dass alle Aspekte der User Story berücksichtigt werden. Durch das Mapping wird die Komplexität der Anforderungen greifbar und die Entwicklung kann zielgerichtet erfolgen. Neue Stories werden durch Feature Injection und Impact Mapping gefunden.

Feature Injection

Feature Injection ist ein Prozess, der darauf abzielt, das Minimum an Funktionen (Features) zu identifizieren, die den Stakeholdern den grössten Nutzen im Hinblick auf ihre Ziele bieten. Es ist ein Ansatz, der in der agilen Softwareentwicklung verwendet wird, um sicherzustellen, dass nur die notwendigsten und wertvollsten Funktionen entwickelt werden.

Die Schritte der Feature Injection sind:

1. Hunt the Value: Identifizieren des Wertes, den ein Feature für das Geschäftsziel bringt.
2. Inject the Features: Einfügen der identifizierten Features in das Produkt.
3. Spot the Examples: Finden von konkreten Beispielen, die das Feature und seine Funktionsweise veranschaulichen.

Dieser Ansatz hilft dabei, Überentwicklung zu vermeiden und sicherzustellen, dass die Entwicklungsbemühungen auf die Features konzentriert werden, die den grössten Einfluss auf die Geschäftsziele haben.

Impact Mapping

Impact Mapping ist eine strategische Planungstechnik, die verwendet wird, um sicherzustellen, dass die entwickelten Funktionen (Features) und Projekte einen echten Einfluss auf die Businessziele haben. Es handelt sich um einen visuellen Prozess, der dabei hilft, Annahmen zu klären und die Ausrichtung des Teams auf die Geschäftsziele zu verbessern. Der Prozess besteht aus vier Hauptkomponenten:

• Goal (Ziel): Definiert den Zweck des Projekts oder Features, oft in Form eines SMART-Ziels.
• Actors (Akteure): Identifiziert die Personen oder Systeme, die das Ziel beeinflussen können, sowohl positiv als auch negativ.
• Impact (Auswirkung): Beschreibt, wie das Verhalten der Akteure geändert werden sollte, um das Ziel zu erreichen.
• Deliverables (Liefergegenstände): Bestimmt die konkreten Aktionen oder Features, die entwickelt werden sollten, um die gewünschten Auswirkungen zu erzielen.

Impact Mapping hilft dabei, Verschwendung zu reduzieren, indem es den Umfang des Projekts begrenzt und unnötig komplexe Lösungen verhindert. Es fördert die Priorisierung von Features basierend auf ihrem tatsächlichen Geschäftswert und unterstützt die iterative Entwicklung, indem es die Möglichkeit bietet, Annahmen zu überprüfen und anzupassen.

Fazit

Heutzutage gibt es ganz verschiedene Ansätze und Philosophien wie man an das Thema “Tests schreiben” herangehen kann. ATDD, STDD, FTDD, Specification by Example und BDD haben zwar aufgrund der involvierten Personen eine unterschiedliche Geschichte sowie Terminologie, jedoch das gleiche Ziel: Die richtige Software richtig zu entwickeln.

BDD möchte die Kommunikationslücke zwischen dem Business und den Technikexperten schliessen, indem der gemeinsame Fokus zuerst auf einen Austausch und Workshops liegt, um ein gemeinsames Verständnis zu schaffen. Erst danach geht man zur Automatisierung der Akzeptanzkriterien und dem eigentlichen Test schrieben übergeht. Somit sollte BDD auch nicht als reines Automatisierungstool missverstanden werden; es geht in erster Linie um Kollaboration und das Entdecken von Features und Szenarien. Dabei ist es ratsam zuerst TDD (Test-Driven Development) verstanden zu haben, bevor man mit BDD beginnt.