Let's take a break
from diving into rounding errors and take a larger scoped view of the testing
role. After all, computing a basic
statistic - such as the average - of a set of numbers is a well understood
problem in the statistical world. How
much value can testers add to this operation?
Fair question. Let me try to
answer it with an analogy.
I used to repeat the
mantra I heard from many engineers in the software world that "testing is
insurance." This lead to the
question ," How much insurance do you want or need for your project?"
and that lead to discussions about the relative amount of funding a test
organization should have. The logic was
that if your project as a million dollar project, you would want to devote some
percentage of that million into testing as insurance that the project would
succeed.
The first analogy I
want to draw is that insurance is a not a guarantee - or even influencer - of
success. Just because I have car
insurance does not mean I won't get into a wreck. Likewise, buying vacation insurance does not
guarantee the weather will allow my flight to travel to the destination. Insurance only helps when things go
wrong. The software engineering world
has a process for that circumstance called "Root Cause
Analysis." I'll go over that later,
but for now, think of it as the inspection team looking at the wreck trying to
figure out what happened to cause the crash.
That leads me to my
second analogy: Testing is like
defensive driving. Defensive driving
does not prevent the possibility of a crash.
Instead, it lessens the chance that you will get into an accident. Hard stats are difficult to find, but most
insurance companies in the USA will give you a 10% reduction in your premiums
if you take such a class. Other estimate
range to up to a 50% decrease in the likelihood of a wreck, so I will use any
number you want between 10% and 50%.
How those results
are achieved are by teaching drivers to focus on the entire transportation
system around them. It is pretty easy to
get locked into only looking in one direction and then being surprised by
events that happen in another are (see where this analogy is going?). If I am concentrating on the road directly in
front of me, I may not notice a group of high speed drivers coming up behind me
until it is they are very close.
Likewise, if I am only concentrated on accurate computing an average, I
may not notice that my code is not performant and may not work on a server that
is in use by many people. In both cases,
having a wider view will make my driving - or code development - much smoother.
More on this coming
up.
Questions, comments, concerns and criticisms always welcome,
John
No comments:
Post a Comment