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

is so intensely focused on the functional requirements and probably has not real-
ized the full impact of improperly chosen support system components on successful
functionality.
There is one troublesome issue for the test team that arises from the initial anal-
ysis conclusions. Conclusion #3 contains a hard and fast application print format
requirement. Absolutely everything else about the DCPS and its support systems
may function perfectly; however, if the system cannot correctly print the results on
approved completion certifi cate forms, then DSA is in violation of the law.
The normal approach for developing new application reports is for the develop-
ment team to design the reports in the Design stage and write the report programs in
the Preliminary construction stage. The timing of report development and testing is
usually much closer to the end of the Preliminary construction stage than the begin-
ning because report development tries to leverage the application program structure
and data fi le structures after they are written and stable, as well as have valid data
loaded for report testing. Then, the testers execute the report programs during the
later part of the Preliminary construction stage and compare actual report results
against expected results.
Initial analysis Conclusion #3 mandates a test strategy that validates the tech-
nical reporting capability of the database management system during the Design
stage, well before the Preliminary construction stage is begun. If the reporting ca-
pability of the database management system chosen for the DCPS is found to be in-
adequate during the Design stage, the dollar and time impact of changing technical
approaches during the Design stage is substantially lower than making the same dis-
covery at the end of the Preliminary construction stage. You alert the development
project manager that database management report testing will need to be advanced
in the schedule to the beginning of the Design stage along with the new support
systems.
This is about as far as you can go with your test planning until the devel-
opment team documents the requirements. Once the requirements are written,
your test team can static test the requirements for completeness and correctness.
Then, your test team can begin to apply the SPRAE method to each require-
ment ( S pecifi cation) to complete your testing strategy and draft your test plans
( P remeditation).
13.3.2 Requirements Writing and Review—Use Cases
CPI begins the requirements research and documentation in earnest. The primary
sources of requirement information are the DSA manual procedures, the continuous-
form completion certifi cates, and the DSA class rosters showing who completed the
classes. Refer to Case Study B Document Repository on the publisher's Web site to
see a blank completion certifi cate and a blank DSA class roster.
From this information and further discussions with Lisa and her certifi cate
support staff, CPI develops the following DCPS use cases.