BDD-Testbaukasten

Mit der Umstellung zur agilen Softwareentwicklung haben sich die Anforderungen an das Testing drastisch verändert. War es zuvor üblich, eine eigene Phase für das Testing zu dedizieren, so verlangen die kurzen Entwicklungszyklen eine andere Art der Testorganisation. Ein wesentlicher Unterschied ist, dass alle relevanten Testverfahren präventiv geplant werden müssen [1]. Dazu ist eine enge Zusammenarbeit zwischen Entwicklern und Testern notwendig. Des Weiteren müssen Tests wesentlich häufiger ausgeführt werden, was eine Automatisierung der Tests unerlässlich macht.Ein Ansatz, der diese Anforderungen erfüllt, ist das Test Driven Development (TDD). Dieses iterative Vorgehen verlagert das Schreiben eines Tests vor die Implementierung des eigentlichen Codes („Test First“). Zunächst wird ein neuer (Unit-)Test realisiert, der bei der ersten Ausführung meist fehlschlägt. Daraufhin wird der Code implementiert, der nötig ist, um diesen Test zu erfüllen. Sobald der Test erfolgreich ist, wird der bestehende Code refaktorisiert. Anschließend geht das Verfahren mit dem nächsten Testfall weiter. Bild 1 zeigt den Zyklus beim TDD. Der Test-First-Ansatz verspricht eine nahezu vollständige Testabdeckung durch Unit-Tests und aufgrund des ständigen Refactorings einen hochwertigen Code. Das Behaviour Driven Development (BDD) folgt demselben Ansatz.

Da das Testing und die Entwicklung von einer Instanz übernommen werden, ist die Kompatibilität von Tests und Code sichergestellt. Was durch TDD jedoch nicht garantiert werden kann, ist, dass die Tests und der umgesetzte Code genau den Anforderungen entsprechen, die durch den Fachbereich definiert worden sind. Dazu ist eine Einbeziehung der Business-Analyse in den Vorgang notwendig, was mit BDD erreicht werden kann.

Der Ursprung von BDD

Der Begriff BDD wurde bereits 2003 von Dan North vorgestellt [2]. BDD wurde basierend auf etablierten agilen Praktiken entwickelt und soll diese für Teams, die neu in der Bereitstellung agiler Software sind, zugänglicher und effektiver machen. Seinen Ursprung nahm BDD als Ansatz, bei dem die Funktion von Testmethoden zusätzlich in natürlicher Sprache beschrieben wurde. Die Beschreibung wurde der Ausführung entsprechend aneinandergereiht und generierte automatisch eine Dokumentation des Testfalls.Mittlerweile hat sich BDD zu einem Ansatz entwickelt, bei dem in erster Linie die Zusammenarbeit zwischen der Business-Analyse und der Entwicklung verbessert werden soll. Dabei wird besonderer Wert darauf gelegt, dass sich Anforderungen, deren Umsetzung und die zugehörigen Tests auf ein reales Problem beziehen. Durch eine Verbesserung der Kommunikation zwischen den einzelnen Bereichen wird sichergestellt, dass die umgesetzte Software nicht nur auf technischer Ebene funktioniert, sondern auch exakt die Anforderungen des Fachbereichs erfüllt. Nur wenn die Software einem Business Value zugeordnet werden kann, wird sie in BDD auch als „Software that matters“ anerkannt. Dazu muss erreicht werden, dass die Anforderungen einen Nutzer- oder Stakeholder-Bezug haben und dass die Umsetzung die entscheidenden Akzeptanzkriterien erfüllt.Um die Geschäftsanforderungen korrekt zu erfüllen, muss daher genau verstanden werden, was die Software aus Sicht des Fachbereichs erreichen soll.

Das Problem: Costs of Translation

