how to use automated tools and how to apply exploratory testing. We know how to analyze equivale nce partitions, state transitions, transactions, and input domains, then translate that analysis into effective and efficient manual and automated test cases. We can deconstruct a system and figure out where the bugs live. (These are skills a typical user does not have, which is why behavioral test teams that consist only of users, without any skilled and trained testers, tend to do a relatively poor job of finding bugs.) Good explanations of behavioral test techniques can be found in the classics Testing Computer Software by Cem Kaner, Jack Falk, and Hung Nguyen, and (the appropriately named) Black-Box Testing by Boris Beizer. The wise and battle-scarred test professional will have these—and many other—books on the desk, ready at hand. Testing as a skill, not just an activity, is finally coming into its own.
While I've discussed each of these techniques as separate, the reality is that sharing of data, cases, procedures, and tools is not just possible, but desirable. A test team that focuses on beha vioral testing can—and should—borrow structural test tools and data from the programmers—or vice versa. Test techniques are not—or at least should not be—religions, where one must chose one church or another. Test techniques are among the wrenches, screwdrivers, hammers, and other tools of the software professional. Pick the techniques that suit the tasks at hand. If you're a test manager, encourage cross-pollination, re-use, and sharing of techniques.
Automated Or Manual?
I've referred throughout this article to automated tools that can help us apply the various testing techniques. But how important is automation? Isn't manual testing still widely practiced, even by enlightened test groups? Are there circumstances where automation is downright dangerous and inappropriate? The answers are "very," "yes, indeed," and "certainly," as I'll explain in the next article.