in the organisation, software or any build is divided in to 
different modules assigned by test lead ex: services and 
admin like..
in the services/admin , difreent part of application is 
assign to each tester  and they did the test after that 
combine all parts of application and do the testing on that 
whether it is correctly working on not
usally it done after unit test and funtional testing 
this type of testing relevent to client/server and 
distributed systems . 

i think it is ok but can anybody tell me answer for this 
one.

Integration Testing : Putting groups of units together
1. arises when many new units developed together
2. common for large, well-specified , pre-designed systems
with much new code 
3. not as common for small,rapid-devlepment systems or for
new features

Big-bang integration : putting all units for a program
together at once
1. often produces many interacting errors,problem worse as
size increases

some more gradual , bottom-up or top - down better

Integration Testing having two approches,

Top down : Root to stubs

Bottom up : stubs to Root 

Either any of the two approached will follow usually, which 
means Once all the functional testing is done (unit level ) 
then you have the check the integration which means 
Integrating is combained part of unit.

While doing integration testing , for example if the 
calculated value or string going to be impact in any where 
of the application or data coming from some other server u 
need to check whether the data's are intergrating correctly 
or not.

For Example , While dropping a money from ATM , Once you 
give ur ATM Pin Number , System should redirect into ur 
Account.

Integration Testing having two approaches,

Bottom up : stubs to Root 
Top down : Root to stubs

Integration testing is a logical extension of unit testing.
In its simplest form, two units that have already been
tested are combined into a component and the interface
between them is tested. A component, in this sense, refers
to an integrated aggregate of more than one unit. In a
realistic scenario, many units are combined into components,
which are in turn aggregated into even larger parts of the
program. The idea is to test combinations of pieces and
eventually expand the process to test your modules with
those of other groups. Eventually all the modules making up
a process are tested together. Beyond that, if the program
is composed of more than one process, they should be tested
in pairs rather than all at once.

Integration testing identifies problems that occur when
units are combined. By using a test plan that requires you
to test each unit and ensure the viability of each before
combining units, you know that any errors discovered when
combining units are likely related to the interface between
units. This method reduces the number of possibilities to a
far simpler level of analysis.

You can do integration testing in a variety of ways but the
following are three common strategies:

    * The top-down approach to integration testing requires
the highest-level modules be test and integrated first. This
allows high-level logic and data flow to be tested early in
the process and it tends to minimize the need for drivers.
However, the need for stubs complicates test management and
low-level utilities are tested relatively late in the
development cycle. Another disadvantage of top-down
integration testing is its poor support for early release of
limited functionality.
    * The bottom-up approach requires the lowest-level units
be tested and integrated first. These units are frequently
referred to as utility modules. By using this approach,
utility modules are tested early in the development process
and the need for stubs is minimized. The downside, however,
is that the need for drivers complicates test management and
high-level logic and data flow are tested late. Like the
top-down approach, the bottom-up approach also provides poor
support for early release of limited functionality.
    * The third approach, sometimes referred to as the
umbrella approach, requires testing along functional data
and control-flow paths. First, the inputs for functions are
integrated in the bottom-up pattern discussed above. The
outputs for each function are then integrated in the
top-down manner. The primary advantage of this approach is
the degree of support for early release of limited
functionality. It also helps minimize the need for stubs and
drivers. The potential weaknesses of this approach are
significant, however, in that it can be less systematic than
the other two approaches, leading to the need for more
regression testing.

using Top down,bottom up, hybrid approches we are doing 
integration testing in our organization