An dieser Stelle soll ein interessantes Konzept von Konstantin Kudryashov vorgestellt werden [3]. In einem standardisierten Requirements-Engineering-Prozess werden Anforderungen identifiziert und meist von Business-Analysten oder anderen Mitarbeitern aus dem Fachbereich formuliert. Anschließend werden die Anforderungen an die Entwicklung weitergereicht.Der Entwickler muss diese fachliche Anforderung nun in Code übersetzen. Ein Problem, das hierbei auftreten kann, ist, dass die fachlich formulierte Anforderung vom Entwickler anders interpretiert wird als von der Business-Analyse. Das Verständnis des Fachbereichs unterscheidet sich in mancher Hinsicht vom Verständnis der Entwicklung. Das kann sogar so weit gehen, dass gemeinsames Vokabular der beiden Gruppen unterschiedlich interpretiert wird. Ein extremes Beispiel dafür ist das „Konten-Management“ in einem Projekt im Bereich Banking: Während der Fachbereich von einem nutzerzugehörigen Bankkonto spricht, versteht ein Entwickler darunter eine Nutzerkonto-Verwaltung. Somit kann die Entwicklung unter Umständen Wochen oder Monate an der Anforderung „Implementierung eines Konten-Management-Systems“ arbeiten, bis auffällt, dass der Kunde etwas völlig anderes wollte. Abhängig davon, wie viel Zeit vergeht, bis ein solcher Fehler entdeckt wird, entstehen Kosten – die sogenannten Costs of Translation. Ein kürzerer Entwicklungszyklus senkt daher die Costs of Translation.Bei solchen „Übersetzungs-“ oder „Interpretationsfehlern“ handelt es sich nicht um Bugs, sondern um vermeidbare Fehler im Kommunikationsprozess. Ein ähnlicher Übersetzungsprozess findet beim Ableiten von Tests aus Anforderungen statt. BDD versucht, genau diese Kosten zu senken, indem es einerseits den Feedback-Zyklus verkürzt und andererseits die Zusammenarbeit der Business-Analyse und der Entwicklung bei der Definition von Anforderungen fördert.

Anforderungen gemeinsam mit Beispielen ­definieren

Um die Costs of Translation zu minimieren oder ganz zu vermeiden, bedarf es also eines gemeinsamen Verständnisses über die Anforderungen seitens des Fachbereichs, der Entwicklung und des Testings. Doch wie lassen sich auf komplexen Business-Regeln basierende Anforderungen verständlich und eindeutig erklären? Die Lösung, die BDD bietet, ist eine Definition anhand konkreter praktischer Beispiele. Indem man eine Anforderung über mehrere Beispiele beschreibt, wird das gewünschte Verhalten der Software ersichtlich. Durch genau definierte erwartete Ergebnisse lassen Beispiele keinen Freiraum zur falschen Interpretation. Zur Beschreibung der Beispiele wird eine universelle, semistrukturierte Sprache verwendet. Sie dient dem effektiven Austausch über die Anforderungen auf einer gemeinsamen Ebene. Die meistgenutzte Sprache im BDD-Kontext ist Gherkin; sie folgt einem simplen Format von Given, When, Then [3]:

• Given beschreibt den anfänglichen Kontext für das Beispiel.
• When beschreibt die Aktion, die der Akteur im System oder der Stakeholder ausführt.
• Then beschreibt das erwartete Ergebnis dieser Aktion.

Die in Gherkin beschriebenen Beispiele ähneln einer Formulierung in natürlicher Sprache. Durch die vorgegebenen Schlüsselwörter wird gleichzeitig eine Struktur eingehalten. Das ist wichtig, um exakte Schritte festzulegen und die erwarteten Ergebnisse herauszustellen, die später zur Überprüfung der Anforderung dienen.Meist lässt sich eine Anforderung nicht mit nur einem Beispiel beschreiben, da unterschiedliche Aktionen des Nutzers zu unterschiedlichen Ergebnissen führen sollen. Die gewünschten Ergebnisse hängen von den zugrunde liegenden Business-Regeln ab.Angenommen, der Fachbereich eines Online-Handels möchte, dass die Premiumkunden des Unternehmens beim Kauf von fünf Büchern Gratisversand erhalten. Dabei können Fragen aufkommen wie: Überträgt sich der Gratisversand auch auf andere Artikel, die mitbestellt werden? Es ist also ein Beispiel notwendig, das dieses Szenario beschreibt. Die Anforderung, in Gherkin „Feature“ genannt, wird somit durch mehrere Bespiele zu unterschiedlichen Szenarien beschrieben (vergleiche Bild 2). Weitere durch Szenarien abzudeckende Fragen könnten sein: Gilt der Gratisversand auch, wenn sich unter den fünf Büchern E-Books befinden? Wie ist damit umzugehen, wenn der Nutzer einen Expressversand gewählt hat? Die Beispiele sollten die Frage beantworten: Wie soll sich die Software bei bestimmten Eingaben und Interaktionen verhalten? Um den Aufwand zu optimieren, müssen nicht alle möglichen Eventualitäten beschrieben werden, aber genug, damit keine Unklarheiten mehr bestehen.

