• 6
  •  
  •  
  •  
  •  
  •  
    6
    Shares
BDD im Überblick

Software-Anforderungen, die jedem klar sind

Behaviour Driven Development – kurz BDD – vereinfacht bei der Suche nach Softwarespezifikationen die Zusammenarbeit zwischen Entwicklung, Testing und Business. Dazu kommen Tools und Frameworks zum Einsatz – doch BDD umfasst noch viel mehr.

08.11.2018Text: bbv0 Kommentare
BDD
  • 6
  •  
  •  
  •  
  •  

Die meisten Nutzer von Microsoft-Programmen kennen es: Word, Excel und PowerPoint sind zwar täglich im Einsatz, doch nutzen die meisten nur einen ganz kleinen Teil der Funktionen. Dabei hätten die Softwares noch viel mehr Fähigkeiten – von denen meist nur absolute Cracks Gebrauch machen. An dieses Phänomen wird man beim Erarbeiten von Softwarespezifikationen gerne erinnert. Denn es zeigt: Die richtigen, wirklich benötigten Software-Features zu finden, ist anspruchsvoller, als man denkt.

Agilisten versuchten es mit dem Test Driven Development, kurz TDD: Tests werden noch vor dem Schreiben von Code formuliert. Agile Teams sollen so konkrete Szenarien – und dadurch Software-Anforderungen – festhalten. So wird zuerst ein Test geschrieben und die entsprechende Eigenschaft dann implementiert. Danach erfolgt ein kurzes Refactoring des entstandenen Codes, ehe der nächste Test verfasst wird. Keine leichte Aufgabe, vor allem für Entwickler: «Entwickler denken oft in Lösungen und haben eine Vorstellung davon, wie sie den Code dafür zu schreiben haben», erklärt Michel Estermann, Senior Software Engineer bei bbv. «Einen Test zu schreiben, noch bevor überhaupt Code vorhanden ist, bereitet ihnen am Anfang Mühe.» Und da die Tests in klassischer Programmiersprache verfasst werden, sind sie für Business-Analysten und Stakeholder nur schwer verständlich – welche Spezifikationen die Software tatsächlich erfüllt, bleibt ihnen ein Rätsel.

Behaviour Driven Development (BDD), das aus dem TDD entstand, soll Abhilfe schaffen – und zwar dank neuer Terminologie: TDD als Begriff verwirrt, denn der Test ist eigentlich nur Mittel zum Zweck. Vielmehr stehen Software-Spezifikationen im Vordergrund. «Die Idee von BDD ist, dass man nicht mehr an Tests denkt, sondern an das Verhalten von Software», erklärt Estermann. «Man muss Softwareentwicklung also mit einem anderen Mindset betreiben.» Dazu gehört auch der Einsatz neuer Frameworks: Softwareanforderungen werden in konkreten Beispielszenarien festgehalten – und zwar in Gherkin, einer auf der natürlichen Sprache basierten Beschreibungssprache: Unter gewissen Gegebenheiten (Given) soll eine bestimmte Aktion (When) zu einem bestimmten Resultat (Then) führen. Etwa ein Login-Prozess:

1
2
3
Given a valid account
When you log in
Then you should see the dashboard

 

Über Tools hinausdenken

Der Vorteil dieser Schreibweise: Sie ist auch für Business-Analysten und Enduser, die von Anfang an in den Entwicklunsprozess miteinbezogen werden, verständlich – sie bekommen einen Eindruck davon, wie die Software letztlich im Betrieb funktioniert. Und dem fachlichen Tester erlaubt die vereinfachte Formulierung nicht nur, Tests manuell durchzuführen; mit Frameworks wie Cucumber oder SpecFlow lassen sich solche Beispiel Szenarien in ausführbare Spezifikationen wandeln und automatisieren.

