Thus, the hand-off of a unit of code into an integration or build phase should include, at an absolute minimum, a list of the conditions that were tested so that the test group need not repeat them and future developers can repeat and expand them. The next level of testing, integration, concerns itself with the merger of units into a functioning whole, whether it's a subsystem or complete application. Usually the integration process, also called the build process, produces an executable system. Perhaps not surprising, but nevertheless disturbing, is the fact that this level of testing is also almost exclusively informal. Victory is often declared if the build compiles successfully.
Tiny differences can cause a domino effect throughout the system.
Without an orderly integration test process, performed by knowledgeable system architects, further testing is continually at risk for functionality to be dropped or broken from one build to the next. Thus, an acceptable integration test hand-off should include the list of configuration options and interfaces tested and the pertinent conditions for each. Although unit and integration testing are commonly understood to belong to development, the system test is where it begins to get hazy. It serves as the ultimate integration test, assuring that all units and subsystems behave as a coherent whole when installed on the test platform as opposed to the development environment. Its purpose is to prove that the system has sufficient technical integrity to enable business functionality to be verified.