There’s a well-known saying: “Those who can, do. Those who can’t, teach.” (George Bernard Shaw)
I tend to live by another saying, one that I just made up now: “Those who can, create. Those who can’t, analyze.”
I’ve always been drawn to writing (never the other way around), and I think I’m pretty good at it. I’ve also always been drawn to programming, and I’m not terrible at it. But where I’ve always seemed to excel is in analysis of other people’s creations: editing works of writing and testing software. Perhaps it’s my detail-obsessiveness and general anal-retentiveness; perhaps it’s my aversion to decision-making and attraction to questioning. I’m not sure. What I do know is that the sibling activities of editing and proofreading can be a useful analogy for testing and checking.
The standard definition of editing makes it out to be very similar to (and inclusive of) proofreading, but in my life it has been more helpful to define them as distinct activities. Proofreading is a low-level task — a hunt for misspellings, grammatical mistakes, punctuation problems, usage issues, and so on. This is the last thing you do to a piece of writing before it is sent off to its final audience. Before proofreading comes one or several rounds of what I personally define as editing. Editing is concerned primarily with high-level issues: structure, point of view, theme, audience, and so on. I usually think of proofreading as a “corrective” activity, wherein I make changes directly; but editing is more of a discussion with the author, during which I might make suggestions (“this paragraph might work better at the beginning”) and ask questions (“was it your intent to convey this message here?”). The goal in proofreading is to fix mistakes; the goal in editing is to help the author work their way to a better version of the piece.
Perhaps you can already see how being familiar with this distinction might help me organize my thoughts about testing and checking. Here are the definitions of testing and checking suggested by James Bach and Michael Bolton:
Testing is the process of evaluating a product by learning about it through experimentation, which includes to some degree: questioning, study, modeling, observation and inference.
Checking is the process of making evaluations by applying algorithmic decision rules to specific observations of a product.
The end result of testing and editing is very similar, and may include a report of issues of concern to stakeholders, as well as questions and observations that may lead to the author or developer re-working part of the artifact in a significant way. Likewise, the basis for both checking and proofreading is algorithmic decision rules: Does clicking this button result in that outcome? Is this clause punctuated with that mark?
There are a lot of differences between these pairs of activities, of course, but one of the more glaring, and useful, is that editing and proofreading are typically separate activities, with proofreading intentionally coming later — there’s not much point in proofreading a piece of writing if the process of editing may yet result in significant rewriting. This is different than a software project, in which (1) the reverse is often true, in that a lack of early low level checking can result in broken software that isn’t worth testing yet, and (2) “testing” under the Bach/Bolton definition is a general term that includes checking.
The benefit of this analogy is some extra structure to my thinking whenever I try to distinguish amongst these activities as I do them. For example, when I first started testing several years ago, my experience giving feedback to other writers helped in finding an appropriate tone for bug reports. And now that I have more experience testing, the worlds often channel advice between each other.
What about you? What analogies do you use to make sense of your own testing world?