Test Environment

Whether you use XP or some other software development process, you absolutely must have a test environment separate from both the development and production environments. This is not negotiable. You might even have multiple test environments, especially if you work in an organization that has post-development test cycles. You might be able to test on your own personal machine using a local build for the early stages of a release, but you'll need a separate production surrogate for realistic testing.

Don't try to test on the programmers' integration machine. That's theirs to break at will. Trying to use the integration machine as a production surrogate will slow up the whole project and cause all kinds of headaches. Ditto for attempting to test on a demo environment. Testing should happen in its very own happy space. Most important, the software and data in the test environment must be controlled by the people doing the testing. They must have the ability to roll back to a previous version of software if needed.

What if you don't have this separate test environment? You'll have an impossible task. Keep pushing for the test environment until you get it. Keep documenting the time wasted and the defects not caught in time because you didn't have it. The need for a separate test environment isn't rocket science. Everyone knows it in his heart; you just need to keep pointing out the emperor's clothesless state until the people with the means to do something about it acknowledge the problem.

Customers should have their own production surrogate environment for user acceptance testing. Once your team has tested a code base and found it solid enough, you can install it on the customer's test environment. Even so, retain control of the customer's production surrogate. Finished releases will be installed on the actual production environment. Demos, design work, or other tasks should be carried out on a separate, dedicated environment.

This brings up the issue of how software should be delivered for testing. At some point, you're going to have to have some kind of release package, either to promote to production or to hand off to an external customer. The earlier in your project the programmers can start producing this, the better.

At the very least, have them label versions in the source-code control, so you know exactly what you're testing. The team needs to be able to roll back to an earlier version when necessary. It's frustrating to install a new build only to discover something broken that keeps you from testing.

On the other hand, it's good to have the capability to check modules out from the source-code control and build them yourself. This allows you to test individual modules that are ready early or test individual fixes.