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:

Parimala Hariprasad said...

I read through the presentation on BDT at http://www.cyreath.co.uk/papers/Cyreath_An_Introduction_to_BDT.pdf. A big thanks to you, Mark. I am delighted to have gone through BDT. I have been doing BDT in the name of functional and system testing all my life!

Recently during my performance appraisal session, I was told by my manager as follows: "A lot of developers have provided feedback that you need to improve in terms of gaining in depth technical knowledge of the product. I am really happy with the testing you have been doing so far. However, in order to earn respect from developers, you need to work on your technical skills".

I was offended to a certain extent. Am I expected to learn the code now? After calming down, I started looking at it from a different perspective (I realised after further discussion with the manager that the developers expected me to point to the exact line of code due to which the defect was born! WOW! So I not only test, but also go code hunting as a part of my full time job). If I understand the code, it would become more easier for me to trap lot more defects at the code level. However, Testing at the code level is only an add-on and not a replacement to behavioral testing which lot of developers fail to realise. It becomes difficult if testing at the code level is forced to replace behavioral testing because at the end of the day, customer is
interested in the behavior of the system and not the code. Like you said 'Every bug we raise as testers should be described in terms of BEHAVIOUR'. I would love to find/report a bug in terms of the behavior, not in terms of telling where the if loop failed in the code though I do believe that this information does help the developer to fix the issue faster. Behavioral testing again has strings attached to the emotions of the user. A user might use a product differently under the influence of different emotions hence resulting in different behaviors of the system.

Nice Presentation Mark - Good Learning for me,

Parimala Shankaraiah
http://curioustester.blogspot.com

Mark Crowther said...

Thanks for the feedback Pari, I appreciate you taking the time to read the material and comment.

It's such a balancing act in QA/test sometimes, needing to be technical enough to earn the respect of development while being empathetic enough with the customer/user to make sure someone is looking after thier needs while making sure the business we work for is considered - phew! :)

Let's face it too, there's no other role like ours is there?

"I am delighted to have gone through BDT. I have been doing BDT in the name of functional and system testing all my life!"

Pari, exactly. I think at heart most testers have, I know I have too. Thank you for letting me know I'm not alone in this!

Mark.

Unknown said...

Blogs are so informative where we get lots of information on any topic. Nice job keep it up!!
_____________________________

Dissertation Methodology

Christopher York said...

Hi Mark, I tried the link to the BDT presentation but it no longer works - would you be able to give me a new link that works. - Chris