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

here. Most of the data entry fi elds are the same. Hence, the same testing details will
apply. The two main differences will be the certifi cate number and instructor name
fi eld. In the completion data entry screen, the certifi cate number does not appear be-
cause the print program assigns the certifi cate number at print time based on the con-
tinuous forms being used. Additionally, the certifi cate number input value test must
be numeric only and fall within a specifi c value range (greater than 0 and less than
10,000,000,000). The instructor information is entered on the completion data entry
screen as an instructor code that is used to look up the instructor name from a table
of certifi ed instructors. The instructor information is entered on the historical data
entry screen as the instructor name that needs to be validated against the instructor
list instead of the instructor code. Finally, the historical data entry screen changes
the student name validation criteria somewhat because the name components are
entered in a different order than the completion data entry screen.
13.6.3 StructuralTesting
The structural testing fi nished in the Final construction stage will be as complex
as it is critical. The Preliminary construction stage was halted a week earlier than
planned because the originally designed structural components that support the ba-
sic certifi cate record processing fl ow would not fully stabilize, and the parts that did
stabilize exhibited poor performance. The testing challenge is to adapt the test cases
to the redesign. The fact that the original design could not withstand the structural
testing before “going live” is a very desirable testing outcome. We have all experi-
enced software systems that seem to need many patches (not enhancements) over the
lifetime of the software. It is likely that the original testing of this software was not
suffi ciently rigorous to force the kind of redesign decision during development that
has occurred on the DSA project.
There is one more structural consideration worth highlighting at this point in the
project. We have a new requirement for student reports to out-of-state agencies. This
requirement could have been addressed by new structural components (fi le extracts,
fi le backups, and fi le transmissions) independent of the basic certifi cate record pro-
cessing fl ow redesign. In this case, there is a benefi t to delaying the development
and testing of the out-of-state reporting until after the process fl ow redesign is fi n-
ished. The out-of-state reporting designers might be able to convince the process
fl ow redesigners to adopt design strategies that make some aspects of the out-of-state
reporting easier to implement or faster to execute without sacrifi cing process fl ow
effectiveness.
13.6.4 PerformanceTesting
The performance testing activities during the Final construction stage will focus on
two main objectives. The fi rst objective is to ensure by performance regression test-
ing that none of the new or redesigned code adversely affects the response times of
the screens that achieved their performance goals in the Preliminary construction