QA is a misnomer

Saturday 22 April 2006 — This is over 18 years old. Be careful.

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

scott lewis 7:06 PM on 22 Apr 2006

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.

will 7:20 PM on 22 Apr 2006

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.

/will

Bob 9:37 PM on 22 Apr 2006

At Microsoft it's called Test not QA. The job title is Software Design Engineer in Test (SDET) -- as opposed the job title for a developer which is Software Design Engineer (SDE).

brian 12:33 AM on 23 Apr 2006

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.

Bob Balfe 9:12 AM on 23 Apr 2006

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.

Jim 3:14 PM on 23 Apr 2006

"Quality Assurance" rings just as false to my ears as "Software Engineer."

Here's what various members of a development group know about a software product at any given time:

Product Manager: The product doesn't do what the competition's product does.

Tester: The product doesn't do what the user stories describe.

Tech Support: The product doesn't do what the customer wants it to do.

Feature Lead: When the other members of the feature team check in their code, I only have a couple of nights to refactor it all.

Developer: All the obvious defects are fixed in my checked-out version. I'll check it in when (and if) test finds them.

Development Manager: The product ship date. The phone number for the pizza delivery place.

Bob 7:10 PM on 23 Apr 2006

I'd be perfectly happy if the job titles were just "Coder" and "Tester".

Mike 9:13 AM on 26 Apr 2006

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.

Ned Batchelder 9:49 AM on 26 Apr 2006

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".

QA is a misnomer

Comments

Add a comment: