• The product to be tested must be considered complete by its developers; any exception must have explicit management approval. This does not mean that the system as a whole must be complete, but it does mean that any intermediate level of the system must have complete functionality in the areas being tested.
• The written Test Specification for that product must be finished, approved, and ready for execution.
• All supporting test data must be ready
• Both the developers and the testing people must be present, or on call
• Computer time, if needed, must be available
• Any special resources (for example, remote equipment, temporary living facilities at a remote site, transportation) must be ready.

   We can learn some lessons about system test from past disasters. First, no amount of luck, political acumen, or clean living will allow you to skip system testing and get away with it. In a system of any complexity at all, those hotshot programmers are going to make mistakes.

   Second, in order to start effective system testing as early as possible, your subsystems must be nearly independent of one another and the interfaces between them must be clean and simple. Remember this when you start the Design Process.

   Third, don’t spread system testing geographically until you’ve reached the point at which the system looks clean and only needs testing against unique site conditions. These conditions may be included modified static databases, geographic location coordinates, varying input and output devices, and varying input loads. Remember that each time you introduce another copy of your system into the test environment, you’ve magnified your change management problems. Because you must include and test every change in one version in all the others, coordination becomes extremely difficult.