Information Technology Reference
In-Depth Information
department called Sales, the responsibility for getting new orders is left
to Sales — the rest of the organization does not consider selling its
responsibility. When there is a QA department, quality is identified with
that department. This should not mean that others ignore this aspect of
quality in their work. The designer, architect, programmer, and technical
writer all try to deliver quality output. Yet the formal seal of approval
must come from QA. This skews the resource allocation toward the output.
Quality in Other Domains
Software development cannot be made very repetitive. Each problem,
program, or application requires a unique solution. Although opportunities
exist for the use of proven problem-solving algorithms, or re-use of code,
the process cannot be made cookie-cutter style. This limits the extent to
which automation can be introduced and to what it can achieve. Software
development depends more on the quality of the team members than on
the equipment and tools given to them — however sophisticated such
tools may be. This reliance on human abilities leads to a variation in
the quality of the output. On the other hand, the manufacturing of goods
is based on repetitive processes: once the proper processes are in place,
automation helps achieve consistency in production quality.
There is another reason why the software “production” process cannot
be made uniform, especially with respect to quality. In software, the design
and development are so intermingled, and iterative, that the process cannot
assure quality. It is not “all design up front” and coding later. This means
that the strategy often adopted in manufacturing — to make the design
as good as possible, followed by a highly repetitive process — does not
work in software. This is not to suggest that there is no healthy feedback
between design, manufacturing, and field deployment in manufacturing.
However, in software development, the phases are intermingled because
the developer has several choices as to how he or she can code to a
design. It is easy to implement the design differently, whether conscious
or not. As discussed previously, both Engineering and QA work off the
same specifications but the specifications that QA depends on could have
been implemented in many ways by Engineering. This makes the QA task
more difficult in practice. For example, if the specifications require that
two users are not to be permitted to access a certain data store at the
same time, such a feature could be implemented through the locking
features provided by the database or through managing flags by the
application. It would matter to an experienced tester in the way he could
design tests.
There is another way in which a design affects QA. If the design
changes frequently, it impacts the quality of the code because it creates
