Behavior-Driven Development (BDD) ist eine Technik der agilen Softwareentwicklung. Dieser liegt ein beispielgetriebener Prozess zugrunde, in dem Szenarien in einer ubiquitären Sprache beschrieben und zur Anforderungserfassung, Testdefinition und Testautomatisierung durchgängig verwendet werden. Tabelle 1 zeigt den Nutzen von BDD.
| Customer Facing | Es wird über den Nutzen von Anforderungen diskutiert |
| Ubiquitous Specification | Anforderungen werden nicht nur aufgeschrieben, sondern gemeinsam erarbeitet und später abgenommen |
| Living Documentation | Die Dokumentation wird automatisch geprüft und veraltet nicht |
| Readability | Lesbare Tests vereinfachen die Kommunikation und erhöhen die Verständlichkeit |
| Maintainability | Die Tests sind leicht anpassbar und unterstützen damit agile Softwareentwicklung |
| State-of-the-art Testautomation |
Eine Vielzahl von Werkzeugen ist verfügbar und setzt auf betriebsbewährten Technologien und offenen Standards auf |
Der gewinnbringende Einsatz von BDD erfordert im Projekt allerdings Anpassungen an Rollen und Abläufe, sodass man von einem neuen Paradigma der Softwareentwicklung sprechen kann. Die Einführung von BDD ist entsprechend aufwendig.
Wir haben in der GI-Fachgruppe „Testen, Analyse und Verifikation von Software (TAV)” wiederholt festgestellt, dass die nachhaltige Einführung des BDD-Paradigmas in Softwareprojekten deutlich schwieriger als erwartet ist. In unserem Arbeitskreis haben wir die Probleme analysiert und diskutiert, insbesondere wie ein pragmatischer und gewinnbringender Einsatz der Methoden und Werkzeuge des BDD für den szenarienbasierten Softwaretest möglich ist, ohne gleich komplett ein neues Entwicklungsparadigma anwenden zu müssen.
Wir schlagen als Lösung Behavior-Driven Testing (BDT) vor, welches eine Teilmenge von BDD leichtgewichtig einsetzt und wichtige Vorteile von BDD beibehält: Testautomatisierung mit hoher Lesbarkeit und Wartbarkeit.
Behavior-Driven Development
In der Literatur wird BDD oft als erfolgreiche Methode geschildert, die eine Durchgängigkeit von der Spezifikation bis zum Test gewährleistet und das zu entwickelnde System durch eine ausführbare Spezifikation absichert. Dazu werden Anforderungen mithilfe von flachen Szenarien erfasst, die in der Regel der Struktur „Gegeben, Wenn, Dann” folgen. Die einzelnen Schritte der Szenarien beginnen jeweils mit einem Schlüsselwort, dem natürlichsprachlicher Text folgt.
Die Szenarien werden im Rahmen der Anforderungsermittlung erfasst, dienen als Grundlage für die Entwicklung und können unverändert mit einer Testautomatisierung hinterlegt werden, welche die erfolgreiche Umsetzung der Anforderungen nachweist. Dazu werden die einzelnen Szenarienschritte (Steps) werkzeuggestützt auf Schrittdefinitionen (StepDefinitions) abgebildet. In den StepDefinitions kann auf vorhandene Testautomatisierungsbibliotheken zurückgegriffen werden. Dieses Vorgehen von außen (Verhalten spezifiziert durch Szenarien) nach innen (Funktion realisiert als Code) wird auch als Outside-in-Development bezeichnet.
Somit deckt BDD Prozesse, Spezifikation und Testautomatisierung ab und scheint ideal für die Softwareentwicklung zu sein. Trotzdem ist es in der Regel nicht das Mittel der Wahl. Was sind also die Schwierigkeiten beim Einsatz von BDD?
Aus unseren Diskussionen im Arbeitskreis hat sich herauskristallisiert, dass die Einführung von BDD in den Softwareentwicklungsprozess sehr aufwendig ist:
- Diverse Teams haben vergeblich versucht, den gesamten Prozess auf BDD umzustellen. Insbesondere der Outside-in-Development-Prozess wird zu Beginn nur schwer verstanden und deshalb selten korrekt angewendet.
- Selbst die Teams, die BDD erfolgreich eingeführt haben, benötigten meist drei Jahre und mehr bis zum Break-Even, das heißt, bis BDD ausreichend durchdrungen und gewinnbringend wurde [Pie19, Adz11].
Diese Schwierigkeiten resultieren unserer Ansicht nach daraus, dass es sich bei BDD um ein neues Paradigma handelt, welches Requirements-Engineering, Softwareentwicklung und Testen integriert.
Behavior-Driven Testing
In unserem leichtgewichtigen Ansatz wird deshalb kein vollumfängliches BDD eingeführt, sondern die Software weiterhin auf Basis der vom Kunden gelieferten Spezifikation implementiert. Unserer Erfahrung nach sind Spezifikationen oft nicht einheitlich formuliert. Das ist aber die Grundvoraussetzung für den durchgängigen Einsatz von BDD, der streng formal beschriebene Anforderungen verlangt, um diese automatisieren zu können. Die verwendete Syntax unterscheidet sich in den verschiedenen Werkzeugen, orientiert sich aber oft sehr stark an der von Cucumber [Cucumber] verwendeten Sprache Gherkin.
BDD lässt sich oft nicht in allen Phasen der Softwareentwicklung einsetzen. Für die Phase der Testautomatisierung bietet BDD jedoch eine Reihe nützlicher Techniken und Methoden. Sie können eingesetzt werden, obwohl im Projekt kein vollständiges BDD etabliert ist.
Diese leichtgewichtige Anwendung von Methoden und Werkzeugen des BDD erfolgt in einigen Projekten in dieser Form bereits unbewusst und wird von uns als Behavior-Driven Testing (BDT) bezeichnet.
Der BDD- und BDT-Stack
Zur Abgrenzung von BDD und BDT erörtern wir in diesem Kapitel den in Abbildung 1 gezeigten, aus vier Ebenen bestehenden Methoden- und Technologie-Stack von BDD:
Die oberste Ebene bilden Prozesse. Diese nutzen agile Prinzipien und basieren auf dem Outside-in-Prozess.
Die zweite Ebene sind szenarienbasierte Spezifikationen, welche oft als Kern von BDD betrachtet werden. Dies sind ubiquitäre Verhaltensspezifikationen in einer formalen Domänensprache, für Requirements-Engineering, Softwareentwicklung und Testen gleichermaßen.
Die dritte Ebene ist die Szenarien-Implementierung, welche die Szenarien in Teststeps zerlegt. Die einzelnen Szenarienschritte werden werkzeuggestützt wie oben beschrieben auf Schrittdefinitionen abgebildet.
Die vierte Ebene ist das darunter liegende Tool zur Testautomatisierung, welches die Teststeps an die zu testende Implementierung bindet. Dieses Binding ermöglicht die automatisierte Testausführung.
BDD umfasst sowohl BDD-Management (obere zwei Ebenen) als auch die Testautomatisierung (untere zwei Ebenen). BDD-Management bringt als Nutzen Customer Facing und Ubiquitous Specification.
Abb. 1: BDD-Stack: Die vier Ebenen und die Bereiche Management, Testautomatisierung, BDT
BDT verzichtet auf den Outside-in-Development-Prozess: szenarienbasierte Spezifikationen sorgen für Lesbarkeit, die darunterliegende Testautomatisierung realisiert Executable Specifications, das heißt Living Documentation. Die Testautomatisierung ist State-of-the-art und sorgt für die Maintainability.
Obwohl BDT in der Community kontrovers diskutiert wird [Nor19], erreicht es vier von den sechs in Tabelle 1 aufgeführten Nutzen, ohne einen Paradigmenwechsel mit Prozessänderungen für alle Beteiligten vollziehen zu müssen.
BDT in Action
BDT ist eine Technik, die sich ohne größere Änderungen in den Softwareentwicklungsprozess integrieren lässt. In Abbildung 2 zeigen wir das beispielhaft anhand eines Buchungssystems für Kinos. Der Kunde arbeitet hier klassisch mit Use-Cases. In der Entwicklung werden daraus User-Storys abgeleitet, die die Basis für die Implementierung bilden. Die Tester schließlich leiten aus den Akzeptanzkriterien Szenarien für den Behavior-Driven Test (BD-Test) ab, die schließlich durch Step-Implementierungen automatisiert werden.
Abb. 2: Verschiedene Sichten auf Software
Jede Sicht auf die Software nutzt andere Techniken und erzeugt andere Artefakte. Obwohl es Brüche im Prozess gibt, ist der Schritt von einer Sicht zur nächsten klein und wird in der Regel gut verstanden. Durch dieses Vorgehen kann jede Gruppe zunächst an ihren gut erprobten Techniken festhalten, nur die Tester müssen sich auf ein neues Gebiet vorwagen.
Der Schulungsbedarf beschränkt sich bei der Einführung von BDT auf die Tester und lässt den restlichen Prozess zunächst unverändert. Durch geringere Kosten ist der Break-Even schneller zu erwarten, als wenn der gesamte Prozess umgestellt werden soll.
BD-Tests werden von allen Stakeholdern intuitiv verstanden, anders als andere Arten von automatisierten Tests, beispielsweise Klickprotokolle, Skripte oder Unittests, die oft nur von Testern und vielleicht noch von der Entwicklung, aber nicht vom Kunden verstanden werden und weiterer Dokumentation bedürfen. Bei den BD-Tests fungiert das Szenario als Dokumentation, es braucht nichts weiter für das Verständnis. So kann BDT den Weg hin zu BDD ebnen.
Fazit
In vielen Projekten gelingt es leider nicht, BDD mit seinem Paradigmenwechsel zu vollziehen, weswegen wir nicht erwarten, dass sich BDD als Managementmethode in nächster Zeit in der Breite durchsetzt. Allerdings lässt sich BDT für den Test und dessen Automatisierung mit hohem Nutzen einsetzen, insbesondere mit hoher Lesbarkeit und Wartbarkeit.
Mangels Outside-in-Development-Prozess beziehen sich die Szenarien bei BDT jedoch leider nicht direkt auf die Anforderungen, das heißt, es gibt Brüche in der Softwareentwicklung. Dadurch ist ein durchgängiges Testmanagement schwierig. Andere Verfahren müssen sicherstellen, dass die automatisierten Testfälle die Anforderungen korrekt, konsistent und vollständig widerspiegeln.
BDT kann den Weg für schrittweise Prozessveränderungen bis hin zu vollständigem BDD ebnen. So kann es gelingen, letztendlich doch BDD als übergreifende Methode zu etablieren.
Weitere Informationen
[Adz11] G. Adzic, Specification by Example: How Successful Teams Deliver the Right Software, Manning Publications Co., 2011
[Cucumber] Cucumber: BDD Testing & Collaboration Tools for Teams, siehe:
https://cucumber.io/
[Nor] D. North, BDD is not about Testing, Vortrag auf der Beauty in Code, 2019, siehe:
https://beautyincode.se/videos/
[Pie19] A. Pietschker, ATDD richtig – aus Fehlern lernen, Vortrag auf der 44. TAV, Stuttgart, November 2019, siehe:
https://fg-tav.gi.de/fileadmin/FG/TAV/44.TAV/GITAV44-Paper3.pdf
