Information Technology Reference
In-Depth Information
test execution. Although some interesting results have been obtained by experienced
testers using the “exploratory testing” approach, its premise seems to preclude
accountability in the SPRAE context and appears to contradict prudent testing
practices for the inexperienced tester.
3.3.5 Economy
The
economy
item is more representative of a kind of thinking and planning like
repeatability than a kind of documentation like specifi cations and premeditation.
The crux of the economy item is testing cost effectiveness, which can be measured
in many ways. The introductory chapter examined some of the high-level cost issues
around software testing, namely the total cost of testing compared to the total cost
of the business risk reduced by testing. This SPRAE item requires the technical
teams to develop a detailed testing budget from which the total cost of testing can
be computed.
Because software testing is basically another kind of technology project, expected
testing personnel and equipment costs are included in the testing budget. Budget
items fairly unique to testing include test data preparation, testing environment setup
and teardown (not just a desktop computer per tester), and possibly automated testing
tools. These unique budget items will be examined in depth in a later chapter.
Finally, the testing schedule can be considered a contributor to the economy
of a test project. Because testing is often considered (incorrectly) to be a necessary
evil between development completion and deployment, the development manager
may consider relegating the testing executions to the third shift where it can be done
on schedule without interfering with daily development and routine business. This
“night owl” approach to testing will actually increase the time necessary to complete
testing, causing both testing and development schedule overruns.
To understand the reasons for this reverse economy, place yourself in a tester's
shoes executing tests on schedule at 2
A
.
M
. in the morning. One of your new test
scripts blows up. Under daytime testing circumstances, you might contact one of
the senior end users in your team to determine if the test script is attempting to
validate the specifi cations incorrectly. Another possibility might be your contacting
the developer to determine if the program code and application specifi cations are
in confl ict. A third possibility might be your contacting the system administrator to
determine if there is a problem with the recent program build or data load for test-
ing. None of these courses of action are available to help you resolve the test script
problem. Everybody you need to contact is at home in bed fast asleep. The best you
can do is leave notes around the offi ce or on voice mail, close down your testing
activity for the night (this problem is a testing showstopper), and go home to bed
yourself. What could have been resolved in an hour or two during the day shift will
now stretch over 8-10 hours while everybody fi nishes their night's sleep, fi nd your
notes, and begin to respond to your problem. Your testing schedule just went out the
window with the fi rst major testing problem encountered.
Search WWH ::
Custom Search