Information Technology Reference
In-Depth Information
Application
Reports
Delivery to QA
DB
Batch scripts
QA Tests multiple environments
Figure 12.8
Quality assurance (QA) consolidates across modules.
pieces. Going ahead with QA for only some of the pieces is not feasible.
This is another reason why QA needs to
pull
the code, even if Engineering
is ready to
push
. It can time the changes in its environment, ensure that
all engineering deliverables are on the new version, and then start a new
test cycle (Figure 12.8).
Any sort of simple dependency diagram, or a release plan, can capture
this sequence of taking up modifications and releasing new versions.
Multiple Views of Quality
Software gets released when a certain quality, deemed sufficient, is
achieved. Engineers and analysts may have a definition of acceptable
quality that differs from what is used by
consumers
interacting with the
system. Consumers are not limited to the primary end users for whom
the software was developed. They include the organization's sales and
marketing groups, implementation and installation sales support engineers,
finance personnel, and perhaps even the external press who have their
own ideas of what a system is expected to deliver.
An application is rarely deployed in isolation — it is part of a larger
environment that includes various business processes. Not all consumers
understand this complex environment. For example, data may be lost
because of inadequate backup, or a report may generate inaccurate totals
(when compared to actual physical inventory) because a data load did
not happen properly at the backend. A user may very well tag these as
quality issues. Unnecessary blame can easily be assigned to the software.
