Behavior Driven Development – Wenn alle die gleiche Sprache sprechen

Behavior Driven Development – Wenn alle die gleiche Sprache sprechen

Innovative Geschäftsmodelle basieren heute meist auf IT-Lösungen. Damit einher geht, dass die Softwareentwicklung und der Betrieb der Lösung die von den Geschäftsmodellen geforderte Agilität unterstützen müssen. Dies spiegelt sich unmittelbar in der Geschwindigkeit wider, in der neue Software ausgerollt wird. Statt weniger Releases pro Jahr, gehen die Anforderungen teilweise so weit, dass mehrmals am Tag ein neuer Softwarestand veröffentlicht werden soll. Um das zu gewährleisten und gleichzeitig die Qualität aufrecht zu erhalten, muss die Software kontinuierlich getestet werden. Dies erfordert eine kontinuierliche und unmissverständliche Kommunikation zwischen Domänenexperten, Entwicklern und Testern, die jedoch meist verschiedenen Sichtweisen auf die Lösung haben. Die Herausforderung ist es also, eine gemeinsame Sprache für alle Prozessbeteiligten zu finden – dies ist das Ziel von Behavior Driven Development (BDD).

Neben BDD ist auch Test Driven Development (TDD) weit verbreitet. Doch wo liegen die jeweiligen Stärken und Unterschiede der beiden Techniken?

TDD: Frühe Testfallentwicklung erhöht die Code-Qualität

TDD ist eine Methodik, die sich für das Erreichen einer hohen Testabdeckung bewährt hat. Eine hohe Testabdeckung wiederum bedeutet in der Regel, dass mehr Code automatisiert getestet wird. Der Grundgedanke von TDD lässt sich wie folgt zusammenfassen: Schreibe zuerst den Test, der initial fehlschlagen soll und entwickle danach den Code, mit dem der Test erfolgreich durchlaufen wird. Im Anschluss werden sowohl der Test als auch der Code überarbeitet.

Die Grafik zeigt den TDD Prozessablauf

TDD bringt folgende Vorteile:

  • frühe Erkennung und Vermeidung von Bugs
  • wenig Redundanzen im Code durch rechtzeitiges Überarbeiten (Refactoring)
  • saubere und erweiterbare Architektur/Code

Die Tests in TDD sind jedoch für viele Fachexperten (z. B. Product Owner, Business Analysten) nicht leicht zu verstehen, da sie in Programmiersprachen wie Ruby, Java, Python usw. geschrieben sind.

BDD: Wir beschreiben und prüfen das Verhalten eines Systems

BDD oder auch verhaltensgetriebene Softwareentwicklung ist eine auf den Grundprinzipien von Test Driven und Domain Driven Development aufsetzende Methodik.

Die Grafik zeigt den BDD Prozessablauf

Wie beim TDD, soll auch bei BDD der Test vor dem Code entwickelt werden. Doch soll dabei dann die Testfallbeschreibung nicht auf die Implementierung eines Systems fokussieren, sondern auf dessen gewünschtes Verhalten. Dahinter steht das BDD-Ziel, die Wirkung der Funktionalität zu prüfen. Mit anderen Worten: Wie soll sich das System abhängig von den Vorbedingungen und Aktionen des Nutzers verhalten?

Ein Verhaltensszenario wird vom Produkt Owner oder von den Business Analysten im agilen Team beschrieben. Es nutzt einfach lesbare Sätze in der Form „Angenommen-Wenn-Dann“, die sich auf User Stories beziehen (siehe folgendes Beispiel):

Die Grafik zeigt eine beispielhafte Step-Definition in Cucumber

Ein Szenario wird solange gemeinsam im Team überarbeitet, bis es für alle verständlich ist.

