Students and clients often ask what the difference is between Software Quality Assurance, Software Quality Control and Software Testing. The classic distinction is that Quality Assurance (QA) addresses the processes that produce software, whereas Quality Control (QC) deals with the products of those processes. Testing is the primary method of QC for software.
That said, these definitions routinely are interpreted in a variety of ways that often are inconsistent at best. For example, most “QA” software groups actually only do testing.
For those relatively few QA groups that are not just doing testing, probably the most common distinction organizations make is that QA reviews requirements and/or designs whereas QC/Testing executes the developed software programs.
It should be evident that this definition of QA as reviewing requirements/designs does not actually address the software process. Review is a form of static testing, albeit typically of intermediate development products earlier in the software process. Executing code is dynamic testing of the end product of software development. QA vs. QC distinctions based on what is tested blur further when it’s the code itself that is reviewed.
Just to add a bit more fuel to the fire and mix metaphors, many people muddy the waters more with the term verification and validation (V&V). For many, verification (that the product was created right) refers to static reviews, and validation (that the right product was created) refers to dynamic code execution tests.
In fact, most dynamic test execution, regardless if it’s called testing or validation, is confirming only that the developed software conforms to its design, not that the design was right, and especially not that the requirements were right. This shortcoming is made even more likely by the common mistake of referring to the design as the requirements, which usually signifies that the REAL requirements have not been identified adequately.