Die Three Amigos

Die Anforderungen beziehungsweise Szenarien sollten stets so formuliert und ausgearbeitet sein, dass die drei davon betroffenen Bereiche Business-Analyse, Entwicklung und Testing oder Qualitätsmanagement ein einheitliches Verständnis haben. Für diese Herausforderung entwickelte George Dinwiddie [4] das Konzept der Three Amigos. Ziel ist es, die drei unterschiedlichen Perspektiven der jeweiligen Bereiche in einem Raum zusammenzubringen. Je nach Projekt können noch andere relevante Bereiche wie das UX-Design hinzugezogen werden. Dazu kommen drei oder mehr Vertreter der Abteilungen zusammen und konkretisieren gemeinsam die Anforderungen. Sie klären Unklarheiten in den Definitionen der Anforderungen, tauschen sich über die mögliche Umsetzung aus und legen Akzeptanzkriterien fest.Der Austausch der Three Amigos dient nicht nur dazu, zukünftige Fehler zu vermeiden, sondern kann auch zum Finden von besseren Lösungen führen. Der Entwickler kann beispielweise aufgrund seiner Erfahrung einen Lösungsweg aufzeigen, den die Business-Analyse nicht als Möglichkeit sah; oder der Tester weist den Entwickler auf ein absehbares Problem des Lösungswegs hin. Der Austausch kann dabei helfen, Teilbereiche eines Problems zu identifizieren, die weniger wichtig sind und/oder erst zu einem späteren Zeitpunkt umgesetzt werden können [5].Die Treffen der Three Amigos sollten in kurzen, zeitlich beschränkten Sitzungen unmittelbar vor Beginn der Umsetzung der Anforderungen stattfinden. In Scrum beispielsweise sollten während eines Sprints die Anforderungen des kommenden Sprints behandelt werden. Zwar ist die Three-Amigo-Methode kein fester Bestandteil von BDD, jedoch passt sie ausgezeichnet in dieses Vorgehen.

Example Mapping

Um die Anforderungsbeschreibung – beispielsweise in einem Three-Amigo-Meeting – möglichst einfach zu gestalten, kann die Methode Example Mapping herangezogen werden [6]. Zuvor definierte Anforderungen oder Stories werden in einem festgelegten Zeitfenster von 25 Minuten besprochen. Sie sollten dabei nicht vollkommen detailliert beschrieben sein, da die Teilnehmer gemeinsam die Details der Story erarbeiten und ihren Kontext verstehen sollen. Zunächst stellt der Product Owner oder ein anderer Vertreter der Stakeholder die Story vor. Die Teilnehmer bestimmen dann gemeinsam die Business-Regeln, die der Story zugrunde liegen, und notieren diese auf farbige Karten. Zu den einzelnen Regeln werden daraufhin Beispiele bestimmt, welche die Regeln prüfen, und diese ebenfalls auf Karten mit einer anderen Farbe notiert. Bei der Diskussion werden teilweise Fragen aufkommen, auf die niemand eine Antwort kennt. Diese werden dokumentiert und sind für das weitere Konkretisieren der Story zu klären. Es können auch zunächst Annahmen getroffen werden, um mit einer Story fortfahren zu können.Bild 3 zeigt die Zuordnung von Story, Regeln, Beispielen und Fragen des Example Mapping. Beim Austausch über eine Story kann diese als zu umfangreich bestimmt und in mehrere kleinere Stories aufgeteilt werden. Es können aber auch neue Stories identifiziert werden, die dann in den Backlog aufgenommen werden. Example Mapping hilft, große und komplexe Stories zu konkretisieren, indem die einzelnen Teilprobleme für sich betrachtet werden.

