The difference between QA, QC, and Test Engineering
Tuesday, March 06, 2007
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.
I love your description of the different roles...right now I work for a small group of a large company...I am a fiarly new employee and up until now the test process has been almost exclusively QC and manual...I am starting to work with developers to implement some automated tests to free test personnel to do more exploratory testing...it's quite the adventure!
ReplyDeleteTest Engineering method is nothing but W-Model (Not waterfall). In W-Model verification and validation process go hand in hand. Reviews play a major role and helps in getting the concrete, strong and stable requirements, whcih will be base for strong future development process. Everyone knows the impact of fixing any defect at the later stage of the project life cycle and also the benefit of identifying the issues at the beginning of the project life cycle. Give more importance to Review and Analysis process, this will help in building strong Base. If the base is strong, anything can be built on that.
ReplyDeleteI also tell my team members to spend qaulity time doing analysis of the work they do. Do not spend the entire day in just doing testing. Spending everyday sometime on Analysis will help them to move in the right direction in the work and also helps them to see in a bigger and broader perspective of the work.
Finally, just spend good amount of time in planning, reviews and analysis, the execution will be done like in no time.
Lest build and grow the Quality and Testing community stronger across the world.
Thanks for the clarification about QA, QC, and Test Engineering.
ReplyDeleteAny suggestion for regression testing? That might be the reason to do most of repetitive testing.
hmm..great info for me, anyway..:)
ReplyDeleteYour blog provides sufficient information on QA and QC but testing, I suppose, hasn't been given enough emphasis. It would be appreciable if you post more on Testing and the process you follow for the same.
ReplyDeleteHi Allan, Jay,
ReplyDeleteYour defintion of QA is a little off, ok, way off base. It is NOT tied to testing or QC and is NOT applied to the product. It is assurance of the quality of a process, which may produce a lousy product if the process is weak. See this article to help clear things up: http://spistuff.blogspot.com/2007/09/qa-vs-qc.html
Thanks for the this clear and succinct definition. I was recently hired as a "QC manager," a role I haven't held before, and was adrift in conflicting expectations. The actual role I hold is more QA than QC, although I suspect I will do both, along with a little testing. There is another with the title of QA lead, but his actual role is more QC. So we have a lot of alignment and setting of expectations to do. This will help.
ReplyDeleteI also came across this tongue-in-cheek definition: "QA tells you how to ensure the quality of your product. QC tells you how you did it wrong."
DeleteThe actual definitions of QA and QC can better be explained in context of the place they work. As matter of fact Testing is done at in-house or by a third party testing team. Tester at in-house do more of QC rather than QA as they do have a set of requirements and they validate the software against requirements. When coming to third party testers, they are involved in lot of process improvements which will actually help the clients to deliver best software.
ReplyDeletei don't agree with
ReplyDelete"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. "
Qc : is the process of testing the quality of a product.
Qa : measures the quality of processes used to create quality product.
I think the disconnect is where the terms QA and QC are often used interchangeably. I definitely work as a test engineer at my company, but my title is QA engineer. The title is closer to what the author is saying here, but I think the industry as a whole uses disparate terms to mean similar things sometimes.
ReplyDeleteWhat is the main idea qa in Google?
ReplyDeleteOne wonders, what is the thin line between automation and human intervention.
ReplyDeleteOnly just read this article, and noticed date! Feels even more relevant in 2016 :) "Test engineering" best describes what I do now, and what should be happening more. Within that scope, I can have influence/effect on overall project quality, from requirements through to the build pipeline. This was more effective and useful QA "power", than when I held management roles. You can over-analyse these things of course :) Whatever we are within large scope of Quality Assurance, we are part of a team and a common goal.
ReplyDeletewhich thing of this number is +327531627
ReplyDeleteThis article is really helpful. Thank you!
ReplyDelete