•  
  •  
  •  
  •  
  •  
Corona-Beitragsserie: Behaviour Driven Development

Softwareentwicklung im Homeoffice mit BDD

Durch die Coronakrise arbeiten auch viele agile Entwicklerteams von zuhause aus – was die Zusammenarbeit nicht immer einfach macht. Mit dem Behaviour Driven Development lassen sich mögliche Missverständnisse aus dem Weg räumen.

28.05.2020Text: bbv1 Kommentar
BDD
  •  
  •  
  •  
  •  

Das Coronavirus hat viele Software-Entwickler ins Homeoffice verfrachtet. Zwar dürften gerade Pendler die wegfallenden Arbeitswege und flexiblen Arbeitszeiten begrüssen. Dennoch steht fest: Die Arbeit von zuhause aus birgt auch gewisse Tücken. Nicht zuletzt für agile Software-Entwickler: Oft legen sie grossen Wert auf co-location, also die Zusammenarbeit im selben Büro – weil dadurch ein reger Austausch über die Software-Anforderungen der einzelnen Stakeholder stattfinden kann. Der Konsens über die Funktionalitäten der Software wird so ständig aufrechterhalten. Im Homeoffice ist dieser Dialog trotz Collaboration-Tools und Video Conferencing jedoch eingeschränkt.

Eine Methode zur agilen Softwareentwicklung eignet sich besonders, um die Kommunikation in verteilten Teams zu verbessern: Behaviour Driven Development, kurz BDD. Im Wesentlichen beruht BDD auf dem Acceptance Test Driven Development (ATDD) – es werden also zuerst Akzeptanztests geschrieben, bevor ein Feature umgesetzt wird. Der Unterschied: Beim BDD werden diese Akzeptanztests – als entscheidender Bestandteil von User Stories – so verfasst, dass sie auch von Business-Stakeholdern zumindest gelesen oder sogar geschrieben werden können. Damit wird sichergestellt, dass diese auch in verteilten Teams nicht von der Kommunikation ausgeschlossen werden. Grundlage dafür ist eine einheitliche, domänenspezifische Syntax nach beispielsweise Gherkin. Sie beruht im Wesentlichen auf der Beschreibung von Softwarespezifikationen nach dem «Given-When-Then»-Prinzip.

  • Given: die Testvorbedingungen
  • When: die einzelnen Testschritte, die durchgeführt werden
  • Then: die Kriterien, die am Schluss abgefragt werden müssen, um zu prüfen, ob die Software das gewünschte Verhalten an den Tag legt.

Das Beispiel-Szenario «Addition von zwei Zahlen in einem Taschenrechner» würde etwa wie folgt geschrieben werden:

1
2
3
4
Given I have entered 2 in the calculator
And I have entered 3 in the calculator
When I Press Add
Then the result should be 5

 

Hier liegt der entscheidende Vorteil von BDD: Software wird nicht mit Detailspezifikationen beschrieben, sondern anhand konkreter, für alle Stakeholder verständlicher Beispiele. Gleichzeitig ist die Schreibweise formalisiert genug, um als Grundlage für automatisierte Akzeptanztests zu dienen. Im .NET-Stack unterstützt beispielsweise SpecFlow BDD-Praktiken: Die Softwarekriterien, die nach Gherkin in einer natürlichen Sprache verfasst und im Feature-File zusammengefasst sind, werden in ausführbarem Code umgewandelt und für die Durchführung automatisierter Tests bereitgestellt. Entwickler erhalten dank diesem Vorgehen auch eine Übersicht über fehlgeschlagene, geglückte und noch nicht implementierte Tests – sprich, eine lebendige Dokumentation über den aktuellen Zustand der Software und seiner Akzeptanzkriterien. Das bekannte Werweissen, ob sich jetzt das System falsch verhält, oder die Dokumentation nicht aktuell ist, gehört somit der Vergangenheit an.

BDD ersetzt den Austausch nicht

Trotz all der Vorteile, die BDD bietet, müssen sich Entwickler eines immer vor Augen halten: Eine User Story besteht nicht nur aus der Beschreibung und den damit zusammenhängenden Akzeptanzkriterien, sondern auch aus den Gesprächen. Die Interaktionen im Team, seien es Scrum-Zeremonien oder der übliche tägliche Austausch unter Teammitgliedern, sollen weiterhin stattfinden. Kein System, keine Methode dieser Welt kann diese ersetzen – auch BDD nicht. Jedoch erhalten Teams mit diesem Entwicklungsansatz eine gemeinsame Diskussionsgrundlage, die dank der Beispielhaftigkeit viel unmissverständlicher sein sollte als allgemeine Systembeschreibungen. BDD hilft dabei, dass der Geschäftsnutzen, der immer wieder gerne hinaufbeschworen wird, tatsächlich zum Tragen kommt. Und zwar nicht nur bei der Entwicklung, im Requirements Engineering oder im Testing, sondern holistisch über das ganze Softwareentwicklungsteam und den ganzen Prozess hinweg.

Behaviour Driven Development

Der Experte

Alan Ettlin

Alan Ettlin ist, neben seinem Engagement bei bbv Consultancy, Business Area Manager bei bbv Software Services und betreut in dieser Funktion Kunden von ersten Ideen hin zu erfolgreich eingeführter Software mit gemeinsam entwickelten Lösungsansätzen – ganz im Sinne von «Making Visions Work».

Unser Wissen im Abo

GUIs und HMIs

Interfaces entwickeln – mit dem User, für den User

Innovation
Flexibilität von Softwarearchitekturen

Softwarearchitektur in der agilen Welt

Qualitätssicherung
Problem Solving für Softwareentwickler

Einen Weg finden oder einen schaffen

Softwareentwicklung

1Kommentar

Artikel kommentieren

Die E-Mail-Adresse wird nicht publiziert. Notwendige Felder sind mit einem * versehen.