Behaviour Driven Development... the wrong or the right way?
I'm sure if you do a bit of 'googling' (did I type it correctly? ... well it's only a few years term anyway....) you will find a few interesting BDD links among which a wikipedia one! However, the real question is what are the main concepts you need to understand in order to do BDD properly? How can BDD help any software development team to deliver the right thing and at the same time keep a good track of the features delivered? These and even more questions often arise when people want to get started with BDD.
The most common mistake I've seen is 'use the tool as a starting point'.
It doesn't take much time or effort to understand that this is a bad idea. I've worked in a project where team members (even stakeholders!) used to refer to our automated features as 'BDDs'. It soon became evident that for anyone involved in this project the term 'BDD' was just another name for some ... automated scripts and these not even written in proper domain language. I've been involved in another team where they thought they were doing BDD by... writing feature files as automated tests at the end! And when I say 'end' I even mean next sprint or ... even very late in the release timescale; late within the sprint was the 'best case scenario'.
That's obviously the wrong way to go about Behaviour Driven Development.
What's the best way? Well... instead of starting off the tool, let's start by the actual meaning of BDD. In a nutshell, it means that:
we let our code be driven by the desired business behaviours.
The key to achieve this is to understand what the business value of each feature or story is (it rings a bell to all agilists, right? business value drives the definiton of done!) In order to do that there is only one key: collaboration. More precisely 'effective collaboration'. And effective collaboration can often happen when there is a tangible output steming from the continuous collaboration between BAs, POs, Developers and Testers. This 'output' can be a 'specification document'. Why is that different to a requirements document then?
My response would be threefold: - You can't 'execute' a requirements document,whereas a specification document which is written in a BDD tool which provides automation hooks can! - It's better if you 'specify' a scenario that can be automated using tangible examples - Specification is a wrapper around to a requirements document making it the living documentation of the product.
When I started my career as a software tester (in a V-model project) there was always a question or more of a riddle puzzling my mind: why should requirements gathering, development and testing be so related but yet so kept apart due to the processes? Wouldn't be better if we could bridge the communication gaps (to use Gojko's term) by bringing these expertise & processes closer?
Well, that's do-able thanks to Behavior Driven Development. You might have already noticed that I haven't still mentioned Cucumber, Behat, JBehave or any other BDD tool. The reason is that I view these tools are essential facilitators of a process that needs to be embraced by a team before these tools can be of any use in a project. Otherwise, there is a big chance that they will be just used as integration test tools or even automated testing tools written in a non-dynamic, one-sided way. BDD is first a process, second a tool...comments powered by Disqus