QA vs. Testing - Part 4: Let's wrap this up.

If you've read the previous posts, you see where I stand on the topic. If you haven't read the previous posts, here's the summary:

QA isn't testing. Testing measures and provides information about the software, and quality assurance measures and provides information about the process.

Since we already have testers calling themselves QA, is it possible to have one person do both testing AND quality assurance?

Maybe.

Based on definitions alone, I'd say no. However, I would bet that most "QA" or "SQA" teams don't have an additional dedicated QA team. In fact, I'd bet that most test teams don't work with a separate dedicated qa team. If that's the case, who owns quality assurance?

I'll get to that in a moment, but first, let's remove a word and ask a similar question. Who owns quality?

Once upon a time, I'd ask this question, and most people would say that test owns quality. Now if I ask, most people say that everyone owns quality. But, if everyone owns quality, who's responsible for quality? Who gets fired or reprimanded for quality issues???

After letting the last question resonate in silence for a moment, I asi "who owns driving quality". The answer to this question is most often "test".

In the end, I guess it makes sense for test to own quality assurance, or at least some aspect of it. It's certainly not optimal, and I would expect senior testers to be the ones who drive quality assurance, rather than have it be a team effort - I'm much happier to see teams having someone own quality assurance whatever they decide to call themselves.