Früher ver­brach­te das Qua­li­täts­ma­nage­ment Wochen damit, eine fertig ent­wi­ckel­te Software auf ihre Funk­tio­na­li­tät zu über­prü­fen. Heute finden Sie dank au­to­ma­ti­sier­ter Tests per Knopf­druck heraus, ob eine komplexe Anwendung ihre Aufgaben ohne Probleme erfüllt. Eine immer be­lieb­te­re Technik ist das Behavior Driven De­ve­lo­p­ment, kurz BDD. Diese Form der agilen Software-Ent­wick­lung ist aus dem Test Driven De­ve­lo­p­ment (TDD) ent­stan­den und wird als dessen logische Er­wei­te­rung angesehen. Anders als bei TDD wird bei BDD die jeweilige Software vor­nehm­lich aus der Sicht des Anwenders be­trach­tet. Ein solcher Ansatz fördert ein ganz­heit­li­che­res Software-Design und er­leich­tert die Zu­sam­men­ar­beit zwischen Ent­wick­lern, Qua­li­täts­ma­na­gern und Kunden.

Was ist Behavior Driven De­ve­lo­p­ment?

Mit wach­sen­der Kom­ple­xi­tät von Software-An­wen­dun­gen entstehen auch immer mehr Qualitäts- und Test­ma­nage­ment­me­tho­den. Nur so lassen sich die Funk­tio­na­li­tät einzelner Kom­po­nen­ten zu­ver­läs­sig über­prü­fen und Fehler sofort aufspüren. Schon länger bekannt ist die test­ge­lei­te­te Ent­wick­lung oder Test Driven De­ve­lo­p­ment (TDD). Hierbei erstellen Ent­wick­ler parallel zur Software passende Unit-Tests oder Sys­tem­tests. Beim De­sign­pro­zess einer Software ist es jedoch durchaus sinnvoll, nicht nur Pro­gram­mie­rer, sondern auch Team­mit­glie­der oder Stake­hol­der ohne tech­ni­sches Code-Ver­ständ­nis mit­ein­zu­bin­den. Das Behavior Driven De­ve­lo­p­ment (BDD) macht genau das möglich.

Bei der agilen Software-Ent­wick­lung können alle Pro­jek­teil­neh­mer das ge­wünsch­te Verhalten der Anwendung de­fi­nie­ren, bevor der Pro­gram­mie­rer den Quelltext erstellt. Dies geschieht anhand von Be­schrei­bun­gen, die in für Menschen leicht ver­ständ­li­cher Sprache verfasst werden. Das heißt, dass auch der Kunde, für den die Software ent­wi­ckelt wird, einen aktiveren Part in der Mo­del­lie­rung übernimmt. BDD fördert also die Zu­sam­men­ar­beit und sorgt für eine Um­ver­tei­lung der Ver­ant­wor­tung. Setzen Sie diese Art der Software-Ent­wick­lung richtig ein, vermeiden Sie von vor­ne­her­ein Miss­ver­ständ­nis­se und ge­ne­rie­ren im Idealfall ein qua­li­ta­tiv hoch­wer­ti­ge­res End­pro­dukt.

Wie genau funk­tio­niert Behavior Driven De­ve­lo­p­ment?

Wie der Name es schon sagt, ori­en­tiert sich Behavior Driven De­ve­lo­p­ment an dem Verhalten, das die jeweilige Software zeigen soll. Dank der so­ge­nann­ten ubi­qui­tä­ren Sprache – was so viel bedeutet wie „allgemein ver­wen­de­te Sprache“ – können auch Laien bestimmte Ver­hal­tens­be­schrei­bun­gen erstellen. Die ubi­qui­tä­re Sprache stammt aus dem Domain Driven Design (DDD), das sich genau wie das BDD auf die An­wen­dungs­do­mä­ne kon­zen­triert. Beide Ansätzen be­rück­sich­ti­gen alle be­tei­lig­ten Bereiche bei der Software-Er­stel­lung und verbinden diese un­ab­hän­gig von Frame­works, Pro­gram­mier­spra­chen oder Tools mit­ein­an­der. Durch die Ver­wen­dung einer ein­heit­li­chen Sprache ist genau dies möglich.

Trotz allem kommt auch das Behavior Driven De­ve­lo­p­ment nicht ganz ohne Tools und Frame­works aus. Denn damit die von Ihnen de­fi­nier­ten Testfälle auch in einen aus­führ­ba­ren Code übersetzt werden können, müssen Sie sich an ein paar Regeln halten. Be­schrei­bun­gen im BDD werden zum Beispiel nicht im freien Fließtext verfasst. Mithilfe von BDD-Tools wie JBehave, Cucumber oder Behat folgen Sie einer fest­ge­leg­ten Struktur, die eine korrekte Im­ple­men­tie­rung er­mög­licht. Der Umgang mit diesen Tools ist deutlich einfacher als das Erlernen einer klas­si­schen Pro­gram­mier­spra­che. Hier erfahren Sie, welcher hier­ar­chi­schen Struktur Sie beim Behavior Driven De­ve­lo­p­ment nor­ma­ler­wei­se folgen:

  • Führen Sie zunächst eine An­for­de­rungs­ana­ly­se durch, bei der Sie die Aufgaben, Ziele und Funk­tio­na­li­tä­ten der Software genau de­fi­nie­ren. Stellen Sie sich oder Ihrem Kunden also die Frage, was die Software alles können soll.
  • Nachdem Sie alle Funk­tio­na­li­tä­ten iden­ti­fi­ziert haben, werden diese in Form von vor­de­fi­nier­ten Szenarien be­schrie­ben. Versuchen Sie, dabei an alle möglichen Si­tua­tio­nen zu denken, in denen die Software mit einer be­stimm­ten Antwort reagieren soll.
  • Im nächsten Schritt halten Sie die erwartete Antwort für jedes Szenario im „An­ge­nom­men-Wenn-Dann“-Schema fest. „An­ge­nom­men“ be­schreibt die Software vor dem Test, „Wenn“ die Aktion während des Tests und „Dann“ den Zustand der Software nach dem Test.

