The Business Story Method is supported by and largely documented in a book called "The Business Story Pocketbook" which is available for FREE DOWNLOAD or can be purchased from Gerrard Consulting (or other good booksellers).
Paul Gerrard's blog
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: http://gerrardconsulting.com/index.php?q=node/602
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.
Peter Farrell-Vinay posted the question “Does exploratory testing mean we've stopped caring about test coverage?”on LinkedIn here: http://www.linkedin.com/groupItem?view=&gid=690977&type=member&item=88040261&qid=75dd65c0-9736-4ac5-...
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.
When the testing versus checking debate started with Michael’s blog here http://www.developsense.com/blog/2009/08/testing-vs-checking/ 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.
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.
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.
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.
The nice folk at Aspire Systems asked me to contribute a talk to a webinar they are running on November 15. The webinar presents things to think about in migrating to SaaS. My contribution describes our journey from being a testing services company to offering services (and not just testing) through a Software as a Service (SaaS) model. We didn't start off as an ISV of course, but we encountered many of the challenges facing ISVs.