The difference between QA, QC, and Test Engineering
March 6th, 2007 | Published in Google Testing
Posted by Allen Hutchison, Engineering Manager and Jay Han, Software Engineer in Test
The testing world has a lot of terms for the activity that we undertake every day. You'll often hear the words QA, QC, and Test Engineering used interchangeably. While it is usually enough to get your point across with a developer, it is helpful to think about these terms and how they apply to the world of software testing. In the classic definition QC is short for Quality Control, a process of verifying predefined requirements for quality. In the terms of an assembly-line this might involve pulling manufactured units off at the end of the process and verifying different parts of the assembly process. For software the QC function may involve checking the software against a set of requirements and verifying that the software meets the predefined requirements.
Quality Assurance, on the other hand, is much more about providing the continuous and consistent improvement and maintenance of process that enables the QC job. We use the QC process to verify a product does what we think it does, and we use the QA process to give us confidence that the product will meet the needs of customers. To that end the QA process can be considered a meta process that includes aspects of the QC process. It also goes beyond that to influence usability and design, to verify that functionality is not only correct, but useful.
Here at Google, we tend to take a third approach that we call Test Engineering. We look at this as a bridge between the meta world of QA and the concrete world of QC. Our approach allows us to ensure that we get the opportunity to think about customers and their needs, while we still provide results that are needed on day to day engineering projects.
Our teams certainly work with Software Engineers in QA and QC roles, but we also work with teams to ensure that a product is testable, that it is adequately unit tested, and that it can be automated even further in our teams. We often review design documents and ask for more test hooks in a project, and we implement mock objects and servers to help developers with their unit testing and to allow our teams to test components individually.
We put an emphasis on building automated tests so that we can let people do what people are good at, and have computers do what computers are good at. That doesn't mean that we never do manual testing, but instead that we do the "right" amount of manual testing with more human-oriented focus (e.g. exploratory testing), and we try to ensure that we never do repetitive manual testing.
The testing world has a lot of terms for the activity that we undertake every day. You'll often hear the words QA, QC, and Test Engineering used interchangeably. While it is usually enough to get your point across with a developer, it is helpful to think about these terms and how they apply to the world of software testing. In the classic definition QC is short for Quality Control, a process of verifying predefined requirements for quality. In the terms of an assembly-line this might involve pulling manufactured units off at the end of the process and verifying different parts of the assembly process. For software the QC function may involve checking the software against a set of requirements and verifying that the software meets the predefined requirements.
Quality Assurance, on the other hand, is much more about providing the continuous and consistent improvement and maintenance of process that enables the QC job. We use the QC process to verify a product does what we think it does, and we use the QA process to give us confidence that the product will meet the needs of customers. To that end the QA process can be considered a meta process that includes aspects of the QC process. It also goes beyond that to influence usability and design, to verify that functionality is not only correct, but useful.
Here at Google, we tend to take a third approach that we call Test Engineering. We look at this as a bridge between the meta world of QA and the concrete world of QC. Our approach allows us to ensure that we get the opportunity to think about customers and their needs, while we still provide results that are needed on day to day engineering projects.
Our teams certainly work with Software Engineers in QA and QC roles, but we also work with teams to ensure that a product is testable, that it is adequately unit tested, and that it can be automated even further in our teams. We often review design documents and ask for more test hooks in a project, and we implement mock objects and servers to help developers with their unit testing and to allow our teams to test components individually.
We put an emphasis on building automated tests so that we can let people do what people are good at, and have computers do what computers are good at. That doesn't mean that we never do manual testing, but instead that we do the "right" amount of manual testing with more human-oriented focus (e.g. exploratory testing), and we try to ensure that we never do repetitive manual testing.