Sunday, 9 August 2009

Behaviour Driven Development (BDD) and the Testing Profession

I posted earlier in the year about BDD. If you’ve not encountered BDD have a wander over to http://behaviour-driven.org/ and take a quick read or hit YouTube and watch Dave Astels (http://techblog.daveastels.com/) Google TechTalk http://www.youtube.com/watch?v=oOFfHzrIDPk. BDD isn’t some kind of Flavour of the Week new thing, it’s been around a good few years so hitting Google or Bing will turn up even more material.

I've read about approaches such as Agile Acceptance Testing (http://snipurl.com/pio2q) too and they offer good ideas about focusing on what’s important to the customer. What really struck home for me about BDD is the focus on Behaviour. As Michael Bolton said “... our clients don't value the code as such; they value the things the code does for them."

Behaviour Driven Testing (BDT)

There is a slight ‘gap’ in all this BDD goodness though and that’s the integration of the testing world’s perspective and practices. Especially those practices that could be applied, as is or modified, to fit alongside a team practicing BDD. AS much as I have the warm fuzzies for BDD it comes across as a far too developer centric perspective yet again. Maxim No. 27: ‘Software Development is more than just the writing of code’. What’s more, I’m a tester, as such it'd be odd to talk about me doing 'development' and having to say 'obviously I mean testing...' every time I mention the word development.

Hence why I don’t talk about BDD as such, I talk about Behaviour Driven Testing 'BDT', a methodology I developed to articulate how a test team could work in a BDD environment and consider what complimentary techniques/approaches might look like. If we’re enlightened enough to realise that ‘development’ is more than writing code and is all the tasks needed (BA, PM, Dev, Test, Support, ...) to get code out of the door then perhaps we could think just BDD but the world is a more fragmented and messy place so unfortunately we talk as if development just means writing code.

Replacing, renaming BDD?
I recently exchanged messages with David Chelimsky (http://www.davidchelimsky.net/) (and Bret Pettichord (http://www.pettichord.com/)) about BDT and a question that came why call BDD by the name BDT? A valid question where the short answer is “I’m not”. Just to be clear BDT is spawned from BDD and uses many BDD practices but the purpose, the objective is to deliver testing of the application code, not the development of the code. BDT sits next to BDD, I’m not renaming or replacing it, BDD is the wellspring that provides the framework and thinking for what BDT is.

When I read about BDD and then read the RSpec book (http://snipurl.com/pipiz) in a stroke I found the answer to many tester pains. BDD:BDT focuses testers back on Behaviour and away from the erroneous belief they are testing code (what do you think testers think they’re doing when they use Boundary Value Analysis?), it eliminates friction between developers and testers because, firstly we’re not testing code (directly) and secondly we both use Cucumber Features and now testers can write more tests (focused on Behaviour) that align with the work Development are doing, Cucumber is a catalyst to get customers, BA's and Test working together in ways they’ve been dreaming of and the first tool that allows Testers to help Developers increase velocity.

When testers then start writing edge and fail cases, end to end scenarios, etc. they like Developers can define those in Cucumber and implement them in the RSpec format. The RSpec approach ‘makes sense’ to testers as it reads so easily. If we’re not just doing manual testing combined with Selenium/Ruby it gives us a really accessible route into automation that focuses on Behaviour. With Selenium/Ruby we also get to use RSpec to structure our automation tests and kick-out neat reports too. Hang on, we’ve just found a way for Test to get really involved in (and in some aspects lead) the project, with all players, aligned with and supporting Development instead of clashing with them and we’ve got a kick-ass way to write automated tests that align with Development tests yet keep us focused on testing Behaviour not code. Is the paradigm shift this represents hitting home? ;)

With RSpec we have a way for testers to write scripted tests that mean something to them and that speaks to what they should focus on, Behaviour, not code. I suggest RSpec is as significant to the testing profession as Exploratory Testing (http://snipurl.com/pipjv). RSpec is the Aha! that smacks you in the face as hard as Exploratory Testing did and provides the paradigm shift in your tester thinking that both excites you about how you’ll work in the future and makes you lament for the pratting about you’ve been doing.

I could go on and on, point is all of the above is not (BD) development of application code. It’s an absolute focus on testing but testing with an equally militant focus on Behaviour. This is what BDT is about. It’s the testing methodology spawned from BDD that focuses testers back onto Behaviour and aligns them with the rest of the development effort. A BDD|BDT project helps testers fulfil roles the business hopes they will but until now didn’t have a way to do so. Are there other ways to approach the issue of development and test team integration, engagement of the customer by all teams in a way that appears congruent, enabling all stakeholders to contribute to each other’s success, etc? Maybe but I’ve yet to work with them.

A final thought, every time I present my BDT methodology to testers it’s great to see the impact of what it enables them to do sinks in. When customers hear about BDD:BDT, Cucumber and RSpec they ‘get it’.

Please email me for a copy of this presentation. I had to take it down as it was branded for another consultancy ;(

Mark.

4 comments: