I’ve seen a few examples of significant amounts of testing taking place only for the tester to realise, a little too late, that all the work is invalidated because the test environment doesn’t match the production environment. In projects where the deadlines are tight and the test environments are limited it’s only too easy to allow developers or support teams access to a test environment in order to help them out. The only problem is that frequently changes are made to the test environment and then never put back. So in an attempt to help out the project overall a tester can often get caught out and be left with an environment that is effectively useless (testers aren’t wholly blameless for messing up test environments either).

Thom Garrett in his article, Implementing Automated Software Testing, puts forward some good suggestions on how to safeguard the integrity of the test environment. Isolating the test environment is one suggestion put forward which is arguably the ultimate solution. However, in the real world where it’s difficult to completely restrict access, the suggestion of implementing formal configuration management processes/tools in the test environment has to be an option worth further investigation.

For anyone who’s been caught out by the issues surrounding test environment configuration this article is well worth a read.

Regards
Yannick