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