BDD agile

BDD: VON DEN BESTEN PRAKTIKEN BIS ZU DEN IRRWEGEN

BDD (Behaviour Driven Development) ist eine Testmethode, die von Dan North im Jahr 2003 populär gemacht wurde und sich von TDD (Test Driven Development) ableitet, zu dem sie komplementär ist.

Warum BDD? Gerade um die üblichen Probleme mit Spezifikationen im agilen Modus zu lösen:

  • Keine formale 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 Testmethode, die darauf abzielt, die verschiedenen Akteure, die eine Funktion entwickeln, mit dem zu synchronisieren, was sie tun soll. Das Ziel von BDD ist es, Akzeptanztests zu entwerfen, die das Verhalten der Funktionalität veranschaulichen, wobei Methoden wie die 3 Amigos oder das Beispiel-Mapping zum Einsatz kommen. Der BDD-Ansatz wird im Allgemeinen in 3 Phasen durchgeführt: Entwurf, Formulierung und Automatisierung.

Die richtige Anwendung

Die Akteure werden mit Hilfe von gemeinsam entworfenen Beispielen, die das Verhalten der Funktionalität veranschaulichen, synchronisiert - dies ist die Entdeckung der USA, die oft durch das Treffen der 3 Amigos (Kunden-, Entwickler- und Tester) erreicht wird, was ein gemeinsames Verständnis des Bedarfs liefert und das Schreiben von Akzeptanzszenarien zur Validierung der Akzeptanzkriterien ermöglicht.

Diese Beispiele werden in einer gemeinsamen Sprache, Gherkin, formuliert, die von den verschiedenen Profilen der 3 Amigos leicht verstanden wird. Diese Gherkin-Sprache ist so formatiert, dass strukturierte Tests in einer natürlichen Sprache geschrieben werden können, die a priori von allen verstanden wird. Gherkin-Tests werden mit den 4 Grundelementen geschrieben: GIVEN / WHEN / THEN ... AND (GIVEN ein bestimmter Kontext, WHEN ich eine Aktion ausführe, THEN ich ein Ergebnis1 UND ein Ergebnis2 habe).

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

Die Tendenzen

BDD wird heute in vielen Unternehmen eingesetzt, um das Verhalten bestimmter Funktionalitäten in enger Zusammenarbeit mit den Benutzern zu testen. Aber auch wenn BDD eingesetzt wird, um ein gemeinsames Verständnis der Bedürfnisse zu erreichen, gibt es immer noch eine Reihe von Verwirrungen rund um diese agile Testmethode, die zu bestimmten Missbräuchen führen können. Worin bestehen diese?

BDD wird ausschließlich als Automatisierung gesehen

  • In diesem Fall geht der wesentliche Beitrag von BDD verloren: die Fähigkeit, dass alle Beteiligten das gleiche Verständnis von dem haben, was erwartet wird. 

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

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

Keine Abnahmeszenarien zu schreiben

  • Manchmal werden Synchronisationssitzungen abgehalten, aber am Ende wird kein Szenario erstellt. Dies ist insofern problematisch, als ein Großteil der Informationen verloren geht, weil sie vergessen werden. Außerdem sind dadurch mehr Personen gezwungen, an diesen Sitzungen teilzunehmen, was einen größeren Aufwand erfordert.

Die Tests sind nicht für alle Profile verständlich

  • Ein BDD-Test muss von allen Teammitgliedern (und manchmal auch darüber hinaus) verstanden werden. Das Schreiben von Tests, die nicht von allen verstanden werden, stellt nicht sicher, dass alle das Gleiche verstehen. Im Allgemeinen erlaubt es dem Unternehmen auch nicht, das zu entwickelnde Produkt wirklich zu validieren.

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 verpflichten musste, ein US zu liefern, das es möglicherweise nicht vollständig verstanden hat.

Verwendung von Gherkin als BDD

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

Vor dem Sprint besteht die BDD-Testmethode darin, durch Entdeckung ein gemeinsames Verständnis der Anforderungen durch alle beteiligten Akteure zu validieren. Dieses Verständnis wird in Form von Beispielen, Akzeptanzkriterien und Akzeptanzszenarien formuliert, die dann in einem Tool für die Erstellung und Ausführung automatisierter Tests umgesetzt werden.
Die Anwendung der verschiedenen Phasen dieses Ansatzes wird dazu beitragen, die BDD-Drift und vor allem die Verwirrung zu bekämpfen, die derzeit bei den verschiedenen Begriffen rund um das BDD-Konzept herrscht.

Über den Autor

image_processing20200928-5386-1elbc2o

Gilles Ménède ist ein Spezialist für Business Analyse und Requirements Engineering und arbeitet als Schulungsberater. Er bereitet Schulungsmaterial vor und bietet praktische Testschulungen an. Als Ausbilder seit über 10 Jahren sind seine Pädagogik und seine Fähigkeit, auf die Bedürfnisse einzugehen, unbestritten. 

Möchten Sie mehr über Testing erfahren?