Behavior-Driven Development – Problemlos einsetzbar in agilen Bestandsprojekten?

Im Jahr 2012 wurde das Expenditionary Combat Support System der US Air Force nach sieben Jahren und mit Entwicklungskosten von über einer Milliarde Dollar abgeschafft. Als Grund wird angegeben, dass das System trotz siebenjähriger Entwicklungszeit keine nennenswerten, militärischen Fähigkeiten erbracht hat [1]. Und dieses Projekt stellt kein Einzelfall dar. Rund die Hälfte aller Softwareprojekte liefert keine wesentlichen Ergebnisse [2]. Hinzu kommt, dass viele Projekte abgebrochen oder nicht rechtzeitig fertig werden. Gründe hierfür gibt es mehrere. Zum einen kann es vorkommen, dass die Software nicht fehlerfrei funktioniert. Zum anderen wird oft nicht das umgesetzt, was ursprünglich von Kunden angefragt wurde.

Daher habe ich in meiner Bachelorarbeit den Ansatz des Behavior-Driven Development (BDD) als Entwicklungsmethode untersucht. Dies ist eine Methodik der Softwareentwicklung und Testautomatisierung, die den Fokus auf die Beschreibung des Verhaltens einer Anwendung legt, indem Anforderungen in einer Einheitssprache verfasst und in Code übersetzt werden. Für die Sicherstellung fehlerfreier Software wird unter anderem auf die Testautomatisierung zurückgegriffen. Mit Unit Tests werden aber beispielsweise nur einzelne Komponenten auf Korrektheit überprüft. Das bedeutet Programmierfehler können schnell nach der Entstehung gefunden und behoben werden. Wie aber wird sichergestellt, dass ein Softwareprojekt wie das Expenditionary Combat Support System das liefert, was von den Fachexperten verlangt wird? Mithilfe von BDD.

Ziel der Thesis war die Identifikation der Herausforderungen, die bei der Einführung von Behaviour-Driven Development in bereits laufenden, agilen Softwareprojekten entstehen können. Die Fragestellung ging aus immer wiederkehrenden Anfragen von Kunden aus, die sich von dieser Methodik eine höhere Qualität versprachen. Wie das Ergebnis meiner Bachelorarbeit gezeigt hat, kann der Einsatz von BDD jedoch problematisch werden, wenn Projekte schon längere Zeit in Bearbeitung sind und nicht „auf der grünen Wiese“ starten.

Traditioneller Entwicklungsprozess vs. BDD – ein Vergleich

Abbildung 1 stellt die Kernprinzipien von BDD mit denen der traditionellen Entwicklung gegenüber. Vergleicht man beide Methoden, lassen sich einige Vorteile der verhaltensgetriebenen Softwareentwicklung erkennen:

1. Es wird über den tatsächlichen Nutzen einer Anforderung diskutiert.
2. Requirements werden nicht mehr nur aufgeschrieben, sondern in einer Diskussion zwischen den Rollen Product Owner (PO), Tester und Entwickler in einer sogenannten Three Amigo Session spezifiziert und in einer Domain Specific Language (DSL) wie Gherkin, also einer Einheitssprache abgenommen.
3. Die DSL sorgt für eine deutlich bessere Kommunikation im Projektteam. Jeder im Team, ganz egal ob Fachbereich oder Entwicklung, ist in der Lage, die Sprache zu verstehen. So wird Missverständnissen vorgebeugt. Im Folgenden Beispiel wird eine Anforderung an einen Bankautomaten in der Gherkin Syntax spezifiziert:
   Scenario: Account has sufficient funds
   Given the account balance is $100
   And the card is valid
   And the machine contains enough money
   When the Account Holder requests $20
   Then the ATM should dispense $20
   And the account balance should be $80
   And the card should be returned 
4. Mit Hilfe von BDD Frameworks wie beispielsweise Cucumber werden die in der Einheitssprache geschriebenen Szenarien mit dem Test-First Ansatz erst in Testfälle und dann in Applikationscode umgewandelt. Fehlinterpretationen der Anforderungen durch Tester oder Entwickler können dadurch vermieden werden.
5. Die Dokumentation wird aus den automatisierten Tests generiert und gibt immer den aktuellen Stand des Projekts wieder. Sie verhält sich „lebendig“ und wird daher Living Documentation genannt.

Die Auflistung der Vorteile von BDD gibt den Anschein, dass der Einsatz der Methodik BDD durchaus sinnvoll ist. Ganz so einfach wie auf den ersten Blick kann das jedoch nicht beurteilt werden. Vor allem dann nicht, möchte man diese Methodik in ein laufendes Bestandsprojekt einbauen. Hier kommt es stark darauf an wie die Organisation und das System eines Projektes aufgebaut sind.

Wichtige Kriterien für den erfolgreichen Einsatz von BDD in Bestandsprojekten

