Lessons Learned in Rapid Software Testing

Give a man a fish and he'll be fed that day. Give a man a fishing rod and he'll be fed for a lifetime.

On James Bach's Rapid Software Testing course, you are that man, but Bach is not tossing you a fish, nor even giving you a fishing rod, instead he's swinging open the doors of his huge angling arsenal, throwing his arms out wide, gesturing at you to take a good look at the contents and smiling broadly.

Inside there's stuff you recognise - poles, rods, nets, lines, hooks, waders, harpoons, reels, bait trays - and stuff you don't - crazy-looking doodads with springs and dials, big hairy ovals, bags of green seeds, assorted heavy machinery and wispy bits of fuzz. Some might have been used only once, some might be go-to tools for every day.

One wall is a posterboard covered with lists; lists of half-acronyms, lists of instructions and heuristics as long as your arm, lists of reminders, mindmaps with lists and sub-lists and sub-sub-lists bursting out of the centre like catfish whiskers. In the back there's a work bench, littered with the  tools used to make everything you can see and to the side of that a vast library of books on seemingly unrelated topics, each marked up for the nuggest of information that breaks open a new way of reeling one in.

You are stunned and bewildered but Bach is already started with the mantra pinned to the back of the door:

• You do not know all the answers
• You know there are many tools that could help you find them
• You do not know which is the right tool for any given context
• You have experience which helps you learn which to try and when
• You have experience, and the use of heuristics
• You have intuition, and you should codify it when you see it working
• You need to be self-aware, of your biases, that you don't know things
• You need to reason and you need to think laterally
• You need to be ready to try a different approach
• You need to think about risk and target your effort based on the perceived risk
• You need to refine your approach based on the evidence you've obtained
• You may have to test to find out what it is that you are testing (for)
• You need to be clear about your assumptions
• You need to ask questions
• You need to own whatever you create or use

It goes on, and he'll come back to it again and again, extending and refining it, but for now he's turned to pick up a piece of piscine technology, and polish it, and demonstrate it, and, a little misty-eyed, tell you how he used it to land a whale that time, and give you an example of the student in a previous class who used it in an exercise a whole different way, a way so imaginative that you wonder what kind of fish that student had been eating.

Then he'll point at you and ask you a seemingly simple question. And then you'll be doing that exercise and for the next fifteen minutes you might be a fish out of water, wriggling on the end of his hook. He'll gently lift you up and guide you into his keep net, trapped, circling, round and round and round. Until you're battered and then he'll review the whole thing, praising or constructively criticising before moving on.

For the rest of that day, you'll be thinking about the responses you could have given. How his set up and his line of questioning led you down a line of reasoning. How your instinctive answers were not the best answers. How your previous experience counted for nothing in the face of the interrogation. How daft you felt when it became obvious that there was another level of thought that could be applied, and one beyond that. Then, how good it felt to have that clarity of vision, even after the fact. How much you wanted to apply it to a new project right away. How you're already thinking about what you're going to need to stock your own shack with.
I attended the Rapid Software Testing course in Cambridge, March 7-9th 2012. There's a slideshow from it here.
Image: digitalart / FreeDigitalPhotos.net