Integration testing means testing of interfaces. Integration testing is done with test cases, which goes through the internal or external interfaces, and tests the functionality of the product. External interfaces are those that expose modules /methods / functions of our product with external developers or consumers of our product, while internal interfaces are not exposed to external community and are visible to internal stakeholders of the project or product.
There are several methodologies available to decide the order for integration testing. There are as follows
1. Top-Down Integration
2. Bottom-Up Integration
3. Bi-directional integration
4. Big-Bang integration
This approach involves testing the top most module interface with other modules in the same order as you navigate the system from top to bottom, till you cover all modules. Below testing steps describe how to test the system shown in the top figure of this post.
2. Bottom-Up Integration Approach
This approach is just the opposite of top-down integration, where the components for a new product development become available in reverse order, starting from bottom as shown in below table
Bottom-up integration model is more suited for agile model of development where we expect dynamic change of requirements, design and architecture as we proceed through various iterations.
3. Bi-directional Integration Approach
Bi-directional integration is a combination of the top-down and bottom-up integration approaches used together to derive integration steps.
4. Big Bang System Integration
In above three integration approaches, If you observe:
1. System integration is carried out as part of last step in each of the above three approaches.
2. As all modules are not available till last minutes, we keep integrating modules one by one till all modules arrive to our testing fold. In this process, we observe duplication of testing efforts.
In Big bang System integration approach, we will wait till all modules arrive and then one round of integration is performed in one go. This approach is well suited in a product development scenario where only very few modules got added and rest of the modules are already in stabilized state.
While this approach saves effort and time, it has got below disadvantages
1. When a failure or defect is encountered during system integration, it becomes very difficult to locate the problem
2. When integration happens in the the end, the pressure to the team that deadline is fast approaching may hamper quality of end to end integration testing.
When to choose what Integration methodology?
FAQs about Integration Testing
Question-1] Not all the interfaces may be available at the same time for testing purposes, as different interfaces are usually developed by different development teams, each having their own schedules. How to handle Integration testing in this process?
Answer: In order to test the interfaces, when the full functionality of the component being introduced is not available, we address the context using drivers and stubs. Drivers provide upstream connectivity while stubs provide downstream connectivity. A driver is a function which redirects the requests to some other module and stubs simulate the behaviour of missing component. Stubs simulate the interface by providing appropriate values in the appropriate format as would be provided by the actual component being integrated.
Question-2] In an incremental product development, where one or two modules get added to the product in each increment, what is the scope of integration testing?
Answer: The scope of integration testing can be limited to (1) New interfaces that got added (2) Related interfaces that got impacted because of the introduced change
Question-3] What are different means of achieving integration testing?
Answer: We can achieve interface integration among modules through number of means. Some of the means are listed below.
1. Application Program Interfaces (APIs)
2. Simple function calls that are visible to the calling module
3. Usage of public functions
4. Programming language constructs like global variables
5. Operating System constructs like shared memory