Saturday 22 April 2006 — This is 17 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.
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.
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.
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.
Consider the difference between "I control whether this button is pressed", and "I assure you the button was not pressed".
Add a comment: