Differences between: QA, QC, Software Testing, Verification, Validation, Prevention and Detection

Question

I've trouble understand the differences between these terms: "Quality Assurance", "Quality Control", "Software Testing", "Verification", "Validation", "Prevention" and "Detection".

Here is what I think:

-Software Testing is a SUBSET of Quality Control. (One of the TECHNIQUE used by Quality Control)

-Quality Control is a SUBSET of Quality Assurance (Not too sure about this)

-Quality Assurance is a SUBSET of TLC (Testing Life Cycle)

-TLC is a SUBSET of SDLC

-Verification is a Quality Control process.

-Validation = Software Testing

-Detection ->Quality Control responsible for detecting bugs.

-Prevention -> Quality Assurance

Please clarify, Thanks

Answer 1

To further User246's point, I'll just add a couple of general points here that I've found to be true throughout most organizations.

Quality Assurance

Quality Assurance is the process of assuring quality. This process in the truest sense can only take place if it is included from the very beginning of a project. In its truest form, this is a process that pertains to all project members. It could be idealized through the common "quality baked in approach". Although many companies consider this as a testing process, if it is going to be implemented properly, it should instead be handled by a senior dev, senior tester, or in an ideal environment, by a quality assurance team whose responsibilities do not include being the only testers. For more information on the quality assurance process, I recommend reading some of Gerald Weinberg's work, specifically Why Software gets in Trouble.

Quality Control

This process should normally begin at the beginning of a project, but it is alright if it begins later. This is the process of inspection and detection (ie: requirements review, code review, software testing). This process is more of a fit for traditional software testers than Quality Assurance is.

Software Testing

Traditionally, testing is considered to be a subset of the Quality Control process although many organizations and managers consider testing to be Quality Assurance. Software testing is a process used to detect and identify faults and failures in a piece of software. More and more however, as companies switch to more non-traditional forms of software development, the software testing process seems to be transforming into a more contextual model in which questions like "Will our customer understand how to use this" (Very high level, I know). References to what software testing is and isn't can be found all over the web. I won't include references, as I'm not certain which particular software testing process you follow.

Verification and Validation

I can't really put much more in here than Peter K. did. About the only way that I can possibly clarify is by 2 examples. For a more in-depth answer, you may want to ask this sub-question on the English StackExchange Site:

I * the data.

I verified the data. (The data is there)

I validated the data. (The data is correct in its context)

Prevention

Prevention is the act of preventing bugs or failures from ever entering the system. In a traditional sense, this cannot be a testing activity as it must be done while the software is being developed. This would include assuring that the requirements are correct and that the software is written to correctly meet them. Personally, as a tester, I spend a lot of time working with our Business Analysts and Developers on the kinds of things that we do not want to happen. This kind of work could be considered a prevention exercise to which a tester can contribute.

Detection

Detection goes hand in hand with Quality Control. It is the process of detecting faults and failures after they have been entered into the system. In the traditional software testing process, this would be the traditional act of software testing (functional testing, automated testing, UAT, etc...). Detection can, however be done at the requirements stage of a project, and could then also be considered part of prevention.

Hope this helps a little bit.

Answer 2

For some of your terms, CMMI has a specific meaning:

Verification addresses the question :- Are we building the product correctly? This process looks at specifications, standards and guidelines to ensure that they have been correctly applied. For example if it is agreed (and this is usually documented in the Quality Plan) that standard IEEE xyz be used for the technical specification then an inspection is made to verify that the given standard has indeed been used for the technical specification.

Validation addresses the question :- Are we building the correct product? This question can be asked at any time during the SDLC but the essence of the question is, when this software product is placed in its proper environment does it fulfill the goals and needs of the end user, as expressed in the requirements.

Answer 3

I assume you saw or heard these terms used without definitions. The definitions for those terms vary by industry, organization, and individual. I could give you my definitions, but since they will not be the same as someone else's, I would be wasting your time. A Google search will reveal one person's definitions. Perhaps you can read those and then, when they seem to conflict what you see or hear, you can state those definitions and ask whether the speaker/author means the same thing.

Answer 4

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
• Verification
• Validation

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 :

1. 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)
2. 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).

Answer 5

Historically Quality Control is term from 1970s which meaning was controlling of the final product quality. In 1980s this term get a new meaning when people realized that they should also control quality of intermediate products.

A decade later term Software Quality Assurance came up when stress was set not only on quality of products but also on monitoring the software engineering processes (popular ISO 9000 certificate is all about quality of process not final product). The thinking behind Software Quality Assurance is that if you provide high quality software development you would get hight quality product. (In this context Prince2 is an interesting methodology: on one hand it stresses the focus on the product but on the other hand it provides well described processes which are means to get final product of high quality).

Lately, there came up another concept called Total quality management which stresses continuous improvement of the quality of products and processes.

Answer 6

In a regulated environment (e.g., FDA), you verify requirements, but validate user needs. The process starts with user needs from which requirements are derived from which features are implemented which are tested to verify that the requirements have been met and then at the end testing is done to validate that the user needs have been implemented.

Answer 7

QA- To ensure whether the requirement meets the developed product.

QC-Set of activities developed for evaluating a developed product

Testing-It is the process of evaluating a developed product with the intent of finding errors.

Verification-is the process of checking whether the developing product(not the final product) meets the requirements,the verification starts from the development

Validation-Checking whether the developed product(final product) meets all the requirements

Detection- To find bugs in the developed system.