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

4.
5.

backup and archiving
menus

This priority list and attendant developer effort estimates drive the testing schedule
you see in the test plan.
The testing schedule is represented by a development task followed by a series
of testing tasks. Almost all of the testing tasks extend beyond the development task
timelines because the testers cannot make a fi nal evaluation of this particular com-
ponent until after the developer is fi nished. At a more summary level, this project
is expected to take 10 calendar weeks of development effort, but the combined Pre-
liminary construction test plan and Final construction test plan show a 12 calendar
week effort.
The other aspect of the test plan worth mentioning is the test case list for each
development stage. This section of the test plan responds to the testing accountabil-
ity, the “A” in SPR A E, by delineating in advance what will be tested and in which
order. This minimizes the wasteful tendency to test “until you get tired of testing.”
As we document the list of performance test cases, some of the performance
test limits are immediately apparent from the use cases. For instance, the weekly
backup process must complete within a 4 hour window on Friday afternoons.
Other performance test limits are not mentioned in the use cases but have obvious
implications for the DSA business. Test case PT-03.0 is troublesome at this
juncture. PT-03.0 is supposed to measure how quickly a data entry screen can
be completed.
The business question for the testers is “How quickly must the data entry screen
be completed? ” This question is directly related to the manual processing bottleneck
that prompted DSA to consider a computer system in the fi rst place. DSA recognizes
that all of the data entry staff are currently working at maximum capacity and any
increase in completed certifi cate production will require additional data entry staff to
handle the increased load. The point is that DSA does not need to do a time-motion
study to see that its data entry staff is maxed out. The fl ip side of this point is that the
test team needs to know the current manual process time-motion numbers in order
for performance testing to target computer response times fast enough to level the
staffi ng load for several years.
CPI meets with DSA to request a time-motion study of the manual system be-
fore it is replaced by the new computer system and before the new computer system
is completed. Here are the metrics that CPI requested from DSA.

• Take several timing samples of the completion certifi cate typing process over

the next 3 weeks (before the data screen programs are due to be fi nished).
Consider sampling work levels of a few of the most profi cient data entry staff,
usually longest employed. Use these numbers as the upper range of certifi cate
production.
Consider sampling work levels of a few of the lesser profi cient data entry staff,
usually newer employees. Use these numbers as the lower range of certifi cate
production.

•

•