What is Incremental Testing: Detailed Explanation With Examples

With the help of this article, I am going to cover one of the important Integration Approach – Incremental Testing.

By the end of this section, the audience will have a fair knowledge of following:

  • What is Incremental Testing?
  • Its Objective
  • Methodologies
  • Advantages
  • Drawbacks

What is Incremental Testing

Incremental Testing, also known as Incremental Integration Testing, is one of the approaches of Integration Testing and incorporates its fundamental concepts.

It is like a test which combines Module and Integration testing strategy.

Incremental Testing

In this testing, we test each module individually in unit testing phase, and then modules are integrated incrementally and tested to ensure smooth interface and interaction between modules.

In this approach, every module is combined incrementally, i.e., one by one till all modules or components are added logically to make the required application, instead of integrating the whole system at once and then performing testing on the end product. Integrated modules are tested as a group to ensure successful integration and data flow between modules.

As in integration testing, the primary focus of doing this testing is to check interface, integrated links, and flow of information between modules. This process is repeated till the modules are combined and tested successfully.


Let’s understand this concept with an example:

System or software application consists of following Modules:

Software Application

Incremental Integration testing approach

  • Each Module i.e. M1, M2, M3, etc. are tested individually as part of unit testing
  • Modules are combined incrementally i.e. one by one and tested for successful interaction
  • In Fig2, Module M1 & Module M2 are combined and tested
  • In Fig3, Module M3 is added and tested
  • In Fig4, Module M4 is added and testing is done to make sure everything works together successfully
  • Rest of the Modules are also added incrementally at each step and tested for successful integration


Combined Two Modules


Combined 3 Modules


Combined Four Modules

Objective of Incremental Test

  • To ensure that different modules work together successfully after integration
  • Identify the defects earlier and in each phase. This gives developers an edge to identify where the problem is. Like if testing after M1 and M2 are integrated is successful but when M3 is added, the test fails; this will help the developer in segregating the issue
  • Issues can be fixed in early phase without much rework and in less cost

Incremental Integration Testing Methodologies

Before we start with this topic, I will like to give a brief intro about Stubs and drivers since we will be using these terms often.

Stubs and drivers are pseudo code or dummy code used in Integration or component testing when one or more modules are not developed but are required to test some other module.

Stubs are used in Top-down testing approach and are known as “called programs”. Stubs help simulate the interface between lower lever modules which are not available or developed.

Drivers are used in Bottom-up testing approach and are known as “calling programs”. Drivers help simulate the interface between top level modules which are not developed or available.

A question that might occur to some of us is why not wait till all the application modules are developed instead of using stub/driver before starting testing?

The simple answer is that it increases the project execution time since testers will be sitting idle till all the modules are developed. Also, this makes the root analysis of defect difficult. This type of testing approach is known as Big-Bang Integration testing.

Now that we have covered Stubs and drivers, let’s move on to different methodologies of Incremental Testing:

#1) Top Down

As the name suggests, testing takes place from top to bottom, i.e., from the central module to sub module. Modules framing the top layer of application are tested first.

This approach follows the structural flow of the application under testing. Unavailable or not developed modules or components are substituted by stubs.

Let’s understand this with an example:

  • Module: Website Login aka L
  • Module: Order aka O
    • Module Order Summary aka OS (Not yet developed)
  • Module: Payment aka P
    • Module Cash Payment aka CP
    • Module Debit/Credit Payment aka DP (Not yet developed)
    • Module Wallet Payment aka WP (Not yet developed)
  • Module: Reporting aka R (Not yet developed)

Top Down Approach

Top down Incremental Integration Testing Approach

Following test cases will be derived:

Test Case1: Module L and Module O will be integrated and tested
Test Case2: Module L, O and P will be integrated and tested
Test Case3: Module L, O, P and R will be integrated and tested.

And so on other test cases are derived.

This type of testing where all modules at a layer are first integrated and tested is known as “breadth-first”. Another category is “depth-first”.

Following test cases will be derived for “depth-first”:

Test Case1: Module L and Module O will be integrated and tested
Test Case2: Module L, O and OS will be integrated and tested
Test Case3: Module L, O, OS, P will be integrated and tested
Test Case4: Module L, O, OS, P, CP will be integrated and tested

And so on other test cases are derived.

Merits of Top-down Methodology

  • Early exposure of architecture defects
  • It outlines the working of an application as a whole in early stages and helps in early disclosure of design defects
  • Main control points are tested early

De-Merits of Top-down Methodology

  • Significant modules are tested late in cycle
  • It is very challenging to write test conditions
  • A stub is not a perfect implementation of related Module. It just simulates the data flow between two modules

