QA is a misnomer

I’m not sure how the role of Quality Assurance got its name. It’s not right.

Many people seem to believe that QA’s job is to ensure that a product has high quality.
This is not their job at all, and it is easy to see if you think about it.
QA doesn’t change the product at all, there is no way anything they do can directly improve
the quality of the product. The only way to improve the quality of a piece of software is to change lines
of code to remove bugs and add features. QA doesn’t do that.

So what do they do? QA’s job is simple: they figure out what the software actually does. Developers
produce software, and they believe it will do X, Y, and Z. They’ve set out to write it so it does these
things. They worked hard to make it do these things. They believe it will do these things.

But does it?

That’s QA’s job: to figure out what the actual software actually does. Forget the designer’s ideal,
forget the fevered dreams of the developers. What does the software before us actually do? QA tests
the software to figure that out. No matter what sub-discipline of testing we’re talking about, the
purpose is the same: to figure out what the software does.

Of course, the whole point of figuring out what the software does is so that you can compare it to
the intention, measure the difference between theory and practice, and work to address the gap. That’s the
part where quality improves: the measuring of the gap, and the work to close it up.

Don’t get me wrong: I love QA. I think it is an important role. But you’re doing it wrong if you
think you are improving quality. It should be named Reality Check, or just Testing, or something like
that.

Comments

Why not just drop the touchy-feely, politically-correct style changes and go back to calling them Quality Control? Myself, I rather like the idea of builds getting a little virtual 'Passed by Inspector 22' sticker. I suppose the name might seem a little hash or totalitarian, but when it comes to lamps burning my house down and apps bringing my operating system down, I want someone to be harsh and totalitarian about quality.

Mmm... I think "assure" has additional meaning that "ensure" does not have. Namely to assure something is to state with confidence that that something is true. So in this case, a QA person does all the things they do so that they can assure, or state with confidence, that the software in question does in fact have quality.

Having said that, most of the people who I know that bill themselves as QA with the exception of this guy I know named Mike don't do anything that actually assures quality at all. They should have their department renamed to something like bicycle-shed-paint-color-debate-club or something.

Development is responsible for the quality of the product. QE (or QA) is responsible for providing development with sufficient data to assess the quality of the product. But ultimately, only development can "assure" the quality of the product.

To Bob from Microsoft:
That is interesting because I truly believe QA, QE, testers, etc really should be software engineers. The testers I find are the veteran software engineers that want to do something different and are good at finding and diagnosing problems. The key is diagnosing! Anyone can find a problem, but to have testers not only find them and have the ability to debug and pin point the problem is invaluable. Having the title Microsoft has implies these are in fact software engineers, or at least it sounds like it.

To Brian: I agree and that is why you are seeing test driven development becoming more popular. If I am writing Java in Eclipse for instance, the first thing I do is create a JUnit test to the interfaces and then I write the code. The JUnit test works the way I think the code should work.

I couldn't disagree more. If QA is done right, you will be effecting code. QA is a process and it should start before even the first design document is written. QA should be ensuring that coding standards are in place and are effective. QA should be ensuring that procedures such as change management are in place and documented. QA should be providing input on what the design documents contain and there format. QA must be involved in the product development from the very first meeting. The most effective place to catch bugs is in the design documents so you must ensure that they are well written and actually used. You must make it clear that the resulting product will be tested according to the design documents and if the product doesnt meet the design, it won't be passed by QA. If the code does not meet the coding standards, then it goes back to development. This is how QA effects the code and why it is called QA. If your QA department is not doing this, then it is broken.

Mike, you are clearly passionate about the process, and I applaud that. It looks a little heavy to my startup eyes, but if it works for you that's great. But read your own description again: QA is not improving the quality of the product: they are doing an awesome job letting people know how reality differs from plans and intention, and that is important, but it doesn't directly change the quality one iota. It's essential, but it is still indirect.

Ben Finney 9:10 PM on 28 Apr 2006

I don't see why "assurance" leads anyone to believe that the code, or its quality, are being changed at all. This is the primary difference between the older term "Quality Control", which implies having *direct control of* the quality (nope, thats what the coders do), and "Quality Assurance", which implies making some kind of *assurance about* the quality.

Consider the difference between "I control whether this button is pressed", and "I assure you the button was not pressed".

Add a comment:

Name:

Email:

Ignore this:

Leave this empty:

Web site:

Name is required. Either email or web are required.
Email won't be displayed and I won't spam you.
Your web site won't be indexed by search engines.