DEFINITION

Quality assurance (QA)

In developing products and services, quality assurance is any systematic process of checking to see whether a product or
service being developed is meeting specified requirements. Many companies have a separate department devoted to quality
assurance. A quality assurance system is said to increase customer confidence and a company's credibility, to improve work
processes and efficiency, and to enable a company to better compete with others. Quality assurance was initially introduced
in World War II when munitions were inspected and tested for defects after they were made. Today's quality assurance
systems emphasize catching defects before they get into the final product.

ISO 9000 is an international standard that many companies use to ensure that their quality assurance system is in place and
effective. Conformance to ISO 9000 is said to guarantee that a company delivers quality products and services. To follow ISO
9000, a company's management team decides quality assurance policies and objectives. Next, the company or an external
consultant formally writes down the company's policies and requirements and how the staff can implement the quality
assurance system. Once this guideline is in place and the quality assurance procedures are implemented, an outside assessor
examines the company's quality assurance system to make sure it complies with ISO 9000. A detailed report describes the
parts of the standard the company missed, and the company agrees to correct any problems within a specific time. Once the
problems are corrected, the company is certified as in conformance with the standard.

DEFINITION 1: Quality is the degree to which an object (entity) [e.g., process, product, or service] satisfies a specified set of
attributes or requirements.

DEFINITION 2: The quality of something can be determined by comparing a set of inherent characteristics with a set of
requirements. If those inherent characteristics meet all requirements, high or excellent quality is achieved. If those characteristics do not

meet all requirements, a low or poor level of quality is achieved.

NOTE: Quality is, therefore, a question of degree.. According to this definition, quality is a relative concept. By linking quality to

requirements, ISO 9000 argues that the quality of something cannot be established in a vacuum.

Quality is always relative to a set of requirements .

DEFINITION 3: Quality is the degree to which a set of inherent characteristics fulfils requirements.
DEFINITION 4: A subjective term for which each person or sector has its own definition. In technical usage, quality can have
two meanings: 1. the characteristics of a product or service that bear on its ability to satisfy stated or implied needs; 2. a product or service

free of deficiencies.

DEFINITION 5: All characteristics of an entity that bear on its ability to satisfy stated and implied needs..
Degree to which a set of inherent characteristics fulfils requirements.

Need to get something straight: QA and QC are different.

Why must I point this out? Because programmers don't seem to get it and use
these terms interchangeably.
QA is QualityAssurance
but
QC is QualityControl
The difference is that QA inspects the process and QC controls the process and the
end product.
Testing, therefore is product oriented and thus is in the QC domain. Testing for
quality isn't assuring quality, it's controlling it.
  Quality Assurance makes sure you are doing the right things, the right
way.
 Quality Control makes sure the results of what you've done are what you
expected.

Why all the fuss?

There are lots of reasons to ensure the distinction between the two. Easily, the
ones that come to mind are:

 The QC and QA roles are different and must be addressed separately.

 QC cannot overrule QA and vise versa; they must work independently but
together to be effective.

The QA team's job is to see that standards, processes, and policies (or other
governing/guiding "writ") are in place and carried out; to recommend and
implement improvements to them, and to ensure that the people that need to
know about them know about them. QA "audits" or "reviews" are intended to
determine the efficacy of these "writs."
It's often easier to understand QA by an example: In one place (a large company
with large projects) I've seen QA's role to help project managers plan their
projects -- so that the projects follow certain organizational procedures; so that
they include the required artifacts, events, and milestones; and so that the
projects know what is expected of them and when in terms of reports, reviews,
and documentation. As the project progressed, QA would conduct "checkpoints"
along the way to see where the project may be developing risks, for example
either by progressing beyond where they've got authorization to go, or where
they may have need to escalate issues to management. These checkpoints would
also be an opportunity to ensure that people who need to be involved are
involved at the right times. This approach to QA isn't one that really suits XP,
but there are easily ways to adapt such an approach to XP.

