QA (Quality Assurance) and QC (Quality Control) are two different things.
The difference? QA is process-oriented and its purpose is to ensure that the right things are being done in the right way (using the right software testing tools). Whereas QC is product-oriented and ensures that the results of what you’ve done are as expected. Testing is, therefore, product-oriented and this is in the QC domain. Testing for quality isn’t assuring it, it’s controlling it.
It’s the job of the QA team to see that policies, processes, and standards are in place and carried out to recommend and implement improvements to them and to ensure that the concerned people are made aware of them. QA “reviews” or “audits” are intended to determine the efficacy of these “writs”.
Why Would Control Mean Product-Oriented and Assurance Mean Process-Oriented?
It’s all in the meaning.
Assurance: Everything needed to make something work right is done.
Control: Examining each item to find its worth.
Using more descriptive names is one way of avoiding confusion: “Process-QA” and “Product-QA”. Quality assurance is about confidence. It’s about the processes and knowing that the right things are done at the right time and the right way. This all should be known or done before starting to work. Whereas, “control” is a term that involves the use of analysis and statistics.
The difference between QA and QC is one of power and control. QC is usually a service provided to develop and is responsible for providing that service. QA expects development to provide services to it and is not responsible for any result. And this is where the major problem lies. People are unaware of what “QA” is supposed to do. Those who do, do it wrongly, and many that work with those doing QA incorrectly wind up hating QA because of the lousy experience they had with it.
Effective implementation of QA in a process should not even cross paths with developers except perhaps at the highest management level. Or to teach the organizational processes to new developers, or existing developers about changes to existing organizational processes. And then later QA may have an interaction with developers to figure out whether the processes work and what needs to be done to ensure improvement. QA shouldn’t cause developers any more work than they need to be doing. The majority of the QA’s role should occur with project leaders and managers of disciplines such as QC and SCM.
Another characteristic of poorly executed QA is that organizations have people handling QA who aren’t sufficiently equipped and are usually rejected from other skills which simply compounds the problem. This is specifically for QA and not for QC.
Separate QA from Development
The job of QA is neither to inspect code nor to run tests. If QA is process-centric, it must not fit in with the developers’ work. QA’s job should happen before and after the product development and not during it.
QA and Testing
These terms are very commonly used and are often confused as they were used in manufacturing paradigms. QA’s area was manufacturing processes, while QC inspected the manufacturing output to verify that it was acceptable. In the environment of manufacturing, you analyze, design, and implement once and then identify identical products. It’s a different ball game in software development where all these three aspects are involved in each product, and then you start over for the next iteration.
In a software environment, QA doesn’t assure quality. Instead, it assures that a process is being followed. A good process will increase the probability of a quality result. It will, presumably, ensure that requirements are scheduled, planned for, traced, communicated, etc. The role of QA will likely also collect metrics that it can then use for process improvement. Similarly, QC doesn’t control quality. Instead, it measures it by verifying that what was implemented matches the requirements. There’s certainly a feedback loop as any defects will be reported and presumably fixed, thus increasing quality. But there isn’t anything controlled by this group.
It’s not easy to define the role of QA, perhaps part of the reason is that it will vary from project to project. It’s important to learn QA processes, techniques, and software testing tools, but QA requires the ability to analyze and respond logically to the needs of the environment and situation in which it is being performed.
