QA vs. QE

Depending on where you go, software testers might be involved in Quality Assurance (QA) or Quality Engineering (QE). Each of these terms have been defined countless times, often in contradictory ways. They also tend to be used interchangeably to mean the same things.

But are they the same? If we look at the words that make up the terms, they would seem to indicate two different activities.

Quality Assurance to me implies the job of assuring that the software has some level of quality. This works great when the software is good - you can just say, "Yup, the software is good. I assure you." But what about when the software is not so good. How can you assure quality when there is none? What do you say then?
"This software stinks"?
"This software is buggier than a stagnant pond in July"?

True as these statements may be, it is not assuring anyone that it is quality software, which is what the term Quality Assurance is all about. That is why I don't like the term. To steal from the overused truism of why you should not assume, you should not assure, because it makes an ass out of you and R.E.

Quality Engineering on the other had seems to be more about a process for improving quality. Engineering is about designing and building things, so Quality Engineering should be about designing and building quality. The input could be of any level of quality, but after it goes through the QE process it should be of higher quality than when it came in. That means that in QE you not only find bugs in the product, but also in the process.

That all sounds great, especially if you are giving an talk at a software testing conference, but what does it really mean to people in the trenches. Whatever QE process your company uses, it could probably be improved. Unfortunately, we're usually too busy finding bugs, writing defect reports, and verifying fixes to have much time left for improving the process. You could move the world if you had a place to stand, right? But, how do you get to that place? My answer to that question is the same as my answer to "How do you eat an elephant?" One bite at a time. Every thing you can do to improve the process, no matter how small, should mean less bugs finding their way into test, which means more time for the Quality Engineer to make more improvements to the process.

In the end, I don't think it really pays to get all worked up about if you are doing QA, QE, or Testing. These are all just words. What matters is that you know what you are trying to accomplish and how to get there. Let people who spend more time with PowerPoint slides than bugs worry about the terminology.