In the previous article I claimed that we can prove our worth using methods of
evaluation, pulled from the liberal arts, instead of quantification. So
instead of proving the ROI of your test process if 30% over six months,
you might, for example, demonstrate that it is in the best interest of
the business and help make you piles of money. (Preferably, big piles of
money.) I'll give an example of the kind of thinking I am describing.
Say, for example, your CEO calls you into his office and wants to know
the ROI of testing. You get the feeling he wants some kind of proof, and
you know from other examples that this might be the kind of question executives like to ask right before the hammer falls. Based on my information, you are skeptical of coming up with a
number.
Now the cheapest way to decrease the cost of testing, after all, is to
not do it at all - to fire all the testers.
So try this thought experiment -- what would happen if we fire all the
testers?
I've found this thought experiment can go one of two ways. On the one
hand, it is possible that your testers aren't providing much value, that
the developers, Analysts, and customer service people are picking up
the slack. At one organization I did see two entire teams eliminated in
reorganizations without a great deal of pain to anyone.
But if you're reading this blog, I'd say you actually care about your
job and doing it well. It's likely that eliminating testing would cause
serious pain across the organization. Management, for example, wouldn't
know the real status of the projects -- they wouldn't know if the
software was in a shippable state. It's likely the company would lose
reputation in the marketplace, and, with that, customers and revenue.
Or, if we shift the testing burden to the developers, we'll end up
having someone doing the same work who is paid more, a poor economic
argument. If the developers are spending that much time testing, they'll
have less time to write new code, which means slower new product
development.
Walk through this discussion with an executive, and you quickly realize
the company needs testing. The question shifts from "should we be doing
testing?" to "should we be doing more or less testing?", and that is a
much more healthy question. Likewise, you can have similar discussions
about computer programs that help test the application automatically.
Specifically, test automation can make it possible for the team to
shrink the size of a regression test cycle, and if the business
considers quick build/release cycles a business advantage.
Another way to do this if the value of the test team is questioned is to
offer to take a few weeks of unpaid time off. If you are providing
value, the other members of the technical staff and business people will
connect the dots themselves. The conversation will shift from "is the
test group providing value?" to "since the testers are providing value,
how can we help them provide the most value?"
And that, my friends, is a much nicer place to be.
The technique I used to do this, by the way, is a logic technique - one
of the seven liberal arts - called reducing to the absurd. The basic
idea is that you start with an assumption counter to the position you
are really advocating, and work backwords until you reach a
contradiction.
The day I met him, my collegue, Mike Kelly said something that made a
lasting impression. While I don't remember the exact words, it boiled
down to something like this "If you need me to come in as a consultant
and help you find ROI numbers for your project, you're in trouble before
you start. A good project doesn't have ROI numbers, it has executives
that say 'we would be idiots to turn down an opportunity like this.'"
I think Mike and I would agree that ROI numbers do have a place, but the
spirit of the argument is that humans are good at evaluation, so we
should let them evaluate.
Yes, physics envy is strong. Yes, we may be swimming uphill. But I
submit that this extensive focus on quantity, analysis and method both
wastes time and leaves us prey to charlatans, promising some wonderful
formulaic approach, then walking away with our time and money.
It's two thousand ten, not seventeen fifty. It's time we stopped falling
for mechanical turks that pretend to play chess. It's time we admit
that the vending machine has a person behind it, filling the order. Or,
to use the language of Dr. Kaner, it's it time we admit that a computer
program is just a mechanism for humans to communicate, distributed
across space and time?
Determining if that conversation is 'good enough' sure sounds like a job
for quality, not quantity. At least it does to me.
The good news is that right now -- here -- today -- after the phenomenal
success of Apple Computer Corporation, a company that describes itself
as the intersection of technology and the liberal arts - we may have
finally reached a point in time where the software Quality profession is
ready to talk about, well ... Quality.
It's an exciting time to work in software testing.
Let's go change the world.