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

Wed, 04 Jun 2003

Hiring

Laurent has a timely post about hiring. He compares the recruiting process to Big Up Front Design, where you have to get it right because there's resistance to changing the decision once the person is hired.

It's timely because I'm actually considering taking a Real Job. I wasn't looking for one, but it dropped in my lap, and there's a chance that I can do some spectacular work.

But I only want the job if I really can do spectacular work. I don't want to do just OK work. So I have proposed a "trial marriage" that I believe is essentially like Laurent's solution in his post. I'll work for a while as a non-employee, doing the kind of job we'd expect me to do as a full-time employee. After some period, we'll look at what I've accomplished and see if it looks like I can do the calibre of job we both want. If not, the company will be more likely to cut me loose than they would if they'd hired me. And I'll be more likely to cut myself loose. (My past two jobs have taught me that I stick with companies well after I should leave.)

We'll see if they go for it.

Because this is a note about hiring, and that's one of her schticks, I want to announce that I finally put Johanna Rothman on my blogroll. I wanted to do it in a way that returned the grief, but I haven't come up with a good one. So this will have to do.

## Posted at 16:03 in category /misc [permalink] [top]

The language of tests

Bob Dalgleish has comments on test planning as requirements specification. He comes at things from a different perspective than I do, but I was struck by a couple of his points.

The first is from his last paragraph:

In fact, the worst that can happen, substituting a Test Plan for a Requirements Document, is that the resulting product is over-specified, with too much detail and decisions made too early. A Test Plan or a Requirements Document needs to be at the correct level of abstraction, but it is much easier to do this with the [Requirements Document] than the [Test Plan].

(Here, "Test Plan" means a document that describes inputs and expected results, and also allocates effort among testing tasks.)

Testers have long been aware of a tension between abstraction and concreteness. Take GUI testing. Your tests have to be concrete enough to catch bugs, but somehow abstracted enough that they're not broken by irrelevant changes to the UI.

Now that testing is taking on a new role, that of helping people understand the problem to be solved, the tension recurs in a new and interesting way. We're now in the realm of the mathematician A.N. Whitehead's "Notation as a Tool of Thought":

By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race.

The quote reminds me of the GUI testing problem: the purpose of notation is to keep you from having to worry about irrelevant details. You worry about the advanced problem - such as ways to express the needs and wants of the users in a checkable way - not about whether the menu items stay in the same order. And by not thinking at all about menu items, you can pay more attention to the users.

And yet... In test-first design, we're sometimes after something more: notation that helps you discover details that turn out to be very relevant. Notation as a tool for provoking Eureka! moments.

It's my hunch that the community of people who care about test-driven design at the product level are soon going to zero in on notation. How do you write tests that harness insight-provoking concreteness without being so specific that they discourage useful exploration of options? And how do tests do that while satisfying all the other goals we heap on them? Like being resistant to GUI changes. Like being so easy to change that they do not slow down the project. Like finding bugs.

(I've written elsewhere on abstraction and concreteness in tests.)

The second point will come later.

## Posted at 14:26 in category /testing [permalink] [top]

Magritte on projects

A clever graphic from Frank Patrick (via Alan Francis).

## Posted at 13:37 in category /misc [permalink] [top]