Sometimes the right test to write is no test at all.

One of my features is clipboard support - cut-copy-paste for all of Sparkle. In my initial test case brainstorming session I came up with 450 test cases - and that was just for the mainline path! Adding in edge cases and the other conditions I ignored will easily push me over one thousand test cases.

Even if I had no other features to test and no other work to do, the chances are very low that I can complete that many test cases by the time they are needed. With some judicious triaging I trimmed my mainline tests in half. Oh boy - now I only have five hundred-ish test cases to write rather than a thousand-ish! That's eminently...

Not achievable either.

So what's a tester to do? My job, in perhaps the best way possible: by getting other people to do it.

Dev needs to write many of these tests anyway, to ensure their code is working correctly before they check it in. So I work with them as they write their unit tests. On the Test front, each tester knows best how their areas should respond to a cut/copy/paste. So I pair with them to write those test cases. Which leaves me maybe a few exit scenarios to write, plus of course general banging on clipboard stuff.

So it's not so much whether this tester has to test but rather how many other people this tester can con into helping get to help him! <g/>


*** Want a fun job on a great team? I need a tester! Interested? Let's talk: Michael dot J dot Hunter at microsoft dot com. Great coding skills required.