Some of these terms come from the "quality" community and have been reused by the IT community.
By "quality" community, I mean people with quality concerns whatever their branch (could be manufacturing, chemicals, etc ...).
This is the case for :
- Quality Assurance
- Quality Control
In the standard ISO 900x, and more specifically in ISO 9000 we find the following definitions :
§ 3.2.8 quality management
coordinated activities to direct and control an organization (3.3.1) with regard to quality
NOTE Direction and control with regard to quality generally includes establishment of the quality policy (3.2.4) and quality objectives (3.2.5), quality planning (3.2.9), quality control (3.2.10), quality assurance (3.2.11) and quality improvement (3.2.12).
§ 3.2.9 quality planning
part of quality management (3.2.8) focused on setting quality objectives (3.2.5) and specifying necessary operational processes (3.4.1) and related resources to fulfil the quality objectives
§ 3.2.11 quality control
part of quality management (3.2.8) focused on fulfilling quality requirements (3.1.2)
§ 3.2.11 quality assurance
part of quality management (3.2.8) focused on providing confidence that quality requirements (3.1.2) will be fulfilled
you can see in the definition that the term assurance takes its full meaning : the idea is to give some assurance = some confidence.
This translate into collecting traces of actual activities, like written test reports or traces of test automation. You wouldn't trust a guy just saying : "I just tested it, it's all fine" (that would be Quality Control without Quality Assurance).
§ 3.8.1 objective evidence
data supporting the existence or verity of something
NOTE Objective evidence may be obtained through observation, measurement, test (3.8.3), or other means.
§ 3.8.3 test
determination of one or more characteristics (3.5.1) according to a procedure (3.4.5)
§ 3.8.4 verification
confirmation, through the provision of objective evidence (3.8.1), that specified requirements (3.1.2) have been fulfilled
§ 3.8.5 validation
confirmation, through the provision of objective evidence (3.8.1), that the requirements (3.1.2) for a specific intended use or application have been fulfilled
This is one step beyond verification : OK you fulfill requirements, but what if requirements have forgotten to properly translate a need ?
Validation may not be always possible, as for some reason, the customer might not want to disclose the intended use.
You can see that Validation and Verification are pretty much the same definitions as in the CMMI.
I believe is there a added value in respecting these definitions, especially when it goes down to contractual disputes between customer/provider.
About prevention :
You could read full books on the history of "quality".
In very short :
Originally, quality was limited to checking the quality at the end of the production line. This was pure quality control / quality assurance.
This entails costs of non-quality : rework, scraping, and some other variants.
So quality made its revolution from focussing to controlling the end-product to focusing to the production process in order to avoid non-quality. Hence the introduction of Quality Management (brought by ISO 9001 version 2001).
I still ponder on which is true for Software :
- the same revolution still remains to be done in the Software field, and avoid so much money spending in these verification/validation phases (but there are some progress)
- hoping for a same revolution in SW is just non-sens. There is too much brainware in SW. The quality topic is essentially different in the "production field" and in the "sw / project field"
Back to prevention : it relates to quality planning, and the said necessity to establish quality processes that allow to fulfill quality objectives. Can we do that : yes, when we include the testing phases, when we monitor the % of passed tests, and so on ...; but this is far from a process that avoids non-quality. It is rather a management fall-back solution for the SW engineering inability to establish "0 defects sw factory" (that is the dream behind option 1 above).
About detection :
Detection assumes detectability which is often considered as obvious.
This is not so.
Detection may be a matter for test teams, but detectability is a matter for dev team as well as architecture (like exposing some interface for the pure sake of testing).