Testautomatisierung von Szenarien

Nun stellt sich noch die Frage, ob und wie eine Automatisierung der Szenarien zu Tests möglich ist. Hier helfen Automatisierungs-Tools wie Cucumber, Specflow und JBehave. Diese Tools analysieren textbasiert die Schritte der Szenarien. Dadurch lassen sich zu den individuellen Schritten Testmethoden hinterlegen, welche die gewünschte Funktionalität ausführen und das Ergebnis prüfen. Die Implementierung der Testmethoden gilt es so vorzunehmen, dass die Schritte voneinander unabhängig ausführbar sind. Dazu müssen die Schritte so weit konkretisiert werden, dass sie elementaren Funktionen entsprechen. Erst dann sind die Schritte für verschiedene Szenarien wiederverwendbar. Werden Szenarien mit bereits implementierten Schritten erstellt, so entstehen dabei automatisierte Regressionstests, die schnelles Feedback geben. Die Features und Szenarien können dann automatisiert ausgeführt werden und geben ein Testergebnis zurück. Damit lässt sich eine Spezifikation und Dokumentation des Systems schaffen.Der große Vorteil von Cucumber und Gherkin ist, dass Testfälle in einer beinahe natürlichen Sprache definiert werden können und damit für jeden verständlich sind. Die Szenarien werden in einem Editor geschrieben und können nahezu frei formuliert werden. Das macht dieses Vorgehen aber gleichzeitig fehleranfällig und sehr aufwendig umzusetzen, da zu jedem unterschiedlichen Schritt eine Ausführung hinterlegt werden muss. Das heißt, dass eine alternative Formulierung und jeder Tippfehler in einem Schritt die Zuordnung zum Test verhindern und damit die Automatisierung brechen [7].

Seed-Test

Die Anwendung Seed-Test versucht genau dieses Problem zu lösen. Sie unterstützt das automatisierte Testen von Web­anwendungen nach dem BDD-Ansatz. Durch das Vorgeben vordefinierter Schritte wird sichergestellt, dass alle Schritte des Szenarios eine funktionierende Ausführung hinterlegt haben. Die Schritte sind entsprechend der Gherkin-Logik in drei Kategorien unterteilt und werden jeweils aus einer Liste ausgewählt. Zuerst können Schritte wie beispielsweise ein URL für den Startpunkt als Vorbedingungen (Given) für den Testfall festgelegt werden. Die für den eigentlichen Test auszuführenden Schritte, wie Eingaben in Textfelder oder Button-Klicks, lassen sich als Aktionen (When) hinzufügen. Zur Überprüfung des Ergebnisses (Then) stehen Schritte zur Auswahl wie die Prüfung, ob eine Weiterleitung auf eine neue Seite erfolgreich war, oder ob bestimmte Texte angezeigt werden. Der Anwender kann die Tests sofort ausführen und erhält als Ergebnis einen anschaulichen Report.Ein weiteres Ziel von Seed-Test ist es, das Erstellen von Tests so weit zu vereinfachen, dass auch Anwender ohne tiefreichende Programmierkenntnisse Testfälle definieren können. Die Schritte sind so aufgebaut, dass nur noch die gewünschten Eingabe- und Ausgabewerte eingetragen werden müssen. Der Nutzer bekommt kein leeres Dokument ohne Anhaltspunkte präsentiert, sondern er kann ein Szenario Schritt für Schritt zusammenbauen. Bild 4 zeigt ein einfaches Szenario in Seed-Test mit vier Schritten.

Seed-Test ist eine Open-Source-Webanwendung und auf GitHub [8] zu finden. Sie wurde mit dem MEAN-Stack (MongoDB, Express.js, AngularJS und Node.js) umgesetzt. Zur Automatisierung der Schritte werden Cucumber und Sele­nium eingesetzt. Die Szenarien sind durch eine Anbindung an ein Ticketsystem direkt mit den Anforderungen verbunden. Mit den bisher definierten Schritten können Webapplikationen getestet werden.

Vorteile von BDD gegenüber klassischem ­Vorgehen

