Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick
191.8 167.2 186.2 183.6 184.0 183.2 184.6

Tue, 10 May 2005

Fine-grained guidance in exploratory testing

I'm going to be hosting a couple of sessions at the AYE conference. I was tailoring my standard biographical blurb for it when a phrase leapt out at me:

[My] approach is evolving. Today, [I] emphasize [...] exploiting the similarities between exploratory testing and incremental design [...]

A lot of what I've been talking about is bringing the tools, attitudes, and biases of exploratory testing to bear on program and product design. But what about the reverse direction?

Consider: I make frequent use of a quote from Ron Jeffries:

Beck has those rules for properly-factored code: 1) runs all the tests, 2) contains no duplication, 3) expresses every idea you want to express, 4) minimal number of classes and methods. When you work with these rules, you pay attention only to micro-design matters.

When I used to watch Beck do this, I was sure he was really doing macro design "in his head" and just not talking about it, because you can see the design taking shape, but he never seems to be doing anything directed to the design. So I started trying it. What I experience is that I am never doing anything directed to macro design or architecture: just making small changes, removing duplication, improving the expressiveness of little patches of code. Yet the overall design of the system improves. I swear I'm not doing it.

-- Agile Alliance authors' mailing list, July 19, 2001

As I've since learned (and sometimes documented), such heuristics - interpreted with imagination and guided by analogies to past experience - really have a wonderful way of guiding the performance of design. They make it less likely that you'll go off into the weeds.

What fine-grained guiding heuristics are there for exploratory testing? I confess that I can't think of any. That alone doesn't mean much, since I don't claim to be a particularly good exploratory tester. But I also can't think of anything written that quite gets at what I'm looking for. Bach&Bach's session-based test management is something like it, since the short sessions force a pause for course correction. Bach, Kaner, and Bolton have written well on using risk to guide testing and on particular heuristics to use when strategizing where to test next. Elisabeth Hendrickson has some techniques particularly good at breaking people out of mental ruts.

But somehow, and it might just be me, these things seem on a larger scale than "eliminate duplication." While coding, I can use that heuristic to choose the very next thing I do, the next keyboard gesture I make. After a time, it becomes a perceptual thing as much as a cognitive one. (I think it's no accident that the phrase "code smells" is so popular. It helps toward the useful goal of removing right action from the realm of conscious decision to the realm of instant expert action.) I wonder what the equivalent in exploratory testing is, and has anyone written it down?

P.S. I learned about the book Sources of Power (the previous link goes to a review of it) from Rachel Davies.

P.P.S. Blogging is light because writing energy is going into Scripting for Testers. Today: Test::Unit.

## Posted at 09:28 in category /testing [permalink] [top]

About Brian Marick
I consult mainly on Agile software development, with a special focus on how testing fits in.

Contact me here: marick@exampler.com.




Agile Testing Directions
Tests and examples
Technology-facing programmer support
Business-facing team support
Business-facing product critiques
Technology-facing product critiques
Testers on agile projects

Permalink to this list


Working your way out of the automated GUI testing tarpit
  1. Three ways of writing the same test
  2. A test should deduce its setup path
  3. Convert the suite one failure at a time
  4. You should be able to get to any page in one step
  5. Extract fast tests about single pages
  6. Link checking without clicking on links
  7. Workflow tests remain GUI tests
Permalink to this list


Design-Driven Test-Driven Design
Creating a test
Making it (barely) run
Views and presenters appear
Hooking up the real GUI


Popular Articles
A roadmap for testing on an agile project: When consulting on testing in Agile projects, I like to call this plan "what I'm biased toward."

Tacit knowledge: Experts often have no theory of their work. They simply perform skillfully.

Process and personality: Every article on methodology implicitly begins "Let's talk about me."


Related Weblogs

Wayne Allen
James Bach
Laurent Bossavit
William Caputo
Mike Clark
Rachel Davies
Esther Derby
Michael Feathers
Developer Testing
Chad Fowler
Martin Fowler
Alan Francis
Elisabeth Hendrickson
Grig Gheorghiu
Andy Hunt
Ben Hyde
Ron Jeffries
Jonathan Kohl
Dave Liebreich
Jeff Patton
Bret Pettichord
Hiring Johanna Rothman
Managing Johanna Rothman
Kevin Rutherford
Christian Sepulveda
James Shore
Jeff Sutherland
Pragmatic Dave Thomas
Glenn Vanderburg
Greg Vaughn
Eugene Wallingford
Jim Weirich


Where to Find Me

Software Practice Advancement


All of 2006
All of 2005
All of 2004
All of 2003



Agile Alliance Logo