Paul Gerrard

First published 13/07/2011

It seems to me that, to date, perceptions of exploration in communities that don't practice it have always been that it is appropriate only for document- and planning-free contexts. It's not been helped by the emphasis that is placed on these contexts by the folk who practice and advocate exploration. Needless to say, the certification schemes have made the same assumption and promote the same misconception.

But I'm sure that things will change soon. Agile is mainstream and a generation of developers, product owners and testers who might have known no other approach are influencing at a more senior level. Story-based approaches to define requirements or to test existing requirements 'by example' and drive acceptance (as well as being a source of tests for developers) are gaining followers steadily. The whole notion of story telling/writing and exampling is to ask and answer 'what if' questions of requirements, of systems, of thinking.

There's always been an appetite for less test documentation but rarely the trust – at least in testers (and managers) brought up in process and standards-based environments. I think the structured story formats that are gaining popularity in Agile environments are attracting stakeholders, users, business analysts, developers – and testers. Stories are not new – users normally tell stories to communicate their initial views on requirements to business analysts. Business analysts have always known the value of stories in eliciting, confirming and challenging the thinking around requirements.

The 'just-enough' formality of business stories provides an ideal communication medium between users/business analysts and testers. Business analysts and users understand stories in business language. The structure of scenarios (given/when/then etc.) maps directly to the (pre-conditions/steps/post-conditions) view of a formal test case. But this format also provides a concise way of capturing exploratory tests.

The conciseness and universality of stories might provide the 'just enough' documentation that allows folk who need documentation to explore with confidence.

I'll introduce some ideas for exploratory test capture in my next post.

Tags: #exploratorytesting #businessstories #BusinessStoryManager

Paul Gerrard My linkedin profile is here My Mastodon Account