Guest View: Quality Assurance meets Quality Control
By Robin F. Goldsmith
August 1, 2010 —
(Page 1 of 3)
Related Search Term(s): QA, testing
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.
I recognize V&V is a well-established practice, especially for Department of Defense development, and often is not founded on static vs. dynamic testing distinctions. Many of those performing such V&V very much do endeavor to validate that the right product is being created. Nonetheless, I still find the term “verification and validation” too often is used in ways that don’t add to my understanding, and I personally avoid it.