BDD: von den Best Practices bis zu den Abweichungen

BDD (Behaviour Driven Development) ist eine von Dan North im Jahr 2003 populär gemachte Praxis, die von TDD (Test Driven Development) abgeleitet ist und dieses ergänzt.

Warum BDD verwenden? Genau, um die üblichen Probleme mit Spezifikationen im Agile-Modus anzugehen:

Keine formelle Erklärung des Kontexts,
Spezifikationen, die von verschiedenen Profilen oder Akteuren unterschiedlich interpretiert werden können,
Nicht unbedingt auf dem neuesten Stand.

BDD ist daher eine Agile-Praxis, die darauf abzielt, die verschiedenen Akteure, die eine Funktion entwickeln, mit dem zu synchronisieren, was sie tun soll. Das Ziel von BDD besteht darin, Abnahmetests zu entwerfen, die das Verhalten der Funktionalität veranschaulichen, und dabei Methoden wie die 3 Amigos oder Beispielmapping zu verwenden. Der BDD-Ansatz wird im Allgemeinen in 3 Phasen durchgeführt: Entdeckung, Formulierung und Automatisierung.

Die richtige Anwendung

Die Akteure werden mithilfe gemeinsam entwickelter Beispiele synchronisiert, die das Verhalten der Funktionalität veranschaulichen: Dies ist die Entdeckung der USA, die häufig dank des Zusammentreffens der 3 Amigos (Kunden-, Entwickler- und Testerprofile) erreicht wird, wodurch ein gemeinsames Verständnis des Bedarfs entsteht und das Schreiben von Akzeptanzszenarien zur Validierung der Akzeptanzkriterien ermöglicht wird.

Diese Beispiele werden mithilfe einer gemeinsamen Sprache, Gherkin, formuliert, die von den verschiedenen Profilen der 3 Amigos leicht verstanden wird. Die Gherkin-Sprache ist so gestaltet, dass strukturierte Tests in einer natürlichen Sprache verfasst werden können, die von vornherein für alle verständlich ist. Gherkin-Tests werden mit den 4 Grundelementen geschrieben: GEGEBEN / WENN / DANN … UND (UNTER EINEM GEGEBENEN Kontext habe ich, WENN ich eine Aktion ausführe, ein Ergebnis1 UND ein Ergebnis2).

Ausgehend von dieser strukturierten (und formatierten) Formulierung des Verhaltens der Funktionalität ist es möglich, diese Beispiele in ein Softwaretool wie beispielsweise Cucumber zu integrieren, welches diese Gherkin-Sprache interpretiert, um automatisierte Akzeptanztests auszuführen, die an diese Beispiele angepasst sind. Dies ist die Automatisierungsphase.

Die Abweichungen

BDD wird heute in vielen Unternehmen verwendet, um das Verhalten bestimmter Funktionen in enger Zusammenarbeit mit den Benutzern zu testen. Aber selbst, wenn BDD verwendet wird, um ein gemeinsames Verständnis der Anforderungen zu erreichen, gibt es immer noch eine Reihe von Verwirrungen rund um diese agile Praxis, die zu bestimmten Missbräuchen führen können. Welche sind das?

BDD wird ausschließlich als Automatisierung betrachtet

In diesem Fall verlieren wir den wesentlichen Beitrag von BDD: die Fähigkeit, dass alle das gleiche Verständnis davon haben, was erwartet wird.

Szenarien werden ausschließlich vom PO oder Tester geschrieben und entworfen.

In diesem Fall gibt es Beispiele. Leider ist ihre Qualität oft unzureichend, da sie nicht von verschiedenen Profilen geprüft wurden.

Versäumnis, Akzeptanzszenarien zu schreiben

Manchmal werden Synchronisierungsmeetings abgehalten, aber am Ende entsteht kein Szenario. Dies ist insofern problematisch, als dass viele Informationen verloren gehen, weil sie vergessen werden. Es zwingt auch mehr Personen, an diesen Meetings teilzunehmen, was eine größere Investition erfordert.

Tests, die nicht für alle Profile verständlich sind

Ein BDD-Test muss von jedem im Team (und manchmal auch darüber hinaus) verstanden werden. Das Schreiben von Tests, die nicht von allen verstanden werden, stellt nicht sicher, dass alle dasselbe verstehen. Im Allgemeinen ermöglicht es dem Unternehmen auch nicht, wirklich zu validieren, was entwickelt wird.

Das BDD wird während des Sprints erstellt

Während eines Sprints bedeutet nicht während der Entwicklung. Aber selbst, wenn BDD vor der Entwicklung durchgeführt wird, hat dieser Prozess Auswirkungen auf das Team, das sich dazu verpflichten musste, ein US zu liefern, das es möglicherweise nicht vollständig verstanden hat.

Gherkin als BDD verwenden

Gherkin ist eine Sprache. BDD kann andere Formen annehmen … genauso wie es möglich ist, Tests in Gherkin auszuführen, die keine BDD sind (z. B.: Das Karaté-Tool bietet Tests in Gherkin, die von Funktionsprofilen nicht verstanden werden können).

Vor dem Sprint besteht die BDD-Praxis darin, durch Entdeckung ein gemeinsames Verständnis der Anforderung durch alle beteiligten Spieler zu validieren. Dieses Verständnis wird durch Beispiele, Akzeptanzkriterien und Akzeptanzszenarien formuliert, die dann in einem Tool für die Entwicklung und Durchführung automatisierter Tests implementiert werden.

Die Anwendung der verschiedenen Phasen dieses Ansatzes hilft dabei, BDD-Drift und vor allem die derzeit herrschende Verwirrung über die verschiedenen Begriffe rund um das BDD-Konzept zu bekämpfen.

Gilles Ménède

Bleiben Sie informiert! Verpassen Sie keine News und Updates mehr.

Holen Sie sich exklusive Insights, Tipps und Know-how rund um Qualitätssicherung direkt in Ihr Postfach.

Diesen Artikel teilen