Ein Tester oder Entwickler überführt die Sätze in ein fehlschlagendes Szenario, wobei jeder Satz mit Programmcode verknüpft ist, um die Vorbedingungen oder Ergebnisse sicherzustellen. Auf diese Weise können Business Analysten, Product Owner und Stakeholder auch ohne technisches Code-Verständnis die Details der Tests verstehen und mit ihrem Wissen in den Entwicklungsprozess einbezogen werden. Die Entwickler ihrerseits verstehen, was das gewünschte Verhalten für das zu entwickelnde System ist. So soll BDD die Kommunikation zwischen den Domänenexperten und den Entwicklern und Testern erleichtern.

Analog zum TDD-Vorgehen wird das gewünschte Verhalten des Produkts dann implementiert, bis das Szenario erfolgreich durchlaufen wird.

Wie sehen die Testszenarien in BDD aus?

Grundsätzlich sind die zu erstellenden Szenarien in drei Teile gegliedert:

  • Angenommen (Given) – die Vorbedingungen für das Szenario

  • Wenn (When) – beschreibt die Aktion (z. B. ein Button wird geklickt, eine Adresse oder Ressource wird aufgerufen)

  • Dann (Then) – beschreibt das erwartete Ergebnis

Zusätzlich könnte auch das Schlüsselwort „Und“ (And) verwendet, um mehrere Vorbedingungen oder Ergebnissen zu verknüpfen.

Es gibt mehrere Tools und Frameworks, die für den Einsatz mit BDD geeignet sind. Eine Liste findet sich am Ende des Artikels. Eines der meist verbreiteten Tools ist Cucumber, das auf Gherkin basiert und ebenfalls zur Veranschaulichung im vorangegangen Beispiel verwendet wurde. Die Aufgabe des Testers ist es, zu jedem Satz die notwendigen Aktionen/Verifikationen zu erstellen und diese dann zu verknüpfen. Durch Wiederverwendung von Sätzen in zukünftigen Szenarien, können die Kosten für Wartung und Neuentwicklung weiterer Szenarien reduziert werden.

FAQ:

In welchen Fällen soll BDD verwendet werden?

  • Nutzt man bereits erfolgreich TDD, führt BDD zu keiner Effizienzverbesserung.
  • TDD eignet sich gut bei Projekten, in denen Product Owner, Business Analysten und Stakeholder ein gutes technisches Verständnis über die Unit-Tests haben. In allen anderen Fällen stellt BDD den besseren Ansatz dar, da die Formulierung der Test-Szenarien weniger technisch orientiert ist und dadurch ein breiteres Publikum erreicht wird.
  • Obwohl sich BDD für alle Ebenen der Testentwicklung eignet, passt es besonders gut für Akzeptanz-, Integrations-, End2End-Tests.

Besonderheiten bei der Nutzung von BDD?

  • Falls die Anforderungen nicht klar spezifiziert sind, kann auch BDD nicht effizient sein.
  • BDD ist bei „klassischen“ Wasserfall-Projekten nicht geeignet.
  • Tester, die BDD nutzen, müssen auch technische Fähigkeiten haben. In Unternehmen, in denen vorrangig „klassisch“ gearbeitet wird, haben Tester meist nur manuelle Tests durchgeführt. Dort ist der Sprung zu automatisierten Tests im BDD-Kontext eher schwierig. In solchen Fällen wird oft ein kostenpflichtiges Testautomatisierungstool herangezogen (z. B. Tosca).

Was sind die populären Frameworks/Tools beim Einsatz von BDD?

  • Open Source: Behat (PHP), Cucumber (Ruby, Java, JavaScript), FIT, FitNesse, HipTest, Jasmine (JavaScript), JBehave (Java), RSpec (Ruby), ScalaTest (Scala), Selenium (WebApplications), SpecFlow (.Net)
  • Kommerziell: Squish (Plattformübergreifend, speziell für GUI Tests), TestLeft, Tosca, HipTest

Mehr zum Thema

Können wir Sie unterstützen? Kontaktieren Sie unsere Experten!

Mit Q_PERIOR steht Ihnen ein starker Partner zur Seite.
Wir freuen uns auf Ihre Herausforderung!