#2) Bottom-up

In this approach, testing takes place from bottom to top, i.e., modules at bottom layer are integrated and tested first and then sequentially other modules are integrated as we move up. Unavailable or not developed modules are replaced by drivers.

Let’s look at a below-mentioned example for better understanding:

Modules Rank, Marks, Percentage and Sports Grade are not yet developed so they will be substituted with related Driver:

Bottom Up Approach

Bottom up Incremental Integration testing approach

Following test cases will be derived:

Test Case1: Unit testing of module Practical and Theory
Test Case2: Integration and testing of Modules Marks-Practical-theory
Test Case3: Integration and testing of Modules Percentage-Marks-Practical-Theory
Test Case4: Unit testing of Module Sports Grade
Test Case5: Integration and testing of Modules Rank-Sports Grade-Percentage-Marks-Practical-Theory

Merits of Bottom-up Methodology

  • This methodology is very useful for applications where bottom up design model is used
  • It’s easier to create test conditions in bottom up approach
  • To start testing at the bottom level of hierarchy means testing of critical modules or functionality at an early stage. This helps in early discovery of errors
  • Interface defects are detected at early stage

De-merits of Bottom-up Methodology

  • Drivers are more difficult to write than stub
  • Design defects are caught in the later stage
  • In this approach, we do not have working application until the last module is build
  • Driver is not a complete implementation of related Module. It just simulates the data flow between two modules.

#3) Sandwich Testing

This approach is a hybrid of top-down and bottom-up methodology. Stub and drivers are used for incomplete or not developed modules.

Testing Approach

  • A middle layer is identified from which bottom-up and top-down testing are done. This middle layer is also known as target layer
  • Target layer is identified as per Heuristic approach, i.e., select a layer which allows minimal use of Stubs and drivers
  • Top-down testing starts from middle layer and moves downwards towards lower level modules. This layer below middle layer is known as Bottom layer
  • Bottom-up testing also starts from middle layer and move up towards top layer modules. This layer above middle layer is known as Top layer
  • With use of stubs and drivers, user interface and functions of lower level modules are tested respectively
  • In the end, only middle layer is left for the execution of the final test


Sandwich Testing Example

Following test cases can be derived with Sandwich Testing Strategy:

Test Case1: Test A, X, Y, and Z individually – where Test A comes under Top layer test and Test X, Y and Z comes under Bottom layer tests
Test Case2: Test A, G, H and I
Test Case3: Test G, X, and Y
Test Case4: Test Hand Z
Test Case5: Test A, G, H, I, X, Y, and Z

Merits of Sandwich Testing Methodology

  • It is very beneficial for a big project which has various sub-projects
  • Top-down and bottom-up testing methodology can run side by side

De-merits of Sandwich Testing Methodology

  • Before module unification, subsystems and their interfaces are not tested thoroughly
  • Higher cost due to involvement of both top-down and bottom-up testing methodology
  • This type of testing is not advised for a system where modules are highly inter-dependent


Incremental Testing comes under the blanket of Integration testing. In this approach of testing, integration testing is done on the individual module as a part of unit testing and in next phase, modules or components of the application are integrated incrementally and testing is performed on combined modules as a group.

Out of three methodologies of Incremental Integration Testing, the choice of which methodology to choose depends on the structure of the application and also on the position of high-risk modules.

All three methodologies of incremental testing come under Horizontal category because of following behavioral aspects:

  • All three methodologies focus on layer testing
  • All of them consider a structural or hierarchical design
  • All of them integrate layers incrementally


With this testing approach, it is easier to identify defects early, and it also helps the developer determine the cause of the issue. Since it uses the basics of structured testing, this testing approach is very effective and accurate.


This type of testing approach is time-consuming because of use of stubs and drivers. It is also repetitive.

About the author: This helpful tutorial is written by Neha B. She is ISTQB certified Lead Quality Analyst with 8+ years of experience.

Let us know if you have any questions/suggestions.

Recommended reading


#1 Prakash Gupta

New thing! knew it and I was doing but didn’t know the term. Thank you for sharing.

#2 Prathibha

@ Prakash
Yes, these are the terms which we use in our routine testing activities but don’t know the exact terms or the technical process behind it. That’s where the posts like these can help.

#3 Hoshang Gandhi

Best to learn new things, there are many things which we use in day to day testing but don’t know the terms which gets cleared out here. Even we come across new terms and definition which is very useful to increase our knowledge resource and can share with our friends also.
Thanks a lot. Great Job.
Please let us know if there is any possibility that we can also share our knowledge in some or the other way.

Leave a Comment