A Full Software Development Lifecycle Testing Project - Software Testing: Testing Across the Entire Software Development Life Cycle - page 220

must validate the software specifi cations against the requirements they are supposed
to fulfi ll. Then someone must validate the software code against the software speci-
fi cations and, by implication, validate the code against requirements. With encour-
agement and support from the test team, the development team performs these static
tests. The more the testers are invited to participate in the developer testing, the more
the testers can learn about the system to be tested. This increased tester knowledge
tends to shorten the test case detail writing effort.

13.5.2 Test Environment Setup and Test Data
Preparation

While the developers are writing the program specifi cations, some of the testers are
writing test cases and other testers are setting up the testing environment and col-
lecting test data. See the Case Study B Preliminary construction stage architecture
design for the DCPS production environment and the test plan test environment. It
is decided to set up two of the new DSA workstations for the test environment: one
for clerk user testing and one for administrator user testing. This decision gives the
test team an exact copy of the intended production environment in which to test. If
automated test tools are to be used, now is the time to acquire the tools and install
them in the test environment. This approach provides the controllability and repeat-
ability of all DCPS testing in conformance with the “R” in SP R AE.
When the developers start writing code, the testers will start collecting and
creating test data. Because there is no DSA computer data to collect from prior
certifi cate printing, the testers will need to create all the computer readable test data
from scratch. The Case Study B Preliminary construction test plan calls for test data
to be created from the following DSA data sources:

1.
2.
3.

current list of all certifi ed instructors who work for DSA
current list of all DSA class teach locations
copy of all DSA class rosters used last month to manually prepare completion
certifi cates.
copy of last year's search log from municipal court and student requests that
resulted in requests for duplicate certifi cates

4.

The fi rst application module to be tested is the print screen (DSA1.02S). So the
testers responsible for test data preparation create data fi les of certifi ed instructors
(data source 1), DSA class teach locations (data source 2), and DSA completion cer-
tifi cates (data source 3) during Weeks 1 and 2. The search log (data source 4) will
not be needed for testing until Week 4 when the search screen (DSA1.03S) is written.
These test data fi les must be hand-built and visually verifi ed from printouts because
none of the new system input or reporting functions will be available until later in
this development stage.
Usually the tester has a choice of test data building approaches: brute force or
equivalence classes. An example of brute force test data building for this application
would be to create a certifi ed instructor fi le of all 200 DSA instructors, a class location