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

Thu, 17 Apr 2003

The mechanical act of coding

In the latest installment of Dave and Andy's interview, Andy says:

As an anecdote, on one project Dave and I were implementing legal requirements in code. These were actual laws that had been passed. We got about three quarters the way through it and realized that the law as stated was wrong. It was inconsistent. If you read through the law one way, it said something had to happen. But in the next paragraph it contradicted itself. Nobody had caught it up to that point, because nobody had tried to do a detailed implementation enacting this legal requirement. This mere mechanical act of coding actually catches bugs in the real world.

This is also something we testers say: the mechanical act of being specific about inputs and expected results makes you think about the requirements in a different way. Things jump out at you. The effect is especially noticeable when you're doing exploratory testing, usually a tactile act of interacting with something semi-physical.

I've also found that the same is true of writing user documentation. If you're trying to do it well, you constantly feel obliged to explain why the product makes sense. Sometimes you realize it doesn't... But even without Eureka moments, the focus on "why" gives you yet another perspective.

The art of it all is to marshal lots of perspectives to give you a rich picture of what you're after. Perhaps ironically, the perspective I've always found least illuminating is the conventional rigorous-natural-language-with-lots-of-section-headers-and-traceability requirements document. But perhaps I've never seen them done well.

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