Product Owner, Entwickler und Tester werden in BDD schon sehr früh in den Entwicklungsprozess miteingebunden, um deren Know-how schon in der Anforderungsanalyse nutzen zu können. Ist beispielsweise der PO eines Projekts nebenbei noch in anderen Projekten beschäftigt und hat für die „Three Amigo Sessions“ keine Kapazität, so wirkt sich das negativ auf den Einsatz der Methodik aus. Auch die Entwickler und Tester müssen sich über eine anfangs zeitintensive Erweiterung ihres Aufgabenspektrums bewusst sein. Sie sind nicht mehr nur für die Entwicklung bzw. für die Erstellung von Testszenarien verantwortlich, sondern müssen in der Three Amigo Session dazu beitragen, die genauen Anforderungen in einer Einheitssprache mit dem Blick aus der Entwicklung und dem Testing zu spezifizieren.

Die Projektdauer sollte langfristig geplant sein. In kurzen Projekten lohnt sich schlichtweg der Aufwand mit Blick auf den Ertrag der Methodik nicht. Ziel von BDD ist es nämlich auch, dass Testfälle später von Rollen geschrieben werden können, die unter anderem nicht das technische Know-how eines Entwicklers besitzen, wie beispielsweise der PO.

Eine weitere ernstzunehmende organisatorische Charakteristik ist die Ansässigkeit des Projektteams. Während sich das Inhouse Development als geeignetste Teamplatzierung herausgestellt hat, so führen Offshore und Outsourcing durchaus zu Problemen. Die Kommunikation ist in BDD ein essentieller Faktor. Projektteams, die nicht in einem Raum/Gebäude sitzen, haben lange Kommunikationswege und möglicherweise auch verschiedene Zeitzonen, was eine kontinuierliche Kommunikation deutlich erschwert.

Sollte sich ein Projekt bezüglich der Organisation als geeignet herausstellen, bedeutet das jedoch noch lange nicht, dass BDD in diesem Bestandsprojekt problemlos einsetzbar ist. Hierfür muss auch die Systemarchitektur des Projekts geeignet sein. Für die Untersuchung der Systemarchitektur muss unterschieden werden, auf welcher Testebene BDD eingeplant wird.

Der Einsatz von BDD ist generell überall dort möglich, wo das Verhalten relevant für das Business ist. Demnach hat es sich angeboten eine Unterteilung der Systemcharakteristiken in die drei verschiedenen Testebenen GUI-, Integrations- und Unit-tests vorzunehmen:

Auf GUI-Testebene sind beispielsweise leicht ansprechbare Elemente des HTML Codes wichtig (Nutzung von Identifikatoren, Namen und CSS Klassen). Andernfalls würde eine komplizierte und vor allem wartungsintensive Logik benötigt werden um einzelnen HTML Elemente anzusprechen.

Plant man den Einsatz von BDD auf Integrationstestebene ein, so hat sich ein an Domain Driven Design (DDD) angelehntes API Design als besonders wichtig gezeigt. Das liegt ganz einfach daran, dass APIs mit DDD aus fachlicher Sicht entworfen sind. APIs, die schwer verständlich sind und ein großes Maß an Wissen über die Systemlogik benötigen, machen den Einsatz von BDD besonders schwierig, weil die Schnittstellen nicht intuitiv ansprechbar sind.

Für Unit Tests kommt die Struktur des Applikationscodes mit ins Spiel. Grundlage für testbaren Sourcecode sind unter anderem Design Patterns. So stellt auch auf Unit Testebene DDD eine gute Grundlage für die Nutzung von BDD dar, da durch die Nutzung von DDD die ubiquitäre Sprache im Source Code abgebildet wird. Unstrukturierter Code, welcher keine Standards besitzt, ist für automatisiertes Testen ungeeignet und stellt demnach auch für BDD große Probleme dar.

Was nicht unerwähnt bleiben darf ist, dass BDD den Test Driven Design Ansatz (TDD) verfolgt. Demnach werden Tests vor der Entwicklung verfasst. Projekte, die den TDD Ansatz im laufenden Projekt schon vollziehen, sind besonders geeignet für BDD.

Fazit

Die in diesem Blogbeitrag vorgestellten Charakteristiken sind lediglich ein kleiner Auszug und sollen mögliche Problemfelder aufzeigen, die bei einem Einsatz von BDD in laufenden Projekten entstehen können. Trotz allem lässt sich festhalten, dass die Methodik BDD an sich sicherlich dazu beitragen kann, qualitativ hochwertige Systeme zu entwickeln. In Projekten, welche nicht auf der „grünen Wiese“ starten ist der Einsatz jedoch mit Vorsicht zu genießen. Es gilt daher genau abzuwägen, inwiefern ein Einsatz der Methodik möglich ist – je nach Struktur und Organisation des Bestandsprojektes. Sind die oben ausgeführten Charakteristiken erfüllt, ist BDD auch in Bestandsprojekten ein zu empfehlender Ansatz.
Auch wir bei doubleSlash evaluieren aktuell den Einsatz von BDD in laufenden Bestandsprojekten. Wir sind davon überzeugt, dass wir durch den Einsatz von BDD unsere Softwarequalität nochmals steigern können. BDD kann einen wichtigen Beitrag dazu leisten, auch in Zukunft unseren eigenen und den Qualitätsansprüchen unserer Kunden in Softwareprojekten gerecht zu werden.

Quellen:

[1] C. Kanaracus, Air Force scraps massive ERP project after racking up $1 billion in costs, 2012.

[2] J. F. Smart, BDD in action: Behavior-Driven Development for the whole software lifecycle. Shelter Island, NY: Manning Publications, 2015.