5.1 What is Integration Testing?

A system is made up of multiple components or modules that can comprise hardware and
software. Integration is defined as the set of interactions among components.

Definition: Testing the interaction between the modules and interaction with other systems
externally is called integration testing.
 Integration testing starts when two of the product components are available and ends when all component
interfaces have been tested.
 Integration testing is both a type of testing and a phase of testing. As integration is defined to be
a set of interactions, all defined interactions among the components need to be tested.
 The final round of integration involving all the components is called Final Integration Testing (FIT) or
System integration.

5.2 Integration Testing as a Type of Testing

Integration testing means testing of interfaces. There are two types of interfaces.
 Internal Interfaces: Internal interfaces are those that provide communication across two modules within a
project or product, they are internal to the product, and not exposed to the customer or external developers.
 Exported or External interfaces: Exported interfaces are those that are visible outside the product to third
party developers and solution providers.

 One of the methods of achieving interfaces is providing Application programming Interfaces (APIs). APIs
enable one module to call another module.
Eg: Java program uses JDBC API to make certain SQL calls.
 Internal interfaces are for other developers inside an organization and external interfaces are for
third party developers or other users outside the organization.
Testing for internal interfaces requires complete understanding of architecture and High Level Design (HLD)
and how they impact software functionality. Testing for external Interfaces requires understanding of the
purpose of the interfaces, why they are provided and how they are used.
 Some of the interfaces are documented (called as explicit) and some are not (called as implicit).
 Integration testing focuses on both Explicit and Implicit interfaces.
 In most of the cases Integration testing is a Black Box Testing. However in situations, where architecture or
design documents do not clearly explain all the interfaces among components the approach can include
going through the code & generating some additional Test cases & mixing them with other Test Cases. This
approach is called “Gray Box Testing” .

Following diagram shows set of modules and the interfaces associated with them. The solid lines represent
explicit interfaces and the dotted lines represent implicit interfaces. There are at least 12 interfaces between the
modules have to be tested (9 explicit and 3 implicit).
 Following methodologies are used for testing interface.
1. Top down integration
2. Bottom up integration
3. Bi-directional integration
4. System integration
1 Top Down Integration
Definition: Testing the topmost component interface with other components in same order from top to bottom
covering all components is called Top Down Integration.
 In software development process, components become available one after another.
 The components are numbered in the order they become available. The integration starts with testing
the interface between component 1 and component 2. To complete the integration testing, all the interfaces as
mentioned in figure covering all arrows have to be tested.
 Integration Testing pertains only to those new interfaces that are added & those that are affected by the
addition.
 To optimize the no of steps in Integration Testing, multiple steps can be combined & executed as single
step.
 The order in which the interfaces are tested is decided based on the following approaches
 BFS : 1-2,1-3,1-4
 DFS: 1-2-5, 1-3-6

2 Bottom-up Integration
 Bottom-up integration is the opposite of top-down integration, where the components for a new product
development become available in reverse order, starting from the bottom.
 The navigation in bottom-up integration starts from component 1 covering all subsystems, till component 8 is
reached. ( figure 5.3)
 The order in which the interfaces have to be tested is depicted in table 5.2. The number of steps in the bottom-
up approach can be optimized into four steps, by combining steps 2 and 3 and by combining steps 5-8,as
shown in Table 5.2 below.
 As explained before, in top-down integration, for an incremental product development, only the impacted and
added interfaces need to be tested, covering all sub-system components.
 Figure 5.3 Example of bottom-up integration. Arrows pointing down depict logic flow; arrows
pointing up indicate integration paths.

Figure: 5.3

Table :5.2

 The approach selected for Integration depends on Design & architecture, associated priorities,
Availability of components, Process etc, Testing skills.

3. Bi-Directional Integration
 Bi-directional integration is a combination of the top-down and bottom–up integration approaches used
together to drive integration steps.
 Look at figure .In this example, let us assume the software components become available in the order
mentioned by the individual components become available in the order mentioned by the component
numbers.