Maybe mix-ups like this are happening because ambiguous terms have been
given specific meanings
Why would "assurance" mean process-related and "control" mean product-
related?
Because "assurance" means that you know you did everything needed to make
something that works right, while "control" means that you have no idea whether
any or all of your batch o'junk is worth anything until you examine each item.
"Just in time" production requires that you are assured your supplier is supplying
you with exactly what you need as you need it so you don't have to stop to test each
incoming item for defects. Was not adequate to assure that you didn't create a lot of
bugs along with your features.
One way to avoid confusion is to use more descriptive names: "Product-QA" and
"Process-QA".
I have always found the term "Quality Assurance" a curious choice. Why would
we want to be assured about quality (made to feel better about it) rather than
have quality ensured (guaranteed)?
Assuring quality is about confidence. It's about the *processes* by which we go
about doing what we do. Part of that knowing that we're doing the right things at
the right time, and part of it is that we are doing them the right way. This all should
be done or known before we start working, not afterwards.

These terms have been defined for us. While it may be 'more right' to redefine
them so they're no longer 'decentralized,' we ought to at least try to ensure
everyone has their terms straight when using them.
We may also look at the other areas in which these terms are used. 'Control' is
often a term used with statistics, and processes that can be "controlled" with
applying the analysis of the statistics. 'Control' is also an active term and has a
certain circumstantial connotation. The need to test ("control") is a function of
the circumstance of the existence of bugs or lack of confidence. Whereas
'assurance' is a passive term with a more universal connotation. The need to
"assure" is a function of building confidence regardless of the existence of bugs
and isn't just about bugs, but of the entire effort.

The difference between QA and QC is largely one of power and control. QC is

usually as service provided to development (i.e. under the control of
development) and is responsible for providing that service. QA expects
development to provide services to it (control development) and is not
responsible for any result.
The above statement is a symptom of one of the biggest problems in the entire
software industry. People don't know what "QA" is supposed to do (as defined in
this page). As a result many that do QA, do it wrongly, and many that work with
those doing QA incorrectly wind up hating QA because of the lousy experience they
had with it.
QA, when done effectively in a project, should not even cross paths with developers
except perhaps at the highest levels of management. Or to teach new developers the
organizational processes, or teach existing developers about changes to existing
organizational processes. And then later QA may interact with development to
figure out whether the processes work and what needs to happen to make sure they
work better. QA should not be causing developers to do any more work than they
need to be doing to develop the work. In fact, most of QA's role should occur with
project managers and leaders of other disciplines.
Another unfortunate characteristic of poorly executed QA is that often in
organizations that don't know the first thing about QA the people assigned to QA
are rejects from other skills which simply compounds the problem. Again, I'm
talking about QA as described here... not QC.
QA ... should not even cross paths with development.
Anyone care to explain this one? What is the purpose of QA if it does not deal
with development? I'm afraid "QA as described here" leaves a lot to the
imagination.
An edit was made to the paragraph above that may clarify the intent. QA's job is not
to inspect code or run tests or test programmers' know-how. If QA is "process"
centric, QA shouldn't fit in with the work developers are doing. QA folks should be
"process" folks not "product" folks. As such, QA's job should happen before and
in the aftermath of product development, and less to do during development. The
purpose of this page is to separate QA from the concept of "testing." A discussion
of what QA (QualityAssurance) really is seems to be brewing. Which is something
this page is not a good place for? Without proper definition, QA rightly so "leaves a
lot to the imagination."
So, define it already. It is not enough to say Qa Is Not Qc, you need to also say
what QA is. Also, is there really some deep distinction between the two, or is this
just some nit-picking intended to preserve a QA role when none is needed?

I have to agree with the prior comment that the terms are very confusing. Even
though they are commonly used, I think we'd be much better off if they were not.
Part of the problem is that these terms were taken from manufacturing
paradigms. QA dealt with manufacturing processes, while QC inspected the
manufacturing output to verify that it was acceptable. In the manufacturing
environment you analyze, design, and implement once and then crank out many
essentially identical products. This is very different from the software
environment where the analysis, design, and implementation happen on each
product, and then you start over for the next iteration.
In a software environment, "Quality Assurance" does not assure quality. Rather,
they assure that a process is being followed, which is very different. The process,
if it's a good process, will increase the probability that there is a quality result. It
will, presumably, make sure that requirements are communicated, traced,
planned for, scheduled, etc. The "Quality Assurance" role will likely also collect
metrics that it can then use for process improvement. However, this group could
do its job and still have the organization's product be low-quality. Therefore this
function would be better termed "Process Management."
 Similarly, "Quality Control" does not control quality. Rather they measure
