Summary of article: Len DiMaggio, "Orchestrating Integration Testing", STQE Magazine July/August 2003.

Systems are put together from components supplied by many parties. They may also be distributed.
The general question: Which variables in local systems can have which impact globally? Normally, they should have been identified in the design. But some are not. If the system is composed of many components, both COTS and specially developed ones, the integration test just has to proceed and variables identified during the test, from system logs. Run transactions through the system, check their results, and have all logging facilities on. The logs will contain information on.

Change the variables:

Exchange databases with other vendor's ones. Exchange versions. Exchange network support... See if something bad happens when doing legal operations of such kind.

Database compatibility

Maybe several databases, supplied by several vendors. Not all support all data types or all in the same way. DATE is especially bad.

Inter program dependencies and start order

Some processes on one machine may depend on other processes on other ones. For example application server on database server. Could this go wrong? Naive users starting the whole thing up? Initializing processes taking too long time?

Installation and configuration

Directories, files and environment variable settings (including PC registry) common to multiple integrated subsystems should not be in conflict. (One subsystem requiring a differing value from another for the same variable).