at the agile testing
exchange 2010, Dan North defined BDD as "A second generation, outside-in, pull based, multiple stakeholder, multiple scale, high automation, agile methodology" (
see this great video). So part of BDD has to do with test-first ideas of TDD, but it also has a lot to do with focusing on delivering business value, recognising explicitly who the stakeholders are and what needs to be delivered to them and working outside in (from system outputs to inputs) in order to design the right system. It also focuses a lot on communication, finding the right ubiquitous language etc from domain driven design.
My understanding of FDD is that it organises work according to business feature slices and focuses on a highly iterative delivery process for those features. (I don't claim to be an expert on FDD, so this might be completely wrong). In that view, BDD inherits a lot from FDD but takes that further by emphasising high automation on validation as well as communication with business users and modelling the right system with examples. So, to conclude, BDD is in my view a mix of good ideas from FDD, TDD and also DDD. This is where the "second-generation" part of Dan's definition comes in. It's a collection of ideas that have worked well in different contexts, taken from 10 or so years of experience the community now has with various agile techniques and methods.
--
Gojko Adzic
http://gojko.net @gojkoadzic +447765132680