Testing Lessons From My Kitchen
In my kitchen I have a mandoline. No, it’s not a musical instrument (that’s a mandolin), but instead a fancy food slicer that can thinly cut or dice just about anything. Anything, that is, including my fingers.
You see, I am extremely clumsy with my mandoline. Every time I’ve used it, I have somehow sliced open one of my fingers. My mandoline is literally covered in knives – there are knives for slicing, knives for dicing, and even more knives stored underneath and inside the thing for torturing vegetables in additional ruthless and unimaginable ways. The whole thing is one big vegetable and finger slicing machine.
The crazy thing about my mandoline is that despite the fact that it cuts me every time I even look at it, it’s not actually broken. In fact, it’s in great shape. All of its knives are sharp, its frame is sturdy, and it slices and dices just like one would expect. I’m sure there is some kind of spec somewhere that says “verify mandoline can smoothly cut onions exactly .125 inches (3.17 mm) thick.” I’m sure mine passes with flying colors. What the spec probably doesn’t say is “verify mandoline won’t cut fingers.”
Specs can’t capture these sorts of negative tests very well. You can write them, but a spec like that is a lot like a spec that says “make sure your software doesn’t crash.” It’s very nice to include, but also kind of worthless. This is where good testers can really show their worth. A tester can think beyond the spec and relay feedback that can be just as valuable as any bug or error.
What are some of the evil mandolines in your projects? If you relayed them to your developers or product managers, do you think you could make your software better?
