What is Integration Testing?

A system is made up of multiple components or modules comprising hardware and software.
Integration is defined as the set of interactions among components.
Testing the interaction between the modules and interaction with other systems externally is called integration testing.
Integration testing is done to make sure that the different components fit together.
The final round of integration involving all components is called Final Integration Testing (FIT), also known as System Integration.
Integration is both a phase and a type of testing.
4 orders of integration testing : Top-down integration, Bottom-up integration, Bi-directional integration, System integration.

Top-Down Integration

Step Interfaces tested

1-2
1-3
1-4
1-2-5
1-3-6
1-3-6-(3-7)
(1-2-5)-(1-3-6-(3-7))
1-4-8
(1-2-5)-(1-3-6-(3-7))-(1-4-8)
The integration starts with testing the interface between component 1 and component 2, then component 1 and 3 and so on.
To optimize the number of steps in integration testing, steps 6 and 7 can be combined and executed as a single step.
Similarly, steps 8 and 9 also can be combined and tested in a single step.

Bottom-Up Integration

Step Interfaces tested

1-5
2-6, 3-6
2-6-(3-6)
4-7
1-5-8
2-6-(3-6)-8
4-7-8
(1-5-8)-(2-6-(3-6)-8)-(4-7-8)
Bottom-up integration is just the opposite of top-down integration, where the components for a new product development become available in reverse order, starting from the bottom.

Bi-Directional Integration

Step Interfaces tested

6-2
7-3-4
8-5
(1-6-2)-(1-7-3-4)-(1-8-5)
Bi-directional integration is a combination of the top-down and bottom-up integration together to derive integration steps.
Comes handy when migrating from a two-tier to a three-tier environment.

System Integration

System integration means that all the components of the system are integrated and tested as a single unit.

Integration testing, which is testing of interfaces, can be divided into two types:

Components or sub-system integration
Final integration testing or system integration

Instead of integrating component by component and testing, this approach waits till all components arrive and one round of integration testing is done.

This approach is also called big-bang integration. It reduces testing effort and removes duplication in testing.

Big bang integration is ideal for a product where the interfaces are stable with less number of defects.

While this approach saves time and effort, it is also not without disadvantages:

When a failure or defect is encountered during system integration, it is very difficult to locate the problem, to find out in which interface the defect exists. The debug cycle may involve focusing on specific interfaces and testing them again.
The ownership for correcting the root cause of the defect may be a difficult issue to pinpoint.
When integration testing happens in the end, the pressure from the approaching release date is very high. This pressure on the engineers may cause them to compromise on the quality of the product.
A certain component may take an excessive amount of time to be ready. This precludes testing other interfaces and wastes time till the end.

Choosing Integration Method

Factors	Suggested Integrated Method
Clear requirements and design.	Top-down
Dynamically changing requirements, design, architecture.	Bottom-up
Changing architecture, stable design.	Bi-directional
Limited changes to existing architecture with less impact.	Big bang

Integration Testing as a Phase of Testing

Starts from the point where two components can be tested together, to the point where all the components work together as a complete system, delivering the product functionality.
It tests how different components work in isolation and also when they are connected to each other.
Focuses predominantly on defects that arise due to combing various components.
Focuses on interfaces as well as usage flow.
When the functionality of different components are combined and tested together for a sequence of related operations, they are called scenarios.

Scenario Testing

Scenario testing is a planned activity to explore different usage patterns and combine them into test cases called scenario test cases.
Scenario testing is defined as a “set of realistic user activities that are used for evaluating the product.”
It is also defined as the testing involving customer scenarios.
Two methods to create scenarios : System Scenarios & Use-case/Role-based Scenarios

System Scenarios

System scenario is a method whereby the set of activities used for scenario testing covers several components in the system. Follow these approaches :

Story line - Develop a story line that combines various activities of the product that may be executed by an end user.
Life cycle/state transition - Consider an object, derive the different transitions/modifications that happen to the object, and derive scenarios to cover them.
Deployment/implementation stories from customer - Develop a scenario from a known customer deployment/implementation details and create a set of activities by various users in that implementation.
Business verticals - Visualize how a product/software will be applied to different verticals and create a set of activities as scenarios to address specific vertical businesses.
Battle ground - Create some scenarios to justify that “the product works” and some scenarios to “try and break the system” to justify “the product doesn't work.”
These approaches have to be used in combination, not in isolation

Use Case Scenarios

A use case scenario is a stepwise procedure on how a user intends to use a system, with different user roles and associated parameters.

Defect Bash

Defect bash is an ad hoc testing where people performing different roles in an organization test the product together at the same time.
Ad hoc testing means that the testing is unplanned.
The testing by all the participants during defect bash is not based on written test cases.
What is to be tested is left to an individual's decision and creativity.

Good Practices Encouraged By Defect Bash

Enabling people cross boundaries and test beyond assigned areas.
Bringing different people performing different roles together in the organization for testing. Testing isn't for testers alone.
Letting everyone in the organization use the product before delivery.
Bringing fresh pairs of eyes to uncover new defects.
Bringing in people who have different levels of product understanding to test the product together randomly.
Let testing doesn't wait for lack of/time taken for documentation.
Enabling people to say “system works” as well as enabling them to “break the system”.

All the activities in the defect bash are planned activities, except for what to be tested. It involves several steps: