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

in the stored record name fi eld versus how are trailing blanks treated in a search
criterion?”

13.5.4 Structural Testing

The majority of the DCPS structural testing is focused on creating, printing, backing
up, and aggregating fi les of certifi cate records. Chapter 8 identifi ed six structural
testing techniques:

1.
2.
3.
4.
5.
6.

Interface testing
Security testing
Installation testing
Smoke test
Administration testing
Backup and recovery testing

Of the six techniques, security testing, installation testing, and smoke test do not
apply to the DCPS as it is currently designed. Security testing will arise if DSA
fi nds it needs more than physical lock-and-key security on the workstation chassis.
Installation testing and smoke test will probably never arise because the DCPS will
be installed by the CPI system developers and only on DSA workstations.
Taking the testing techniques in the order that they are expected to be used,
administration testing will be fi rst by virtue of use cases -07 and -08 whose actor is
administrator. The high-level goal of administration testing here will be to ask the
question, “Does the Admin Menu contain all the activities necessary to support the DCPS
on a daily, weekly, monthly, and yearly basis?” The low-level goal of administrative
testing will be to validate the functionality of the administrative processes provided.
Next, interface testing will occur as an extension of use cases -07 and -08 as
fi les of student completion records are selected and moved from local database fi les
to transfer fi les that can be sent from one workstation to another. These test cases
are represented by the FTXXX-08.0 series. If transfer fi les of student completion
records cannot be properly built, then there is no value in testing backups, transfers,
or archiving of bad transfer records.
Finally, backup and recovery testing will occur after the transfer fi le validation
is completed. These tests are represented by the FTXXX-07.0 series. They validate
the destination fi le updates caused by moving the transfer fi les via the administrative
screens. Notice that these tests involve two or more workstations (see the prelimi-
nary construction architecture design). The multiple workstation test requirement
introduces the additional test environment dimension of peer-to-peer connectivity.
The primary developer challenge is to make these backup and archive processes
rerunable if the process fails. For example, if the peer-to-peer transfer process fails
while testing FTPOS-08.0, the software must provide a retry capability without du-
plicating records on either the transfer fi le or the destination fi le.