I had a few goals in this presentation. One I stated clearly – this presentation was primarily about the how of Test Design – not the what. This means that I didn’t share a big list of test design ideas – in fact, I don’t think I shared any unless they helped make a point.
Other points I left (purposely) up to the imagination. I have an inkling that some testers think that there’s a master list of test design ideas somewhere, and once they have the list, they’ll be up for any testing challenge.
This, of course, is a horribly broken idea.
First of all, Test Design ideas (I’ve explored, and continue to explore the pattern metaphor with these ideas) are endless. Like infinity, as many testing ideas as you can list, I can think of one more.
The bigger challenge is knowing when to use which testing idea – and to me, that’s the bigger challenge in test design. Let’s say that I’m an expert in Boundary Value Analysis. You can stop laughing now – all that means is that I’m a hotshot at finding boundary issues. The problem is that only a small (but significant) percentage of testing actually deals with boundaries. I may try testing boundaries in a lot of places, but most of the time that effort isn’t doing anything for me.
As a tester, you need to recognize the problem your facing, then pick the best test design ideas for that problem.
Here’s a real example. It’s no secret that I like model-based testing. Sometimes, testers will ask me “how would I use model-based testing in this scenario?”. That’s a nice question, but it’s the wrong question. To be a good test designer, you need to look at the problem first (I need to test this application), analyze how the program works, then pick the best approaches. If you start with the approach and try to make it work, you’re probably going to fail. With this example, a tester with MBT in their “tester toolbox” may recognize a portion of the application that 1)behaves like a finite state machine, and 2) recognizes risk in traversing that state machine. Then they apply the technique.
The point is that to be a good test designer (and tester), you need a lot of testing ideas, and you need to know how and when to apply them.
And that’s really, really hard – and as you know, that’s also why it’s really, really fun.