Information Technology Reference
In-Depth Information
bugs are not “syntactic” language errors, as the obvious ones would have
been removed by most compilers.
The definition of “bug” depends on perspective. For a customer, a
requirement not met by the system is considered a bug. For a developer,
a bug
is something that does not match the specifications given to him.
This sometimes leads to a “bug versus feature” dispute with the customer,
especially during user acceptance.
Most bugs are, however, incorrect implementations of a desired end
user need.
The cause could be incomplete requirement specifications or
incorrect interpretation by the developers due to a lack of detail. At times
this ambiguity is due to the “obvious” being left unsaid. For example, the
fact that each door and window in a house must have a latch is a fair
expectation, reasonably well understood, and need not be explicitly stated
to the builder. Such expectations on the part of the homeowner (the
customer) may not match the assumptions of the builder. Often, projects
fail due to the differences in what is assumed to be obvious “to any
sensible person.” The problem is that what might be obvious to a customer
may not be so to the builder, however trivial it may be. This is a familiar
problem related to getting good requirements. It is the problem of figuring
out whether requirements are a push or pull process. As discussed
previously, the QA interacts more with Engineering than with the customer.
A change in requirements after the design is released can have serious
consequences on code quality. A set of final requirements, if arrived at
in two steps rather than one, is likely to generate more bugs. Some factors
include:
Depending on how the change request is handled, the code may
have to be rewritten.
New third-party software may have to be introduced, bringing its
own complexity, to handle the changes.
New developers, who would have missed the discussions up to
that point, may have to be added to the team.
It is thus very important to spend some more time up-front on require-
ments. In development processes that specifically plan for iterative require-
ments gathering, the success of the process depends on ensuring that the
factors mentioned above are in control.
Handling Change
Some changes in a given software environment can be more detrimental
than others. Utmost care must therefore be taken while introducing
partially tested third-party components into a system. Never assume that
