Information Technology Reference
In-Depth Information
The primary focus of the testers is the diffi culty they encountered as they adapted
some of the Preliminary construction test cases to the new but similar screens added
in Final construction. Testers also recalled that they had diffi culty with the regres-
sion testing because of rerun challenges with the test cases.
When the time comes for the testers to return to DSA for Postimplementation
testing, the testers request the use of one workstation, the time of one of the more
experienced DSA certifi cate preparation staff, and the time of the DSA Operations
Manager, Lisa Lemoine. Testers repeat their Final construction performance testing
with the DSA staff operating the workstations and software. In accordance with the
postimplementation test plan, the testers start by measuring the data entry screen
response times. Then the testers move on to measure the printing response times.
Finally, the testers measure the weekly certifi cate fi le transfers to the master fi le.
Each round of tests takes most of a workday. At the end of each day's tests, the testers
show DSA the measurements collected over the day and how these measurements
compare with the Final construction testing measurements. At the end of the week,
the CPI testers and DSA staff agreed that the DCPS continues to operate as well as
it did the fi rst days after “going live.”
13.9 CASE STUDY CLOSURE
The software system that is the basis for this chapter's case study was implemented in
1988 and was still in production in 2000 as originally implemented without any major
fi xes. The customer felt that the software achieved all of the original design objectives
with nominal disruption to business and continued to meet its business requirements
three times longer than the originally hoped 4-year return on investment period.
13.9.1 Summary
The challenge for this chapter is to walk you through a case study that will demonstrate
ways to make intelligent choices of strategies and techniques that are successful time
after time when there is no single formula for success. We will answer this challenge
by repeatedly applying the SPRAE method to a series of situations that arise during
a software development case study.
The case study chosen for this chapter contains some intentional simplicity. One
reason for this simplicity is ease of demonstration and discussion. Another reason
for this simplicity is to set the stage for Chapter 14 that will show how more complex
testing situations can be attacked successfully by decomposing the complex situation
into the simpler, more familiar situations from this chapter. The case study develop-
ment activities follow the phased development methodology. Testing at each stage is
conducted using the SPRAE methodology.
The software development project chosen for Case Study B is a real software
development project in which one of the authors was a primary participant. The
company name, staff, and location have been changed to honor the company's
confi dentiality.
Search WWH ::
Custom Search