Information Technology Reference
In-Depth Information
during the development of the test strategy. One common mistake is to
not understand (and challenge) the specifications well enough before
detailed test plans are prepared. A thorough review of the specification
by QA is a valuable exercise for both QA and Engineering. This highlights
the multiple levels of feedback that are typical of systems — there is the
feedback about how well the specifications are being met, and then there
is feedback about the specifications themselves. If this duality is recognized
by managers, then the value of the QA process increases.
Specifications may be of poor quality for many other reasons: lack of
details, or too much detail; poor expression; invalid assumption; and the
like. However, one problem that can be expensive is incompleteness. Incom-
pleteness emerges due to various situations that can often be prevented:
The assumption often is that the entire ground has been covered
but that may not be so. Each of these smaller specifications cover
some ground and have their own specifications. For example, there
may be a pop-up box that asks whether one wants to “save the
screen.” If one specifies the responses as “yes” and “no” only, it
would be incomplete because “cancel” is a valid option that allows
one to avoid both the yes and no options. Another example could
be one of data management, where the “import data” module
specifies only the requirements for importing data; the “export
data” covers exporting data, etc. There may be a need for a nightly
“refresh” process that does not fall under either the “import” or
the “export” categories.
While decomposition allows details to be specified in a manageable
manner, it can prevent the larger picture from being addressed
until it is too late. Addressing the larger picture is necessary because
behavior at a higher level differs from the nature and behavior of
its components. This is known as the
of systems,
and necessitates a (separate) specification at the high level, or each
level against which QA should test. For example, if there are
specifications for each screen of a multi-step order-taking process,
there should be another specification for the entire order-taking
process, and its associated behavior.
emergent
property
Specifications can end up having a narrow focus, which is often
based on the defined objectives or scope. A strong focus on the
issue specified — the “defined objective” — leads to the oversight
of other effects. This is similar to the situation where the doctor
focuses on solving the “main” problem, say cancer, while anything
else that happens is deemed a “side effect.” However, these side
effects could be more harmful than the focal issue; and even if
Search WWH ::




Custom Search