Testers have a story. We may tell a story of a hero who saved a release, or it may be a routine story of what we do day to day. The story involves the kind of information we gather, the way we gather it, whom we tell, and what decisions are impacted by it.
The story testers tell is important, but it is not the only one; programmers, managers, and executives have their own stories. It’s when those differ from the story we are trying to tell that we get in trouble.
Two years ago at STARWEST, Michael Kelly gave a keynote, What Executives Value in Testing. He talked about an interview for a chief testing role in a large international organization. The candidate spent a great deal of time talking to the senior executive team about office locations, wages, outsourcing, vendor management, and organizational structure. You can think of all of that as the form of testing—the outer appearance. Finally, the candidate grew frustrated and asked what the testing group did for the company, as activities should dictate structure.
The senior management did not know how to answer.
Let’s pause for a moment and think about that.
Thinking of testing as that thing we have to do to get to production or a box to check can get you in a heap of trouble. If you never examine the contents of the box and only look at the outside, then all you care about is the number of hours and hourly rate.
If you don’t care what people are doing, it’s easy enough to pay a tenth of the price, and you won’t even realize what you are losing! Hours billed is another subtle trap, as junior testers can finish quickly and not delay a project—because they didn’t find the bugs.
This kind of goal displacement does happen. A few years ago, a chief test officer for a major bank told me, “All the C-levels care about is numbers. When they see a development project costs thirty thousand dollars and testing only costs one hundred fifty, they are happy.”
Really?
What could that team that costs one hundred fifty dollars possibly be doing? Could they even be testing the software? When I pushed my colleague on what management got for that sum, he said all they had time for was usability testing. Given they only had time for one cycle, presumably after coding, I imagine the testing did not lead to any substantive changes.
Recognize that if all we measure testing by are cost indicators, we will end up making decisions that decrease the value. Once we’ve done that, we find we are not getting enough value from testing, and we get more decisions to cut corners; it is a death cycle.
Find out the story your executives have for testing, and then discover your own story. How do you add value?
