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.
Michael,
I think it is great the way you analyze your use of vocabulary to understand its implications.
In these two examples, testers don’t add value, but they shine light on places where value might be added.
Would you agree to my assumption that testers add value “to the team”, by “shining light on places where value might be added”. I usually argue with a lot of people about their testing practices and their relationship with the project team. A lot of the time I would express my doubts that they are adding value to the team, and hence their dissatisfaction. Many times I would suggest that they need to consider the context in which they are working and really analyze how they can serve the expectations of the team. For example, if the tester is able to identify critical problems in an unreasonable deadline (set by management) and as a result convinces management to reconsider shipping, I would assume the tester added value to the management by helping them make the right decision at that time. But I totally understand your point when you say that the tester simply defended the assumed value of the product.
In another example, I had once identified a number of security vulnerabilities that were taken very seriously by the project lead. However it was apparent that this was a system wide problem and would take time to resolve. Although no attempts were made to fix the issue immediately, the project lead made it a point to remind everyone quite frequently that they will need to schedule the fix very soon, before anyone else figures out the vulnerability. So although my shining light did not actually add value to the product (yet), it probably did set the wheels in motion. Nevertheless I would assume that the project lead did experience the added value. What are your thoughts on this?
Would you agree to my assumption that testers add value “to the team”, by “shining light on places where value might be added”.
Yes, if we look expansively—not narrowly—at what it means to add value, then you're right. Remember the context of the original post. The point was that testers bring dollars in (which is what people often mean when they're talking about "adding value"), testers mostly defend the value that's there. That's a worthwhile activity, not a worthless one. In one narrow sense, building inspectors add no value to a building, but they help to defend the value of the value that's there. Yet in an alternative frame of reference—one in which we consider the value as "the building PLUS all the information we have on it", there's more information and thus more value there. You've provided a couple of excellent examples of adding value in this more inclusive way. So thanks!
—Michael B.
If quality is part of the requirements, it should be explicit in the cost, and clients have to pay for it. Of course, quality is not only guaranteed by testers, but depending on how a company value its products, testers have their weight “monetary speaking”.