Thu, 11 Mar 2004
Very tangentially, I'm reminded of those who claim that the failure of Lisp and Smalltalk was partly due to their being hermetic - taking all data on their own terms, not the world's. They failed to embrace the string and the regular expression.
(Not just to pick on Lisp and Smalltalk, two fine languages: how long did it take for a regex class to make it into Java? And a regex class is one significant affordance notch below regexps built into the language.)
Despite tending to agree with Carlos, I gotta say: it's just so much finer to define functions on the fly in Lisp than in Ruby. For that particular (but important!) purpose, having the parse tree as a first-class data type is just a total win. Within programs, strings are a second-class way to represent code.
Two related ideas:
The common thread is quickly instrumenting your program, running a
lot of ready-to-hand examples through it, getting some
output that's not too noisy, and deriving value from that. Not a new
idea: how long have profilers been around?
But now that
"listening to what the code is trying to tell us" is marginally
more respectable (I blithely assert), we should expand the range of
conversation. It shouldn't be only about the code's static nature,
but also about its dynamic nature. And perceiving the dynamic nature
should be as simple, as semi-automatic, even as rawly perceptual as, say, noticing
duplication between two
I don't like the word "test" in "unit test" or "customer test". It leads to endless repetition of sentences like "But don't forget that unit tests aren't really about testing, they're about design." The listener is perfectly justified in asking, "Then why not pick a name that doesn't mislead?" To which, the only real answer is historical accident.
I haven't been enormously comfortable with my use of the phrase "exploratory testing" either. Exploratory testing has historically been a fast and flexible and creative way of finding bugs that matter. My goal for it (in Agile projects) is different. It's to expand the range of possible future stories from which the business expert will choose. Some of those stories might be bug fixes like "make it such that the operating system doesn't crash when you lay a manual on the keyboard and the keys repeat more than about 100 times"1. But I'm much more interested in stories that are feature requests, ones that suggest adding positive business value rather than removing negative business value.
For a time, I was calling that "exploratory learning" to emphasize that it will use some of the techniques of exploratory testing while still being a different sort of thing. But the name didn't catch on, so I reverted to "exploratory testing." But I'm still unhappy about it.
In the Agile Testing mailing list, Randy MacDonald wrote:
Don't build a system where exploratory testing is possible. Do build a system where exploratory design is possible. In fact, build the system via exploratory design.
I'm thinking that "exploratory design", perhaps with another adjective tacked on front, is more what I'm looking for. So, if I start using that, this will remind me to give Randy credit for the term.
1 Not apocryphal. I actually crashed Gould's real-time OS that way sometime in the 80's.