A while back, I wrote a post on breaking code, in which I suggested that testers don’t add value to a project; they merely defend the value that’s there. This isn’t a general systems law, but any general utterance should have a couple of specific exceptions or alternative views. So, with the passage of time, here are a couple.
First, a while ago, I was chatting with James Bach, and we realized that testers sometimes can add value by recognizing new ways of using the product, or proposing refinements to what’s already there. Two wonderful examples were Quarterdeck’s products Manifest (which allowed you to inspect the state of the system) and Optimize (which placed programs in memory so that they occupied the minimum amount of memory available to the operating system. Yes, that used to be important.) Testing—in an exploratory way—revealed plenty of circumstances in which these products could be improved, or could be used in novel ways. That information triggered decisions and development work that added value.
In another case, I was on a documentation project for a network analysis program that had been purchased by a software publisher. Since the existing documentation was so shoddy and out of sync with the version that I had been asked to document, and since the third party’s developers were no longer available, my principal source of information was the product itself. I had to test it in an exploratory way, and in so doing, I identified a number of ways in which I could find (and document) ways of using the product that neither the developers nor the marketers had recognized. That information pointed to marketing opportunities that added value.
In these two examples, testers don’t add value, but they shine light on places where value might be added.
Another way of thinking about testers adding value is that the product isn’t just the running code. Indeed, as Cem Kaner points out, a computer program is not merely “a set of instructions that can be run on a computer.” That’s too limited. Instead, he says, a computer program is “a communication among several people and computers, distributed over distance and time, that contains instructions that can be run on a computer.” I love this definition, because if we honour it, it takes us way beyond questions of mere correctness, and straight to questions about value.
Does the program help the user to produce or accomplish something of value? Does the program include anything that would threaten the production or accomplishment of that value?
The system we’re testing is not merely the code or the binaries; the system is the sum of that stuff plus everything we know about it; how it can be used, how it can work, how it might not work. When testers add to the store of knowledge about the system, then testers indeed add value. That might not be easy to quantify, but there are lots of things in the world that we value in qualitative ways.
Don’t believe me? Think of a manager that you’ve liked working for, a teacher that inspired you, a friend that you’ve treasured, and think on how little mere numbers would tell you about how and why they were valuable.
Want to know more? Learn about Rapid Software Testing classes here.