Are You in QA? No. Am I a So�ware Tester? Yes!
� � � � � � � � � � � � �have this question asked of me quite frequently.
Somehow I will be involved in a discussion and
something will come up about testing, and when I
talk about it, a natural question to be asked is “oh,
so you must be in Quality Assurance!” For years,
I answered “yes”, but I don’t answer that way any
longer. Now, when people comment that I must be
in QA, I answer, “Am I a software tester? Yes!”
For many of the people I talk to, the
comment doesn’t just hang in the air; they notice
the difference, and often they ask me about it? What
do I have against QA? Why do I avoid saying those
words, and why do I substitute the words “software
testing” instead?
The roots of this come from my
further understanding of the dynamics and the
created, and the environment in which it is built and
where it runs. The term Quality Assurance stems
from the idea that there should be quality standards.
software exists in an unusual state that is never
loaded with the same operating systems, and with
as close as possible the same hardware, and we
ran those two systems, with as close to identical
certainty, say that the machines would behave
identically. We could guarantee that the metal
parts were stamped out to make the case with a
high amount of precision, but the sustaining of
the electronic states of an operating system will
be different on each computer. The vagaries and
differences in the speed of ram, the speed of the
hard disk, the length of the cables used inside the
chassis, the power load at that given moment,
and any programs installed and activated on the
system will make for a different experience. This
is a key reason why I have come to view software
“quality assurance” as a misnomer. Metaphorically,
installing and testing software is less like building
a house on a concrete foundation, but more like
extend the metaphor, building it on the lake instead
The reasons run even deeper than this
however. With Quality Assurance, there is both
an expectation and an understanding that we can
what Assurance means. I assure that this product
has a level of quality. For most of us that work in
this space, that is not likely, nor is it really even
feasible. To assure software quality, we would need
to have the ability to make changes to the system,
to “retool the line” so to speak, so that we can make
sure that the system is doing exactly what it was
This also stems from the factories in which items
are made. Whether they are made of wood, plastic
or metal, factories have a vested interest in their
parts being designed to have few defects or broken
pieces. The idea of quality assurance grew out
of the factories and assembly lines looking to
guarantee, as much as possible, the parts that were
talking about a drill press, and the ability to make
for equally distributed holes into a piece of sheet
metal, having the ability to guarantee that process
works consistently is realistic. It’s a very stable
process, and something that can be assured (or as
The metaphor of a factory and an assembly
line feels natural when we talk about software.
Functions plug together, modules can be connected
to make larger programs, and numerous “moving
product. The similarity, however, ends here.
Unlike a drill press or a metal stamping machine,
� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ! � � � � � � � " � # � � � � � � � $ � � � � % & � � � � � � � ' � � # $ (� � � $ � � ) � � * � � � � % � � � � � � � � � + � � , � � � � � � � � � � � ) � � � � � � - � � � � � � � � � � � � � $ � � � # � � � � � � � � � � . # � � �/ 0 1 2 3 4 5 4 3 6 7 8 9 : ; 7 < 2 / 9 8 8 / 4 = 9 >
? @ ? A B C
BriefHistorY
OF
Time
a
FrenchEdition
least in the environments that I work in, we don’t
have that control or power. We have to have a
programmer make those changes. Thus, the ability
to assure quality is not in our hands.
The biggest reason, though, has nothing to
do with these situations I’ve described. The reason
I dislike using the term “Quality Assurance” the
most is the false expectation it gives. It tells people
that we can assure quality, in a way that says we
will prevent any defects from getting to the public.
While yes, that is ultimately what we want to do,
the fact is that it is impossible to test completely,
to examine every conceivable situation, and cover
every eventuality to assure that there are no defects.
If a defect does get out, we have set ourselves up
for blame. We are Quality Assurance, our job is to
assure the quality of the product, and therefore any
that particular issue, neither did the programmer
who wrote the module, or the product owner who
accepted the module. We’re all on the same team.
Setting ourselves up to be the judge, jury and
executioner will merely leave us to be blamed if we
miss something.
These are of course all semantic
arguments. The fact is, Quality Assurance is a
long established term, and for the most part it is
synonymous with being a tester. Still, I prefer
using the words “software tester” for a variety of
reasons. First, it accurately effects what we do.
We test the software. Not an idealized piece of
software on some mythical perfect machine, but
on a lake. We look at a product and we explore
it. We discover with the resources at our disposal
how the software behaves, and based on that
behaviour, we explore in different places. Jon Bach
has a metaphor that I personally love1, in essence
saying that instead of trying to present ourselves as
should use something closer to who and what we
really are. We are storytellers. We are journalists.
Our goal is to explore, study and learn about a
product, from as many different vantage points as
we can, and then, based on those vantage points,
explain what we see. Tell as complete a story as
possible. Show the software team and product
owners the who, what, where, when and why of the
software. We are providing the development and
product team, and the customers, with information
product team and the programmers will determine
what they will do with that information. Often it
will be to take the problems that we have found
leave the issues as is.
Each time I have this conversation, I have
the chance to change someone’s mind on how
they see software development and what we as
opinions; the long-term use of the QA term is
someone who gets what I’m saying, and they start
to view software testing differently. I’ve even heard
a number of software testers likewise answer in
kind when they are asked if they “work in QA?”
It’s going to take time to change perceptions, but if
we all work together and remind people what it is
we really do, we might help others understand that
the term Quality Assurance belongs in the factory,
while software testing belongs with the code we
work with every day. D E F E D E G H E I J
Visit www.qawizard.com to learn more and download your free 30-day trial today. Learn More
QA Wizard: Intelligent Tools for Testers
Automate your web, Windows, and Java testing, and gauge
the real-world performance of web sites with QA Wizard Pro.
Create adaptable scripts that require less maintenance with
an object-based recording engine and global control repository
Test the latest technologies including HTML 5, Java, .NET,
Qt, AJAX, and more
Simulate hundreds or even thousands of users to measure
the real-world performance of your web site
With Resource Thief you don't need to maintain virtual
machines, or create crazy configurations in the lab to test
application behavior in stressed environments.
Limit disk, memory, and network access to specific
applications
Run existing, or new test cases against the application
under test
Use your existing diagnostic, testing, and development
tools during stress tests
Resource Thief Stress Testing
QA Wizard Pro Automated Functional & Load Testing