Information Technology Reference
In-Depth Information
Quality as Feedback
In systems terms, quality assurance is part of the feedback loop of the
engineering system. The input to an engineering system is the require-
ments document. The output is the code. Quality assurance (QA) teams
sample the output and provide feedback signals, in the form of defect
reports, so that the output is brought closer to the requirements. This
is an example of negative feedback. Car efully note that the term
“negative feedback” is different from “negative criticism” and does not
indicate a problem. It is called “negative” because it has a
damping
effect
on the divergence between the output and the requirements. This
damping effect is desirable. Engineering acts on this feedback and
improves the code; and the output is again sampled, hopefully showing
that it has moved closer to the requirements. How long this might
continue depends on how many such iterations the project can afford,
in terms of time and money, or on the application of a threshold of
acceptable divergence.
Products and Processes
There is a well-known difference between quality assurance (QA) and
quality control (QC) in the manufacturing world, perhaps more than in
software. To put it simply, QA refers to the process and QC to the product.
However, both are important. Quality products need quality processes.
Good systems are needed to build good systems. However, many software
organizations identify the QA department with
, and have focused
their attention on product (quality control) aspects more than the process
aspects. Most of the quality-related costs are incurred in determining
defects in the product to be shipped.
QA is not as actively engaged in many aspects of software development
as it should be. They are often not invited to discussions about design
and architecture. The fact is that the QA process, as it commonly exists,
interfaces more with Engineering than with the customer. It therefore
works off the same specifications as Engineering does. It is not seen as
QA's role to challenge the requirements or specifications. As one might
guess, this assumption of correctness of specifications has some risks, yet
as a process it works. They are only following specifications.
The difference between QA and testing also lies in the attitude and
approach of those in charge (Figure 12.1). QA is oriented toward error
testing
prevention
. It should be employed throughout the software development
life cycle, in managing and improving processes, making sure that docu-
mented standards and procedures are being followed. On the other hand,