Die Features und ihre konkreten Szenarien sind im BDD-Vorgehen bereits als Anforderungen und Dokumentation für den Fachbereich und die Entwicklung von hoher Bedeutung. Durch die Umwandlung zu Testfällen werden sie ebenfalls Kernbestandteil des Qualitätsmanagements. Damit bilden die Szenarien das zentrale Dokument und die Schnittstelle zwischen Fachbereich, Entwicklung und Qualitätsmanagement. In BDD rückt das Testing stärker ins Zentrum des Entwicklungsprozesses und ist nicht länger eine ausgelagerte Instanz. Das erfolgreiche Ausführen der auf den Szenarien basierenden Tests ist nichts anderes als das Erfüllen der Akzeptanzkriterien der Anforderung. Durch eine Automatisierung können sie weiterhin als Regressionstest genutzt werden.Durch BDD bauen alle am Entwicklungsprozess beteiligten Bereiche ein gemeinsames Verständnis für die umzusetzende Software auf. Eine gemeinsame und universell verständliche Sprache stellt sicher, dass jeder Beteiligte, unabhängig vom technischen Wissen, einen gründlichen Einblick in den Projektfortschritt hat. Dadurch haben alle Parteien einen gemeinsamen Blick auf das Projekt und können auf einer Ebene kommunizieren.In BDD können alle Entwicklungsarbeiten direkt auf die Geschäftsziele zurückgeführt werden. Die Entwicklung erfüllt damit möglichst genau die Benutzeranforderungen. Das dadurch entstehende Softwaredesign entspricht so den Geschäftsanforderungen und unterstützt auch die Umsetzung von anstehenden Anforderungen. Die vertiefte Anforderungsanalyse in BDD ermöglicht eine effizientere Priorisierung der Anforderungen, sodass geschäftskritische Funktionen zuerst bereitgestellt werden. Der Test-First-Ansatz in BDD erhöht die Codequalität und führt zur Reduzierung der Wartungskosten und Minimierung des Projektrisikos.

Fazit

Behaviour Driven Development (BDD) fördert die Zusammenarbeit zwischen Business-Analyse, Entwicklung und Qualitätsmanagement. Der BDD-Ansatz lässt sich in zwei grundlegende Punkte unterteilen:

• Die Praxis, Beispiele in einer universell verständlichen Sprache zu verwenden, um zu beschreiben, wie Benutzer mit dem Produkt interagieren.
• Diese Beispiele als Grundlage für automatisierte Tests zu verwenden.

Damit wird nicht nur die Funktionalität der Software sichergestellt, sondern auch, dass das System während der gesamten Projektlaufzeit den Intentionen des Fachbereichs entspricht.Ein weiteres Ziel von BDD ist, die Costs of Translation, die beim Übertragen von Anforderungen in Code und Testfälle entstehen, zu minimieren. Mit Unterstützung durch Tools wie Cucumber wird die Automatisierung von Tests nach BDD möglich, bringt aber auch diverse Herausforderungen mit sich. Die Open-Source-Anwendung Seed-Test versucht einige dieser Probleme zu lösen und Cucumber und BDD für eine breitere Nutzergruppe zugänglich zu machen.

Fussnoten

1. Jan Wolter, Agile Testing – The New Normal, http://www.dotnetpro.de/SL2011SeedTest1
2. Dan North, Introducing Behaviour Driven Development;, http://www.dotnetpro.de/SL2011SeedTest2
3. Konstantin Kudryashov, The beginner’s guide to BDD, in Dan North Q & A, http://www.dotnetpro.de/SL2011SeedTest3
4. George Dinwiddie, A Lingua Franca between the Three (or More) Amigos, http://www.dotnetpro.de/SL2011SeedTest4
5. Todd Charron, George Dinwiddie on the Three Amigos (Business, Programmers, and Testers), http://www.dotnetpro.de/SL2011SeedTest5
6. Matt Wynne, Introducing Example Mapping, http://www.dotnetpro.de/SL2011SeedTest6
7. Johannes Bergsmann, Behaviour Driven Testing und automatische Unit-Test-Generierung, http://www.dotnetpro.de/SL2011SeedTest7
8. Seed-Test auf GitHub, http://www.dotnetpro.de/SL2011SeedTest8