It's tempting to use BDD as a way to describe and run acceptance tests on the UI. Our experience has shown, that BDD is more beneficial, when used in earlier testing stages instead.

Target Audience: Test managers, testers, developers, ... so for the whole team
Preriquisites: Knowledge in BDD advantageous, but not mandatory
Level: Basic

Extended Abstract:

BDD is well established way to provide abstract description of expected system behaviors to developers. But, due to years of siloed mindsets, BDD is often described as the next big thing to describe and automate testcases for QA teams. This talk gives a small insight, in why using BDD in later testing stages (System-Integration and Acceptance Testing) could create additional overheads and more complicated test automation setups. You will learn how BDD can be beneficial when used correctly, but also how it can disrupt team velocity if introduced at the wrong places.