quality, by verifying that what was implemented matches the requirements.
Certainly there's a feedback loop, as any defects will be reported and
presumably fixed, thus increasing quality. But this group doesn't really control
anything. It would thus be better termed "Requirements Verification," although
I find the term "Product Test" more concise.
Calling these functions Process Management and Product Test removes any
ambiguity or confusion. And calling them by these names does not impact your
ability to get ISO 9000 certification or achieve a CMM level. Those require
certain things to be done or documented, and require certain functions to be
executed by the organization, but absolutely do not require specific
organizational names.

I'm currently performing a quality assurance and quality control role on a

project. This has been a first for me and I haven't spent a great deal of effort find
out what quality assurance is "supposed" to mean, because to me it is clear. I'm
supposed to assure the quality of the product and customer satisfaction. That
doesn't mean reassuring people that quality exists, it means stepping in wherever
I see an opportunity to add or ensure quality. For this project it has meant a lot
of things - clarifying requirements, documenting new requirements, facilitating
communication within the development team, and yes, testing. But not just
testing requirements, testing understanding of requirements, testing the
schedule, etc.
If it is difficult to define what quality assurance is or should do, perhaps part of
that is because it likely will vary from project to project. If you spend a great
deal of effort trying to apply some "this is what I'm supposed to be doing"
process to a project I'd guess a lot of your effort is going to go into dotting i's and
crossing t's that could have better been spent contributing something useful to
the project. Which is not to say you shouldn’t learn QA techniques or processes,
only that QA requires the ability to analyze and respond logically to the needs of
the environment and situation in which it is being performed?

CategoryQuality

The terms “quality assurance” and “quality control” are often used interchangeably to refer to ways of ensuring the quality of a service or
product. The terms, however, have different meanings.

 Assurance: The act of giving confidence, the state of being certain or the act of making certain.
Quality Assurance: The planned and systematic activities implemented in a quality system so that quality requirements for a product or
service will be fulfilled.

 Control: An evaluation to indicate needed corrective responses; the act of guiding a process in which variability is attributable to a
constant system of chance causes.
Quality Control: The observation techniques and activities used to fulfill requirements for quality.
Quality control (QC) is a procedure or set of procedures intended to ensure that a manufactured product or performed
service adheres to a defined set of quality criteria or meets the requirements of the client or customer. QC is similar to, but
not identical with, quality assurance (QA). QA is defined as a procedure or set of procedures intended to ensure that a
product or service under development (before work is complete, as opposed to afterwards) meets specified requirements.
QA is sometimes exprIn order to implement an effective QC program, an enterprise must first decide which specific
standards the product or service must meet. Then the extent of QC actions must be determined (for example, the percentage
of units to be tested from each lot). Next, real-world data must be collected (for example, the percentage of units that fail)
and the results reported to management personnel. After this, corrective action must be decided upon and taken (for
example, defective units must be repaired or rejected and poor service repeated at no charge until the customer is satisfied).
If too many unit failures or instances of poor service occur, a plan must be devised to improve the production or service
process and then that plan must be put into action. Finally, the QC process must be ongoing to ensure that remedial efforts,
if required, have produced satisfactory results and to immediately detect recurrences or new instances of trouble.essed
together with QC as a single expression, quality control

.
A system for ensuring the maintenance of proper standards in manufactured goods, especially by periodic random inspection of
the product.
Quality assurance and control(Mathematics & Measurements / Statistics) control of the relative quality of a manufactured product,
usually by statistical sampling techniques (QA/QC) a system for verifying and maintaining a desired level of quality in a product or
process, as by planning,

Quality control - maintenance of standards of quality of manufactured goods

Internal control - an accounting procedure or system designed to promote efficiency or
implementation of a policy or safeguard assets or avoid fraud and error etc.