The individual components1, 2, 3, 4, and 5 are tested separately and bi-directional integration is performed
initially with the use of stubs and drivers. Drivers are used to provide upstream connectivity while stubs
provide downstream connectivity.
A driver is a function which redirects the requests to some other component and stubs simulate the behavior of
a missing component.
After the functionality of these integrated components are tested, the drivers and stubs are discarded. Once
components 6,7 and 8 become available, the integration methodology then focuses only on those components
which need focus and are new, This approach is also called “sandwich integration.”
The steps for integration testing, using this approach is given in table 5.3

(1-7-3-4) –(1-8-5)

As you can see from the table, steps 1-3 use a bottom-up integration approach and step 4 uses
top-down integration approach in this example.

4. System Integration
System integration means that all the components of the system are the 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
 The salient point this testing methodology raises, that of optimization. Instead of integrating component by
component and testing, this approach waits till all component 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.
 System integration using the big bang approach is well suited in a product development scenario where the
majority of components are already available and stable and very few components get added or modified. In
this case, instead of testing component interfaces one by one, it makes sense to integrate all the components
at one go and test once, saving effort and time for the multi-step component integration.
 While this approach saves time and effort, it is also not without disadvantages. Some of the important
disadvantages that can have a bearing on the release dates and quality of a product are as follows.
 Difficult to locate defects.
 Root cause of defect is difficult to pinpoint.
 As it is performed at the end, time pressure may cause the developers compromise with the quality.
 If certain components takes longer to be ready, others time is wasted.
 5.3 Integration Testing as a Phase of Testing
 The integration testing phase focuses on finding defects which arise because of combining various components
for testing, and should not be focused on for component or few components.
 Integration testing as a type focuses on testing the interfaces. This is a subset of the integration testing phase.
When a sub-system or system components are put together (or integrated), the defects not only arise because of
interfaces, but also for various other reasons such as usage, incomplete understanding of product domain, user
errors, and so on.
 Hence the integration testing phase needs to focus on interfaces as well as usage flow.
 This is a testing phase that should ensure completeness and coverage of testing for functionality.
 To achieve this, the focus should not only be on planned test case execution but also on unplanned testing,
which is termed as ―ad hoc testing‖.
 All testing activities that are conducted from the point where two components are integrated to the point where
all system components work together, are considered a part of the integration testing phase.

5.4 Scenario testing

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.
There are two methods to evolve scenarios.
1. System scenario
2. Use-case scenarios/role based scenarios

1 System Scenarios
System scenario is a method whereby the set of actives used for scenario testing covers several
components in the system. The following approaches can be used to develop system scenario.
Story line: Develop a story line that combines various activities of the product that may be executed by an end
user. A user enters his or her office, logs into the system, checks mail, responds to some mails, compiles some
programs, performs unit testing and so on. All these typical activities carried out in the course of normal work
when coined together become a scenario.
Life cycle/state transition: Consider an object, derive the different transition/modification that happen to the
object, and drive scenarios to cover them .for example , in a savings bank account, you can start with opening
an account with a certain amount of money , make a deposit, perform withdrawal, calculate interest, and so on.
All these activities are applied to the “money” object, and the different transformation, applied to the ―money‖
object becomes different scenarios.
Deployment/ implementation stories from customer : Develop a scenario from 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 vertical and
create a set of activities as scenarios to address specific done differently in different vertical like
pharmaceuticals, software houses, and government organization. Visualizing these different type
of tests make the product ―multi-purpose.‖
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.” This adds flavor to the
scenarios mentioned above.

2. Use – case Scenarios

 It is a stepwise procedure on how a user intends to use a system with different user roles & associated
parameters.
 Includes stories, pictures & deployment details.
 Use Cases are useful for explaining customer problems without any ambiguity.
 Can involve class of users who typically perform different activities based on the role.
 In Use case scenarios, users with different roles are called as actors
 Users with a specific role to interact between the actors & the sys are called the agents
  Eg Customer fills up a check & gives it to an official in bank who verifies the balance in the A/c &
gives required cash.

 Customer – Actor
 Clerk – Agent
 Response by computer about balance Amount – System response.
 This way of describing roles in test cases helps in testing the product without going into the details of
