The difference is that QA is process oriented and QC is product oriented.
Testing, therefore is product oriented and thus is in the QC domain. Testing for quality isn’t assuring quality, it’s controlling it.
- Quality Assurance makes sure you are doing the right things, the right way.
- Quality Control makes sure the results of what you’ve done are what you expected.
Why all the fuss?
There are lots of reasons to ensure the distinction between the two. Easily, the ones that come to mind are:
- You’ll need to know the difference for CMM or ISO-9000
- You don’t want to prove you don’t do QA by calling the QC testing you do ‘QA’
- If you really want to scale your development process you’ll need the real QA and you won’t want to confuse it with QC.
The QA team’s job is to see that standards, processes, and policies (or other governing/guiding “writ”) are in place and carried out; to recommend and implement improvements to them, and to ensure that the people that need to know about them know about them. QA “audits” or “reviews” are intended to determine the efficacy of these “writs.”
It’s often easier to understand QA by an example: In one place (a large company with large projects) I’ve seen QA’s role to help project managers plan their projects — so that the projects follow certain organizational procedures; so that they include the required artifacts, events, and milestones; and so that the projects know what is expected of them and when in terms of reports, reviews, and documentation. As the project progressed, QA would conduct “checkpoints” along the way to see where the project may be developing risks, for example either by progressing beyond where they’ve got authorization to go, or where they may have need to escalate issues to management. These checkpoints would also be an opportunity to ensure that people who need to be involved are involved at the right times. This approach to QA isn’t one that really suits XP, but there are easily ways to adapt such an approach to XP.
Maybe mix-ups like this are happening because ambiguous terms have been given specific meanings.
Why would “assurance” mean process-related and “control” mean product-related?
One way to avoid confusion is to use more descriptive names: “Product-QC” and “Process-QA”.
I have always found the term “Quality Assurance” a curious choice. Why would we want to be assured about quality (made to feel better about it) rather than have quality ensured (guaranteed)?
These terms have been defined for us. While it may be ‘more right’ to redefine them so they’re no longer ‘degeneralized,’ we ought to at least try to ensure everyone has their terms straight when using them.
We may also look at the other areas in which these terms are used. ‘Control’ is often a term used with statistics, and processes that can be “controlled” with applying the analysis of the statistics. ‘Control’ is also an active term and has a certain circumstantial connotation. The need to test (“control”) is a function of the circumstance of the existence of bugs or lack of confidence. Whereas ‘assurance’ is a passive term with a more universal connotation. The need to “assure” is a function of building confidence regardless of the existence of bugs and isn’t just about bugs, but of the entire effort.
The difference between QA and QC is largely one of power and control. QC is usually as service provided to development (i.e. under the control of development) and is responsible for providing that service. QA expects development to provide services to it (control development) and is not responsible for any result.
Anyone care to explain this one? What is the purpose of QA if it does not deal with development? I’m afraid “QA as described here” leaves a lot to the imagination.
So, define it already. It is not enough to say QAisnotQC, you need to also say what QA is. Also, is there really some deep distinction between the two, or is this just some nit-picking intended to preserve a QA role when none is needed?
I have to agree with the prior comment that the terms are very confusing. Even though they are commonly used, I think we’d be much better off if they were not. Part of the problem is that these terms were taken from manufacturing paradigms. QA dealt with manufacturing processes, while QC inspected the manufacturing output to verify that it was acceptable. In the manufacturing environment you analyze, design, and implement once and then crank out many essentially identical products. This is very different from the software environment where the analysis, design, and implementation happen on each product, and then you start over for the next iteration.
In a software environment, “Quality Assurance” does not assure quality. Rather, they assure that a process is being followed, which is very different. The process, if it’s a good process, will increase the probability that there is a quality result. It will, presumably, make sure that requirements are communicated, traced, planned for, scheduled, etc. The “Quality Assurance” role will likely also collect metrics that it can then use for process improvement. However, this group could do its job and still have the organization’s product be low-quality. Therefore this function would be better termed “Process Management.”
Similarly, “Quality Control” does not control quality. Rather they measure quality, by verifying that what was implemented matches the requirements. Certainly there’s a feedback loop, as any defects will be reported and presumably fixed, thus increasing quality. But this group doesn’t really control anything. It would thus be better termed “Requirements Verification,” although I find the term “Product Test” more concise.
Calling these functions Process Management and Product Test removes any ambiguity or confusion. And calling them by these names does not impact your ability to get ISO 9000 certification or achieve a CMM level. Those require certain things to be done or documented, and require certain functions to be executed by the organization, but absolutely do not require specific organizational names.
I’m currently performing a quality assurance role on a software project. This has been a first for me and I haven’t spent a great deal of effort find out what quality assurance is “supposed” to mean, because to me it is clear. I’m supposed to assure the quality of the product and customer satisfaction. That doesn’t mean reassuring people that quality exists, it means stepping in wherever I see an opportunity to add or ensure quality. For this project it has meant a lot of things – clarifying requirements, documenting new requirements, facilitating communication within the development team, and yes, testing. But not just testing software, testing requirements, testing understanding of requirements, testing the schedule, etc.
If it is difficult to define what quality assurance is or should do, perhaps part of that is because it likely will vary from project to project. If you spend a great deal of effort trying to apply some “this is what I’m supposed to be doing” process to a project I’d guess a lot of your effort is going to go into dotting i’s and crossing t’s that could have better been spent contributing something useful to the project. Which is not to say you shouldn’t learn QA techniques or processes, only that QA requires the ability to analyze and respond logically to the needs of the environment and situation in which it is being performed.
