The Testing Environment - Software Testing: Testing Across the Entire Software Development Life Cycle - page 155

is signifi cantly less expensive to rent or lease computer equipment for a short time
(1-3 months) than it is to purchase the equipment. The cost of setting up and tearing
down the test environment becomes a standard line item of the testing project budget.
What about testing environments whose lifetime falls somewhere in between
the two extremes? The recommendation is to start with pricing research for the
needed testing equipment both as a short-term rental and as a long-term purchase.
Then, determine from previous testing projects the estimated effort in setting up
and tearing down the testing environment. Finally, estimate the number of times the
test environment will be used over a 1-year period starting as soon as the software
development project begins. Do the math and determine which approach is most
cost-effective for your software development projects.
10.6 GOOD TESTING ENVIRONMENTS AND WHY
THEY SHOULD BE USED
A good testing environment is one that very closely operates like the intended or
existing production environment and is totally controlled by the test team.
The closer the testing environment resembles the production environment, the
more valid the test results become. In many cases, the testing environment can be
set up truly identical to the production environment. Testing in this kind of duplicate
environment gives the developer and the end user an exceptionally accurate view of
how the new software will behave in production.
Test team control of the testing environment has two major benefi ts. The fi rst benefi t
relates to the controlled repeatability of all testing. When the test team does control the
testing environment, then the team knows exactly what versions of software components
are in the testing environment at all times, as well as the state of all test data fi les. As
defects are detected in the software, the tester can repeat the test and confi rm the defect
discovery for anybody who needs to see the defect demonstrated … like the developers.
The second benefi t of a tester-controlled environment is the testers' ability to plan and
execute tests without being interfered by or interfering with development activity. The
testers drive the test schedule, whether it is to complete a certain set of tests by a certain
date or to rerun a set of tests to validate correction of previously detected defects. A fi nal
implication of tester control of the testing environment is that testers can ensure that no
software corrections are made directly in the testing environment. Modify a previously
tested piece of code, and the previous test results are null and void. Corrections and
modifi cations must be made in the developer's environment and be re-staged into the
testing environment using the same staging process as fi rst introduced.
Staging procedures also represent a level of testing environment control. Good
staging procedures take advantage of automated staging tools. The primary intent of
staging tools is to guarantee that the software that arrives in the testing environment
is the same as the software that departed from the development environment ready
for testing. The secondary intent is to guarantee that each staging is repeatable, that
is, rerunning the staging tool for the same versions provides the tester with exactly
the same software to test. Very often, the migration tool used to move software from