What
Testing performed to expose faults in the interfaces and in the interaction between integrated components.
BS 7925-1.British Computer Society Specialist Interest Group in Software Testing (BCS SIGIST)

The above definition only refers to "integrated components." This is known as "integrtion testing in the small". Thus checking that widget A, when integrated with widget B generates a bleep, after a given input, constitutes integration testing.

"Integration testing in the large" refers to the whole systems being joined. For example checking that a Payroll system interacts as required with the Human Resources system.

The two extremes shown here mean that integrated testing can appear virtually anywhere along the V Model.

Integration testing connects with many other designs and techniques. Including Black Box Testing, Alpha and Beta Testing.

Why?
I see three main reasons to conduct Integrated testing.

1) To find faults that could not have been found in the component testing because, they only become apparent when components are integrated. (Rather they should only be found at integration.)

2) To generate credible information about the software under test, so that technical and business decisions can be made.

3) Confirm that as the system grows risk of failure is being diminished.

Who?
As integration testing covers such a broad length of the V model, it is not surprising that a large range of people should be conducting it. From the developer who joins 2 widgets together to make a tiny subsystem, to the systems integrator who has to join the systems up on the customer site.

Where?
Almost all integration will take place at the developing organisations site.

When?
Once the components or sub-systems, to be integrated have themselves been fully component tested. If any are not ready to be integrated, this is not necessarily a problem as their functionality can be simulated.

How?
Integration testing can either be conducted incrementally (see for more detail or non-incrementally.

The non-incremental approach is also non as "big-bang" testing. This approach is very unfashionable due to the level of risk that one takes in hoping that the system will perform as expected.

Incrementally, testing can be split into top-down testing and bottom-up testing. Middle-out is another variation.

In top-down testing, higher level modules are tested. If lower modules required to make up the system are not yet available then, stubs are used to simulate their activity.

Conversely Bottom up testing, tests the lower levels first. If the higher level modules required to make up the system are not yet available then, drivers are used to simulate their activity.

Testing that can be undertaken on the now integrated system are both functional and non-functional.