Testing Strategy - Software Testing: Testing Across the Entire Software Development Life Cycle - page 72

supporting layers beneath the application before any actual testing is begun. The
testing strategy involves using an intelligent combination of testing techniques.
The testing strategy discussion will fi rst focus on just the top row, the applica-
tion under development. Assume for current discussion that the application under
development will be custom written. Off-the-shelf software package testing will be
discussed later in this chapter. Figure 4.2 shows you an optimal placing of chess
pieces on the test planning “chess board for your custom-written application under
development (top row).
For the Preliminary investigation, Analysis, and Design phases (leftmost
column), there is only a magnifying glass strategy in the application under de-
velopment (top row) indicating only static testing to be planned for these phases.
At this stage in the life cycle, the application exists only as design documents:
requirements, specifi cations, data structures, and so forth. No program code has
been written yet. So the only development artifacts that can be tested are the docu-
ments. This kind of testing done at this stage in the life cycle is concerned with
two issues:

1. identifying incomplete, incorrect, or confl icting information within each

document and across all documents that describe all aspects of the applica-
tion to be developed, and
confi rming that the document objectives are testable when they have been
translated into software.

2.

For the Preliminary construction phase (second column from the left),
there is a magnifying glass, a white box, and a black box strategy piece in the
application under development row. At this phase in the life cycle, there is a rich
set of artifacts to test: environment setup documentation, program source code,
data, and program code that can be executed. Besides source code walkthroughs
(magnifying glass), there is testing of the newly written code paths (white
box) and code input/output behavior (black box) as the written code becomes
complete.
For the Final construction phase (third column from the left), there is a
magnifying glass, a black box, and a hammer strategy piece in the application under
development row. Some of the later produced documentation like user's guides,
training guides, installation guides, and operating manuals need to be tested here.
Testing “inside” the code (white box) is no longer practical because all the code
components have been “packaged” or integrated together via compilation, linking,
or bindings. Testing of the packaged, more complex code component inputs and
outputs (black box) is continued during this phase. The fi nal testing that remains
at the end of this phase is verifi cation that the new application installs correctly
and operates properly (both black box testing) in its documented production
environment.
The hammer represents two different kinds of performance testing strategies:
performance baseline and workload. In traditional performance baseline testing,