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.
During the unit testing phase of this testing, we test each module separately. After that, components are combined gradually and checked to make sure the interface and interactions between them are seamless.
Instead of integrating the entire system at once and then testing the final product, this method combines each module gradually, that is, one by one, until all modules or components are added logically to build the desired application. To guarantee successful integration and data flow between modules, integrated modules are tested collectively.
Checking the interface, integrated links, and information flow across modules is the main goal of this testing, just like in integration testing. Until the components are successfully integrated and tested, this process is repeated.
Example
Let’s understand this concept with an example:
The system or software application consists of the following Modules:
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
- The rest of the Modules are also added incrementally to each step and tested for successful integration
Fig2
Fig3
Fig4
Objective of Incremental Test
- Ensure that different modules work together successfully after integration
- Identify the defects earlier and in each phase. This gives developers an edge in identifying where the problem is. For example, if testing after M1 and M2 is integrated is successful but when M3 is added, the test fails; this will help the developer in segregating the issue
- Issues can be fixed early in the phase without much rework and at less cost
Incremental Integration Testing Methodologies
Before we start with this topic, I would 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 a 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.
Some of us may wonder why testing should not begin until all application modules have been developed rather than using a stub or driver.
The short answer is that because testers will stay inactive until all the modules are produced, it lengthens the time needed to complete the project. This also makes it challenging to identify the underlying causes of flaws. Big-Bang Integration testing is the name given to this kind of testing methodology.
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 the application are tested first.
This approach follows the structural flow of the application under testing. Unavailable or undeveloped 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 Incremental Integration Testing Approach
The 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”.
The 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 to architecture defects
- It outlines the working of an application as a whole in early stages and helps in early disclosure of design defects
- The main control points were tested early
De-Merits of Top-down Methodology
- Significant modules were tested late in the cycle
- It can be quite challenging to write test conditions
- The stub is not a perfect implementation of the related Module. It just simulates the data flow between the two modules
#2) Bottom-up
This method involves testing from the bottom up, meaning that modules at the bottom layer are integrated and tested first, followed by the integration of other modules as we go up. Drivers take the place of modules that are unavailable or underdeveloped.
For a clearer understanding, look at the example below:
Since module ranks, marks, percentages, and sports grades are not yet produced, the following drivers will be used in their place:
Bottom up Incremental Integration Testing Approach
The 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
The Merits of Bottom-up Methodology
- This methodology is very useful for applications where bottom up design models are used
- It’s easier to create test conditions in the 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 an early stage
De-Merits of Bottom-Up Methodology
- Drivers are more difficult to write than stubs
- Design defects are caught in the later stage
- In this approach, we do not have a working application until the last module is build
- The driver does not have a complete implementation of the 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. Stubs and drivers are used for incomplete or undeveloped modules.
Testing Approach
- The middle layer is identified from which bottom-up and top-down testing are done. This middle layer is also known as the 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 with the middle layer and moves downwards towards the lower level modules. The layer below the middle layer is known as Bottom layer
- Bottom-up testing also starts with the middle layer and moves up towards the top layer modules. The layer above the middle layer is known as Top layer
- With the use of stubs and drivers, the user interface and functions of lower level modules are tested respectively
- In the end, only the middle layer is left for the execution of the final test
Example:
The following test cases can be derived from the 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 be run side by side
De-merits of Sandwich Testing Methodology
- Before module unification, subsystems and their interfaces were 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
Conclusion
Integration testing is the umbrella term for incremental testing. In this testing methodology, integration testing is carried out on each module as part of unit testing. In the subsequent phase, application modules or components are merged gradually, and testing is done on the combined modules collectively.
The structure of the application and the location of high-risk modules determine which of the three Incremental Integration Testing approaches should be used.
All three methodologies for incremental testing come under the Horizontal category because of the following behavioral aspects:
- All three methodologies focus on layer testing
- All of them consider a structural or hierarchical design
- They all integrate layers incrementally
Merits:
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.
Demerits:
This type of testing approach is time-consuming because of the use of stubs and drivers. It is also repetitive.
About the author: This helpful tutorial is written by Neha B. She is an ISTQB certified Lead Quality Analyst with 8+ years of experience.
YOU MAY BE INTERESTED IN
The Art of Software Testing: Beyond the Basics
Automation testing course in Pune
Automation testing in selenium
Mastering Software Testing: A Comprehensive Syllabus
Frequently Asked Questions
What is incremental testing in software development?
Incremental testing is a software testing approach where the application is tested incrementally, with each module or component being tested separately before being integrated into the larger system. This approach helps identify and fix defects early in the development process, reducing the overall cost and time required for testing. By testing each component separately, developers can ensure that each part of the system works correctly before combining them.
How does incremental testing differ from other testing approaches?
Incremental testing differs from other testing approaches, such as big bang testing, in that it involves testing each component or module separately before integrating them into the larger system. This approach allows for faster identification and resolution of defects, as well as reduced risk of downstream problems. It also enables developers to test and validate each component in isolation, before integrating them with other components.
What are the benefits of using incremental testing in software development?
The benefits of using incremental testing include early defect detection, reduced testing time and cost, and improved overall quality of the software system. Incremental testing also allows for faster time-to-market, as each component or module can be tested and validated separately, before being integrated into the larger system. This approach also enables developers to make changes and improvements to individual components without affecting the entire system.
How do I implement incremental testing in my software development project?
To implement incremental testing, start by breaking down the software system into smaller components or modules, and then create a testing plan for each one. Identify the testing requirements and create test cases for each component, and then test each component separately before integrating them into the larger system. Use automated testing tools and techniques to streamline the testing process and reduce the time and effort required.
Can incremental testing be used in agile software development methodologies?
Yes, incremental testing can be used in agile software development methodologies, such as Scrum or Kanban. In fact, incremental testing is well-suited to agile development, as it involves testing each component or module separately before integrating them into the larger system. This approach allows for faster and more flexible testing, which is consistent with the principles of agile development.
