Dear Readers,
I've come to realise that many developers see BDD with Cucumber solely as a means to achieve an automated testing framework. Sure, the advantages in this regard are clear. Automated testing frees testers from the burden of regression testing and allows them to focus on exploratory testing. It also helps to facilitate a Continuous Delivery model with features being pushed out rapidly and over all functionality being guarded by the automated testing suite. Sounds great.
However, this particular drive for adopting BDD presents the danger of misinterpreting its original intention.Lets start with a definition of BDD:
"Behaviour Driven development is about implementing an application by describing its behaviour from the perspective of its stakeholder"The primary issue that BDD was created to address is poor communication between primary stakeholders and developers. It is influenced by the idea that creating a conversational, common language between developers and stakeholders and using this language to specify requirements is the best way of developing the right product.
Developing automated tests based on this conversational set of specifications is a secondary concern of BDD.
Unfortunately, the drive to create a replacement for regression testing suites has blinded many developers, myself included, from the original purpose of BDD.
The result is a view that does not consider primary stakeholders. Since the automated tests simply replace regression tests, only developers and testers need to be able to understand their descriptions in the Cucumber Scenario files. The original purpose of Behaviour Driven Development, as stated in its very name, is lost.
My team at work has suffered from this very issue. Development had a particular understanding of a feature we were writing, our Business Analyst had another. It was only during a review of our feature files that we realised that our view of the product had diverged. If the very first thing we had done was to define a common language between us and to define the behaviour of the product as a result, these divergences would have been addressed in step 1.
So what's my solution? Firstly, read up on your BDD theory. Writing up notes on this lecture by Gordon Force was a great start for me.
Before starting the development of a feature: Start with your product's stakeholders.
- Define who your stakeholders are
- Define the interests of your stakeholders
- Defined a common language between you and your stakeholders that you can use to write a set of requirements
- Using this, figure out a template for your Feature files and Scenarios
- Figure out your development process around BDD. Write your scenarios and decide their priority. Have developers pull these scenarios in priority order to develop and your managers/BA decide which of these scenarios comprise your minimally viable product. Feed this into your sprint planning
My team have recently implemented this approach and so far it is working out quite well! I first performed the above analysis for a feature we planned to develop. The following sprint was spent fleshing out a complete set of Scenario descriptions. This gave us a granular set of sub-features that we could sensibly pick and choose from for the planning of the next sprint.
Although BDD recommends an outside-in approach, a decision to develop the automated tests in parallel to the code was made for the sake of getting the work done efficiently. I haven't decided how cynical I should be to this approach, but in any case, since both the developers of the functionality and the developer of the automated tests were working directly from the Scenario descriptions, they ended up marrying quite happily.
My take on all of this is that yes indeed Automated Regression suites are important and that BDD is a great way of achieving them. However, testing coverage should come as a result of requirement definitions that can be communicated easily with stakeholders, so always start with those!
Shrek
