Information Technology Reference
In-Depth Information
than “preferred,” thereby making the review process more of an announce-
ment than a serious discussion of options.
When requirements are put together, they are often based on current
needs. Even if they contain future plans, they are usually based on a
current
understanding of the future. This understanding can be flawed
or inadequate. It is difficult to add design elements that have to take care
of issues that are important but are not well articulated or understood,
such as scalability or third-party tool integration. For example, while
creating a Web-based system, the analyst may quantify the scalability need
at a certain number of concurrent hits. The designer puts components in
place to support this. The unexpected popularity of the site may cause
this projection to be exceeded, resulting in frequent outages, much to the
customer's dismay. Should the designer have accounted for this, even if
it was not in the specifications made by the analyst, and should it be
called a bug in the design or the specifications? This is being explained
below.
A few years back, an explosion in its center wing tank destroyed a
TWA jet. Since the dawn of the jet age, 14 fuel tank explosions have
occurred on commercial aircraft, killing more than 530 passengers and
crew. People consider it a grim monument to a faulty design. The industry
recognizes the presence of flammable vapors, and minimizes the associ-
ated hazard by eliminating potential ignition sources. Clearly this is a
conscious choice made to balance increased cost with customer safety
rather than a design flaw. Just as with jet planes, in QA there can be no
requirements for something that “should not be present in a system.” So
what
should
QA base its tests on? Should it test for all possible permuta-
tions and combinations of things that might result in a spark?
There are design expectations in any situation that remain implicit.
Some have to do with actual designs as we understand them (every room
should have a door or access to another room, and the door must open
and close). Others are assumptions around some structural basics, for
example, files are closed after opening them. It is the responsibility of
the QA team to point out instances where they recognize that the design
does not deliver on these implicit assumptions. But the QA team is not
a team of designers, and they cannot be expected to go too deep into
design issues.
Often, developers overlook things such as proper program structure,
inline documentation, maintainability, and supportability (exception han-
dling). All these impact the quality of the delivery. They are rarely included
as a part of the QA scope.
To summarize, QA operates on requirements, while software is devel-
oped to the design.