Je nachdem, welches BDD-Tool Sie verwenden, kann das Vokabular leicht variieren. Statt „An­ge­nom­men“ ak­zep­tie­ren manche Tools auch For­mu­lie­run­gen wie „Gegeben sei“. Solche Werkzeuge sind übrigens für die gän­gigs­ten Pro­gram­mier­spra­chen wie Java, Ja­va­Script, Python oder Ruby er­hält­lich.

Behavior Driven De­ve­lo­p­ment: Ein Fall­bei­spiel

Stellen Sie sich vor, Sie möchten einen nut­zer­freund­li­chen On­line­shop ent­wi­ckeln. Hat sich der Kunde einmal in Ihrem Shop re­gis­triert, sollen seine Nut­zer­da­ten ge­spei­chert werden. So kann er sich immer wieder einloggen und muss seine per­sön­li­chen Daten nicht erneut eingeben. In der weit ver­brei­te­ten Gherkin-Sprache, die im BDD-Werkzeug Cucumber zum Einsatz kommt, sieht die richtige Syntax wie folgt aus:

Funktionalität: Ein bestehender Kunde soll sich mit seinen Zugangsdaten in sein Benutzerkonto einloggen können
	Szenario: Kunde gibt beim Login-Vorgang die korrekten Zugangsdaten ein
		Angenommen ich habe ein gültiges Benutzerkonto
		Und ich befinde mich auf der Login-Webseite
		Wenn ich meine E-Mail-Adresse in das E-Mail-Feld eingebe
		Und ich mein zugehöriges Passwort in das Passwort-Feld eingebe
		Und ich auf den Login-Button klicke
		Dann sollte ich automatisch eingeloggt werden

Das obige Beispiel zeigt, dass Sie mithilfe des Zusatzes „Und“ gleich mehrere Be­din­gun­gen auf­stel­len und so Ihre Testfälle so komplexer gestalten können.

Was un­ter­schei­det BDD von anderen Test­ver­fah­ren?

Beim Testen einer Software be­schäf­tigt sich Behavior Driven De­ve­lo­p­ment mit der „Wie“-Frage. Die Be­tei­lig­ten wollen wissen, wie sie das Verhalten eines Codes und nicht dessen Im­ple­men­tie­rung richtig testen können. Bei einem so­ge­nann­ten Modultest geht es hingegen darum, ob eine einzige Code-Einheit richtig im­ple­men­tiert wird. Dieses Test­ver­fah­ren be­schäf­tigt sich also mit dem „Was“ und ist ein schneller Weg, einzelne Bugs auf­zu­fin­den. Die Frage nach dem „Wenn“ be­ant­wor­tet das Test-Driven-De­ve­lo­p­ment, bei dem es um den Prozess des Aus­füh­rens von Tests geht. Dieser Prozess kann auch Mo­dul­tests oder andere Test­me­tho­den be­inhal­ten.

Hinweis

Neben Mo­dul­tests gibt es auch noch In­te­gra­ti­ons- und Funk­ti­ons­tests. Diese sind um einiges komplexer, da sie sich mit dem Zu­sam­men­spiel ver­schie­de­ner Sys­tem­tei­le und der Ge­samt­funk­tio­na­li­tät einer Software be­schäf­ti­gen.

In der Tabelle unten sind die Vorteile und Nachteile des Behavior Driven De­ve­lo­p­ment kurz zu­sam­men­ge­fasst:

Vorteile Nachteile
Dank ubi­qui­tä­rer Sprache ideal für Ein­stei­ger, da kein Vorwissen nötig Schlecht ge­schrie­be­ne Spe­zi­fi­ka­tio­nen er­schwe­ren die Arbeit für Ent­wick­ler
Bessere Kom­mu­ni­ka­ti­on zwischen Ent­wick­lern, Stake­hol­dern und Qua­li­täts­ma­na­gern Das Einbinden mehrerer Parteien führt zu längeren Ent­wick­lungs­zei­ten
Testfälle dienen als lebendige Do­ku­men­ta­ti­on und lassen sich leicht anpassen Umrüstung auf BDD-Workflow führt zu höherem Aufwand bei Legacy-Codes
Fokus liegt auf End­an­wen­der und Nut­zer­freund­lich­keit der Software

Obwohl Sie jedes Test­ver­fah­ren einzeln anwenden können, wird die Qualität Ihrer Software um einiges erhöht, wenn Sie mehrere Test­ver­fah­ren in Kom­bi­na­ti­on verwenden. Mit BDD de­fi­nie­ren Sie dabei die beste Vor­ge­hens­wei­se beim Schreiben von Tests, während Sie mit TDD für eine hohe Test­ab­de­ckung sorgen.

Zum Hauptmenü