Softwareentwicklung im Homeoffice mit 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:

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.