BDD sollte aber nicht auf den reinen Einsatz von Tools beschränkt werden – ein Fehler, den immer noch viele Teams begehen: «Viele stürzen sich auf diese Frameworks und beginnen einfach, statt klassische Testcases solche Szenarien in Gherkin zu schreiben und automatisiert zu testen», erklärt Estermann. «Behaviour Driven Development bringt so aber sehr wenig Mehrwert. Das Ziel sollte vielmehr sein, ein gemeinsames Verständnis der Anforderungen zu bekommen, die man an die Software stellt.» Statt im Vorfeld einen riesigen Backlog mit Anforderungen und Features zu erstellen, die man einfach abarbeitet, muss festgelegt werden, welches Ziel man mit der Software erfüllen möchte – und welche Funktionalitäten dazu beitragen. Als Methode kann dazu das sogenannte «Feature Injection» hinzugezogen werden. Das Analysemodell umfasst drei Schritte und dient als Hilfsmittel, um Antworten auf folgende Fragen zu finden:

  • Hunt the value: Welchen Geschäftswert (Business value) soll die Software haben?
  • Inject the features: Welche Funktionalitäten tragen dazu bei, dass der Geschäftswert erfüllt wird?
  • Spot the examples: Welche Szenarien gibt es und wie geht die Software damit um?

Beim «Feature Injection» wird im Grunde genommen also rückwärts gearbeitet: Erst wenn die Outcomes einer Lösung genau definiert sind, versucht man herauszufinden, welche Inputs dazu benötigt werden. Mit dem «Impact Mapping» können diese Features schliesslich Mindmap-artig aufgezeichnet werden. Dabei werden folgende Fragen beantwortet:

  • Why?: Beschreibt das Ziel den Business Value als Mission Statement
  • Who?: Beschreibt die Akteure, also möglichen Stakeholder oder Persona, die das Ziel umsetzen
  • What?: Beschreibt die Auswirkungen und hält fest, wie die Akteure helfen können, das Geschäftsziel zu erreichen
  • How?: Beschreibt die Ergebnisse und hält fest, was getan werden muss, damit die Auswirkungen erreicht werden.

Impact Mapping

Der Aufbau einer Impact Map ist immer gleich. (Quelle: impactmapping.org)

 

Entwickler müssen beraten

Damit BDD mit Modellen wie Feature Injection und Impact Mapping gelingt, bedarf es nicht nur der gemeinsamen Sprache zwischen Projektverantwortlichen aus Entwicklung, Business und Testing; auch ein Blick fürs Ganze ist elementar: Entwickler, Tester und Stakeholder müssen sich im Klaren darüber sein, welches die Hauptfunktionalitäten einer Software sind, die zum gewünschten Business Value führen. Nur so erhalten sie die nötige Agilität und frühes Feedback und können dadurch weniger wichtige Spezifikationen gegen das Projektende schieben – oder notfalls sogar weglassen. Wie es schon Jeff Patton in seinem Buch «User Story Mapping» treffend formuliert hat: «Your job is not to build more – it’s to build less. Minimize output, and maximize outcome and impact.»

Dazu muss sich der Entwickler auch in den User hineinversetzen können – und nicht nur ausführende Kraft sein: «Herauszufinden, welche Features und Anforderungen vom Business tatsächlich benötigt werden, ist nicht nur Aufgabe des Requirements Engineers», erklärt Estermann. «Auch der Entwickler hat die Aufgabe, genau hier eine beratende Funktion wahrzunehmen. Eine gemeinsame Vision über das Projekt und das Ziel, das damit erreicht werden soll, ist unerlässlich.»

Der Experte

Michel Estermann

Michel Estermann ist Senior Software Engineer bei bbv. Er ist überzeugt, dass ein gemeinsames Verständnis der Vision, Ziele und Anforderungen essentiell für das Gelingen eines Projektes ist – ganz nach dem «Manifest für Agile Softwareentwicklung». Als Entwickler möchte er auch seinen Beitrag dazu leisten.

Unser Wissen im Abo

Zusammenarbeit und Kommunikation

Der Weg zum agilen Unternehmen

  • 3
    Shares
Innovation
Monitoring für Produktentwicklung

Einblick ins Nutzerverhalten

  • 1
    Share
Softwareentwicklung
Licence to code

Mit James Bond zu mehr Agilität

  • 6
    Shares
Agile

Artikel kommentieren

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