| testing.com > Testing Craft > Motivation |
In mature crafts like woodworking, medicine, and mathematics, practitioners are expected to have detailed shared understanding of specific techniques. Compare software testing books to woodworking books. Where is the equivalent to 100 Keys to Preventing and Fixing Woodworking Mistakes? The Band Saw Handbook? The Complete Guide to Sharpening? Amazon's first customer review of that last book begins, "Having read over a dozen books on this topic..." Stop for a moment and think about that. There are more than a dozen books on how to make woodworking tools sharp. They have illustrations, step-by-step instructions, discussions of specifics like "how to true and flatten the sole plate." We have almost nothing like that in testing. If woodworking books were written like testing books, they would read like this:
To carve a Santa Claus, take an appropriately sized piece of basswood. Using a saw, chisel, and detail knife, make the wood be shaped like a Santa Claus.
I'm exaggerating some. But not as much as I should be. This site is about providing specific techniques in sufficient detail.
I'm not a woodworker. (My father is.) The woodworking books I've seen show pictures of the work in progress. They teach techniques by telling a story that begins with the intent to create something, highlights the key steps, and ends with the finished product. I think that's a good way to teach. This site will encourage case studies, though it will by no means be restricted to them. Because there's no hope for any one person to create enough case studies to make a useful site, I will try to wheedle help from many people, including you.
I use the term "case study" carefully. My beloved wife is a professor of veterinary clinical medicine and a diplomate of the American College of Veterinary Internal Medicine. Doctors who want to join that college (which qualifies them for faculty or highly paid specialist positions) must, among other things, submit case studies. (They call them case reports.) A case report tells the story of an actual case, step by step, in great detail. Importantly, it's the whole story, mistakes and all. It includes the wrong diagnoses, incorrect treatments, and plain inefficiencies of the actual experience - together with a careful discussion of what should have been done differently at the time. It is only by seeing the whole, true story that the examiners can pass judgement. The stories on this site, intended to help practitioners, will help them most if they expose them to the true totality of the experience of using a technique, glitches and all. Prettified fictionalizations help only the egos of the writers.
A variant sort of prettified fictionalization applies a technique only to a toy example. When I try to apply those techniques, I almost always have problems understanding how they scale (even for those techniques that do scale). For that reason, we will prefer case studies applied to real software, not toy examples. We've selected some products that we encourage (but do not require) technique explainers to use. That way, readers can concentrate on the technique, not on figuring out the program being tested.
I don't pretend that everything worth knowing about testing techniques will appear on this site, so it will contain outward links to, and summaries of, techniques explained elsewhere.
As a testing consultant, I am often asked for templates for test plans, test reports, and the like. It would be convenient to redirect such questions to this site, so we will include such things here.
To learn well, you need to be presented an idea (a technique). You need to practice it. And you need to talk about it with other people in your community of practice. For that reason, almost all the pages on this site contain a forum for the discussion of techniques. One problem with testers is that discussions of technique tend to drift rapidly into talk about how misunderstood and underappreciated testers are, or into relatively abstract discussions of the role of testing, the meaning of quality, and so on. The only thing wrong with those discussions is that they seem to squeeze out the nitty gritty of techniques. Consequently, we'll try to squelch them on this site.
One of the reasons for those discussions is, I believe, that there does not yet exist a true community of software testers. We're defined negatively, in terms of what other people think of us, instead of in terms of what we know and can do. Some people want to create certification programs to give us more letters after our names and force others to respect us. I'm not opposed to certification in general. As far as I can tell, certification has been a force for good in veterinary medicine. It's led to better veterinarians. However, I believe that in the absence of true commonly accepted practice, certification can only be a tool to gain power - perhaps for testers as a whole, perhaps only for those who get to define for the community what it had better commonly accept. My hope is that this web site will help commonly accepted practice bubble up from below, from the practitioners, rather than be imposed from above by those big names who talk a lot about testing but don't actually do it. One final motivation for this web site is to force myself to get my hands dirty, keep myself from becoming one of the talking heads that I used to despise when I was a line tester.
I introduced this site in an editorial in Software Testing and Quality Engineering magazine. It goes into the need for large examples in some more detail, by contrasting learning testing to how I learned to program (by working on open source software, back before there was such a term).
Here are examples of concrete, applicable knowledge derived from experience. They're from fields somewhat related to software testing. If reading these things thrills you, you are exactly the sort of person I want to serve with these web pages.
Be the first person to add a comment in the
Wiki Forum at page TestingCraftMotivation.
(The Forum is explained in its FrontPage.)