the product.
 The act by actor & the agent can be tested by the testers who do not have much knowledge of the
product.
 Simulating diff types of users needs understanding of business & implementation of the product.
 Testers who have in depth knowledge of the product can perform system behavior part of testing. They
need to know logic of the code & response of the system.

Agent part of the use case is not needed in all the test cases. Eg Cash withdrawal using ATM

5.5. Defect Bash

 A defect bash is an ad hoc testing, done by people performing different roles in the same time duration
during the integration testing phase, to bring out all types of defects that may have been left out by planned
testing.
 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.
Defect bash brings together plenty of good practices that are popular in testing industry. They are as follows.
1. Enabling people ―Cross boundaries and test beyond assigned areas‖
2. Bringing different people performing different roles together in the organization for
testing—―Testing isn’t for testers alone‖
3. Letting everyone in the organization use the product before delivery—―Eat your own dog food‖
4. Bringing fresh pairs of eyes to uncover new defects—―Fresh eyes have less bias‖
5. Bringing in people who have different levels of product understanding to test the product
together randomly—―Users of software are not same‖
6. Let testing doesn’t wait for lack of/time taken for documentation—―Does testing wait till
all documentation is done?‖
7. Enabling people to say ―system works‖ as well as enabling them to ―break the system―—
‖Testing isn’t to conclude the system works or doesn’t work‖
It involves several steps.
Steps 1 Choosing the frequency and duration of defect bash
Steps 2 Selecting the right product build
Steps 3 Communicating the objective of each defect bash to everyone
Step 4 Setting up and monitoring the lab for defect bash
Step 5 Taking action and fixing issues
Step 6 Optimizing the effort involved in defect bash

1 Choosing the Frequency and Duration of Defect Bash

Defect bash is an activity involving a large amount of effort (since it involves larger a number of
people) and an activity involving huge planning (as is evident from the above steps). Frequent
defect bashes will incur low return on investment, and too few defect bashes may not meet the
objective of finding all defects.
2 Selecting the Right Product Build
Since the defect bash involves a large number of people, effort and planning, a good quality build is needed for
defect bash. An intermediate build where the code functionality is evolving or an untested build will make the
purpose and outcome of a defect bash ineffective.
3 Communicating the Objective of Defect Bash
Even though defect bash is an ad hoc activity, its purpose and objective have to be very clear.
Since defect bash involves people performing different role. The objective should be to find a large number of
uncovered defects or finding out system requirements (CPU, memory, disk, and so on) or finding the non-
reproducible or random defects, which could be difficult to find through other planned tests.
4 Settling Up and Monitoring the Lab
Finding out the right configuration, resources (hardware, software, and set of people to perform defect bash)
are activities that have to be planned carefully before a bash actually starts. Since the effort involved is more, it
is critical to ensure that the right setup is done, so that everyone can perform the desired set of activities on the
software. There are two types of defects that will emerge during a defect bash. The defects that are in that
are in the product, as reported by the users, can be classified as functional defects. Defects that
are unearthed while monitoring the system resources, such as memory leak, long turnaround
time, missed requests, high impact and utilization of system resources, and so on are called nonfunctional
defects.
5 Taking Action and Fixing Issues
The last step is to take the necessary corrective action after the defect bash. Getting a large
number of defects from users is the purpose and also the normal end result from a defect bash.
Many defects could be duplicate defect. However, different interpretation of the some defect by
different users, and the impact of the same defects showing up differently in different places,
makes them difficult to be called duplicates.
6 Optimizing the Effort Involved in defect Bash
Having a tested build, keeping the right setup, sharing the objectives, and soon, to save effort and meet the
purpose have been already discussed. Another approach to reduce the defect bash effort is to conduct ―micro
level‖ defect bashes before conducting one on a large scale. Hence, a defect bash can
1. Feature/ component defect bash
2. Integration defect bash
3. Product defect bash
Advantages:
 Enables people test beyond assigned areas.
 Allows testing by different people with various roles.
 Letting everyone in the organization use the product before delivery.
 Brings fresh people to uncover new defects.
 Need not wait for documentation.