The control process to keep system testing separate from live, operational work.

• The inappropriate introduction of modified software can have potentially disastrous results and bring the organisation to a standstill.

• Never introduce a new version of a major system upon which your organisation depends, without adequate and appropriate Regression Testing.
• If the new software passes Regression Testing according to your Test Plan criteria, you may wish it also to undergo User Acceptance Testing.
• The tested software may then be passed to Systems Operations for a controlled and scheduled upgrade, again following a plan.

• IT staff who run day to day operations and also test new software, (possibly swapping from one to the other on the same screen),risk making unintentional errors by inadvertently issuing system commands to the wrong system.

• Isolate testing work from your production work by using separate computers or partitions.
• Ensure that separate, restricted user IDs are employed - one for operations and a different one for testing.
• Refrain from using live data files for testing if possible, and if not, control the process tightly. See Using Live Data For Testing.

• Testing a system at the same time as it is being used for development work can yield flawed test results and give an inaccurate picture of its readiness for live operations.

• Do not permit the programmers to have simultaneous access to the source code libraries during System Testing. Separate your development and system testing environments.
• Use separate computers or partitions and also employ the Information Security features available under your operating system.
• Your testing process should reproduce 'live conditions' as far as possible, but take place under controlled conditions.