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:
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 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.
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?
In diesem Fall verlieren wir den wesentlichen Beitrag von BDD: die Fähigkeit, dass alle das gleiche Verständnis davon haben, was erwartet wird.
In diesem Fall gibt es Beispiele. Leider ist ihre Qualität oft unzureichend, da sie nicht von verschiedenen Profilen geprüft wurden.
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.
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.
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.
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.