Behavior driven development kann ein ein mächtiger Verbündeter im Softwarelebenszyklus sein, aber auch mächtig im Wege stehen. In diesem Talk werde ich auf die Quintessenz von BDD eingehen und eine Abgrenzung zu ähnlichen Konzepten wie TDD, ATDD oder auch SBE machen. Weiterhin werde ich einige Verhaltensweise aufzeigen, die einer gelungenen Umsetzung im Weg stehen und dafür sorgen, dass BDD seine Stärken nicht ausspielen kann. Gezielt werde ich auf drei Probleme eingehen, die mir in der Praxis begegnet sind. Ich werde berichten, was mir in der Vergangenheit geholfen hat, Teams wieder auf den rechten BDD Kurs zu bringen.

Zielpublikum: Tester, Entwickler, Product Owner, Projektleiter
Vorraussetzungen: Grundlegendes Verständnis von Softwareentwicklung
Schwierigkeitsgrad: Basic

Extended Abstract:
Behavior driven development kann ein ein mächtiger Verbündeter im Softwarelebenszyklus sein. Genauso gut kann es aber auch mächtig im Wege stehen und den Prozess verlangsamen, verkomplizieren und zum reinen Selbstzweck verkommen.

Im Rahmen dieses Talks werde ich auf die Quintessenz von BDD eingehen und eine Abgrenzung zu ähnlichen Konzepten wie Test Driven Development, Acceptance Test Driven Development oder auch Specification by Example machen. Unabhängig vom gewählten Softwareentwicklungsmodell, kann es gerade in agilen Umfeldern seine Stärken ausspielen. Weiterhin werde ich einige Verhaltensweise aufzeigen, die einer gelungenen Umsetzung mächtig im Weg stehen können und dafür sorgen, dass BDD seine Stärken nicht ausspielen kann. Gezielt werde ich auf drei Probleme eingehen, die mir in der Praxis bereits häufiger begegnet sind. Dem Reflex widersprechend, diese Probleme mittels Workarounds zu umschiffen, werde ich berichten, was mir in der Vergangenheit geholfen hat, Teams wieder auf den rechten BDD Kurs zu bringen, damit BDD nicht zu einem reinen Selbstzweck verkommt und das Team verlangsamt.