3 Advantages of Behaviour Driven Development

Last night I attended a talk held by the PMI Sydney Chapter Meetup Group, on the topic of Behaviour Driven Development (or BDD), given by John Smart, the author of BDD in Action.  

Previously, BDD was something that I'd heard about, but never really looked in.  I had a feeling that it was similar to Test Driven Development (mainly based on the similar names), and there are some, mainly that both emphasise automated testing (see point 3, below).  However, with BDD the emphasis is on the way the team works and thinks as a whole, rather than just being a methodology for developers.  

Below, I've selected the three main advantages that I see in adopting BDD, and why many more teams and workplaces should consider this methodology.

1. Collaborate Early

BDD emphasises collaboration.  Rather than working in isolation, with the business analyst defining the requirements, the developer reading them to implement, then the tester creating test cases and running them, the business analyst, developer and tester (the "3 amigos" of BDD) should sit down and work together, early on during requirements definition or user story writing.

Together, they should work to understand what is wanted by the business.  This ensures that everyone is on the same page, rather than questions coming up later (such as during development) and then needing to be discussed.  This also allows the developer and tester to have input, to bring up different scenarios and considerations - often quite valuable!  The end aim is to come up with concrete examples of the requirements (acceptance criteria), that are testable.

2. Truly Understand the Business Need

Often, most of the people working on a feature don't really understand why they're doing it.  Usually the business analyst will, and possibly the project manager and a lead developer.  But what about everyone else?

As part of BDD, the goal is described for each feature, and is shared with everyone.  This means that rather just focusing on the details (which may have been supplied by the customer, and may not be the best way to implement a feature), everyone can also focus on what is really being achieving for the customer.  More people can have input into reaching the customer's goal, including more quickly (we can add this to this little known feature that already exists...) or better (such as with the latest UX technology that the customer may not be aware of).  And it's more satisfying for everyone if they know the real purpose of their job.

3. Set Up for Success

Often in software development teams, there's a underlying battle between developers and testers.  Testers are out to find as many bugs as possible in the code delivered by developers, and sometimes a backwards and forth battle developers as bugs are fixed (or not fixed).  This is not a positive situation for the team, and can waste a lot of time.

BDD gets around this by making the passing of automated acceptance tests part of code delivery.  These are developed by both the developer and tester following the "3 amigos" sessions, and prior to code being delivered, these must be completed and all must be passing successfully.  This means everyone knows already that all of the most essential test cases are already passing, setting up testing for success rather than rejection.  This means the time then spent by in manual testing can be reduced, with the tester only running a few key test cases, plus usability testing and exploratory testing.

(Like the photo above?  Check out Unsplash.com for more beautiful license-free photos.)