Paul Gerrard's blog

How BDD can fit the corporate culture

Last Friday, I was happy to present to the Skillsmatter Agile Testing and BDD Exchange at 'The Crypt'. Thanks to Gojko Adzic for inviting me and chairing the day.

You can see the video of my talk here. Afraid Skillsmatter don't allow embedding the video.

Future of Testing

In London, on 18 May I presented a keynote to the Testing and Finance conference. I've been asked for the slides of that talk, so I have uploaded them here. The talk was mostly based on two articles that I originally wrote for Atlassian, and you can find the text of those articles in the blog here:

Requirements-Driven Story Development and Requirements Validation

In this approach, the technique involves taking a requirement and identifying the feature(s) it describes. For each feature, a story summary and a series of scenarios are created and these are used to feedback examples to stakeholders. In a very crude way, you could regard the walkthrough of scenarios and examples as a ‘paper-based’ unit or component test of each feature.

Freedom, Responsibility and the Tester's Choice

Peter Farrell-Vinay posted the question “Does exploratory testing mean we've stopped caring about test coverage?”on LinkedIn here:

I've replied on that forum, but I wanted to restructure some of the various thoughts expressed there to make a different case.

Do exploratory testers care about coverage? If they don't think and care about coverage, they absolutely should.

Should Most of What we Call Testing Really be Called Checking?

When the testing versus checking debate started with Michael’s blog here I read the posts and decided it wasn’t worth getting into. It seemed to be a debate amongst the followers of the blog and the school rather than a more widespread unsettling of the status quo.

The higher the quality, the less effective we are at testing

Its been interesting to me to watch over the last 10 or maybe 15 years the debate over whether exploratory or scripted testing is more effective. There's no doubt that one can explore more of a product in the time it takes for someone to follow a script. But then again - how much time exploratory testers lose spent bumbling around lost, aimlessly going over the same ground many times, hitting dead ends (because they have little or no domain or product knowledge to start with). Compare that with a tester who has lived with the product requirements as they have evolved over time.

The Value and Significance of Tests

At Eurostar 2010 in Copenhagen, the organisers asked me to do a brief video blog, and I was pleased to oblige. I had presented a track talk on test axioms in the morning and I had mentioned a couple of ideas in the talk. these were the "quantum theory of testing" and "testing relativity".

The video goes into a little more detail.

Evolution of tools for Requirements and Behavior Driven Development

Some time ago, Tim Cuthbertson blogged "how I Replaced Cucumber With 65 Lines of Python." I recently commented on the post and I've expanded on those comments a little here.

I share Tim's frustrations with Cucumber. I think the reuse aspect of the step definitions has some value, but that value is limited. I've heard of several sites having literally thousands of feature files and step definitions and no way to manage them systematically. A bit of a nightmare perhaps.