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

development to testing is also the tool used to move software from testing to produc-
tion. This approach guarantees that the software verifi ed as behaving correctly in
the test environment is guaranteed to be the correctly behaving software placed in
production.
10.7 BAD TESTING ENVIRONMENTS AND WHY
THEY SHOULD BE AVOIDED
A bad testing environment is one that is only similar to the intended or existing
production environment and is shared by other groups such as the developers or the
training staff.
The more dissimilar the testing environment is from the production environment,
the less valid the test results become. For example, suppose your application uses a
number of disk fi les to maintain application data. Further suppose the development
and test teams get the fastest computers available to speed up the development and
testing schedules. Your test computers then use a larger, faster disk drive than the
production computers, resulting in performance tests that will mislead the end-users
to believe the application will run faster in production. The corollary situation (more
common) is that the test team is given older, hand-me-down computers that have
slower, lower capacity disk drives than in production. In this situation, the perfor-
mance tests will under-report the application's response times … if the application
runs in the test environment at all. Extend the disk drive example to CPU speed, resi-
dent memory capacity, network topology, network speed, network capacity, printer
speed, monitor screen refresh rate and you will quickly realize how many ways the
testing environment execution dimensions can miss the mark.
When the test team shares any of the testing environments with other teams, the
loss of control can be disastrous for the test effort. The most obvious downside of not
controlling the testing environment is that the test team will be forced occasionally
to pause and possibly reschedule tests because the test environment is “busy.”
Another example of a busy test environment that impacts the test team schedule
is when testing is relegated to the third shift (11 P . M .-7 A . M .) of a computing envi-
ronment not used at night. Working at night does eliminate testing confl icts with
development. The real issue that arises is that when a tester fi nds a possible defect
in the middle of the night, there is nobody around at 3 A . M . from either development
or end-user groups to help confi rm the defect discovery. Everybody the tester needs
to contact is at home in bed. In this situation, the testing may need to be halted until
the next morning when everybody the tester wants to contact comes to work. Of
course, the tester will not be at the offi ce to greet them. The tester will come to work
late because he or she has been up all night. The result is the very delay hoped to be
avoided by third shift testing in the fi rst place.
Without clear management and coordination of the testing environment, it is
also possible that multiple test teams needing to reset the environment data in con-
fl icting ways cannot get their confl ict resolved in a timely and supportive way.