Integration Testing

A typical assembly line process involves assembling separated units to form a single functional unit. For example: Assembling a car involves putting in various parts together and then testing the final product. It is important to note that the individual parts have been already tested and verified before they were set up for car assembly. But it is also imperative that those units work together in sync for the car to work as per the desired standards and specifications. That’s where the test run comes into the picture.

Similarly, in the world of software, the whole project is broken down into a number of units/modules for the ease of development. The modules are then developed and tested by the teams assigned to them. There are times when these units are perfectly functional on their own when tested in isolation. But there might be issues in inter-modular interactions when they are plugged in together to test a combinatorial behavior. 

Integration testing is the level of testing that identifies module interfacing issues due to integration testing the integrated modules as a single unit. 

Either of the testing methods, Black box, white box or Grey box can be applied for Integration testing depending on the type of modules under test.

Why is Integration testing required?

Let us take a look at the scenarios which give rise to the need for Integration testing.

• During the course of software development, the requirements may change over a period of time. In that case, some (not necessarily all) modules may get impacted. While implementing those changes, chances are that the interfacing between the modules gets affected. Integration testing steps in to handle such cases.
• Multiple people work on various modules. Each of them has a different way of handling code logic. Extra care is required while integrating modules so that correct parameters are passed between the modules. Also, the final code logic needs to be cohesive for a correct end result. Integration testing takes care of these situations.
• Interaction with third-party plugins has to be handled carefully. The integration of such tools or APIs has to be tested thoroughly to ensure that the desired functions are performed with correct inputs.
• In some cases, inadequate exception handling in one module may have a catastrophic effect in another module. Such scenarios need to be carefully examined and handled while integration.

Approaches for Integration Testing

Besides these commonly known Integration testing techniques, there are some lesser-known ones like Coupling-based integration testing, Interaction-based integration testing ─ a functional testing technique, distribution services Integration testing, backbone integration, client/server integration, layer integration, etc.

Big Bang Approach

In this method, all the units/modules are combined together and tested in one go. This sounds very similar to System testing. But the Big bang approach to integration testing handles the interactions between the modules and verifies the end result. It works best for small scale projects.

However, it has certain drawbacks.

• Fault localization becomes a challenge.
• There are chances of missing some interfacing issues due to multiple modules talking to each other at the same time.
• There may be time constraints since testing is executed once all modules are integrated. These constraints may lead to lower quality tests.
• The quantum of time ideally needed to test critical modules may get impacted.

Incremental Approach

An incremental approach, as the name suggests, tests the related modules by combining them incrementally. The process continues until all the modules have been integrated and tested successfully. It is important to consider the fact that all related modules may not be ready at the same time during testing, so dummy modules called Stubs and Drivers are used to simulate the logical connection and data communication between modules under test.

A Stub is a dummy module called by module under test.

A Driver is the dummy module that calls the module under test.

There are three sub approaches in incremental integration testing.

• Top-down approach
• Bottom-up approach
• Hybrid or Sandwich approach

Top-down Approach

In this approach, the top-level module is tested first and lower-level modules are integrated incrementally and tested. In this case, test stubs are used to simulate lower-level modules that may not be available when higher-level modules are tested. 

Top-down approach has two further sub-types: Depth-first and Breadth-first.

Advantages:

• Fault Localization is easier.
• It is possible to get a prototype earlier in software development.
• Critical Modules are tested on priority and any flaws can be rectified on accordingly.

Disadvantages:

• Many stubs are needed to simulate lower-level modules.

Bottom-up Approach

In this approach, bottom level modules are tested first and then incrementally level above are tested. Test drivers are needed to simulate the higher-level modules which may not be available during testing.

Advantages:

• Fault Localization is easier.

Disadvantages:

• An early prototype is not possible.
• Critical modules on top of module hierarchy controlling the program flow are tested in the end. This may leave room for errors.

Hybrid / Sandwich Approach

Hybrid approach is a combination of Top-Down and Bottom-Up approach.

Advantages:

• Useful for large projects which involve several sub-projects

Disadvantages:

• High cost in terms of time and resources.

Best Practices and guidelines for Integration Testing

• Identification of critical modules to be tested on priority.
• Complete unit testing of these modules before starting integration testing.
• Identify appropriate Integration test strategy and preparation of test cases accordingly.
• Create test cases to cover and verify all module interfaces and interfaces with external API’s/Databases/Third-party tools.
• Automate test cases wherever possible.

Conclusion

Integration testing adds on to the unit testing by providing test coverage and helps in sealing any gaps that are left because of issues in module interactions. Clearly, it is a very crucial part of the Software Development and testing life cycle. Automating the integration tests further helps in optimizing the testing process.

At Webomates, we offer tools/services that help our clients to validate those small pieces of code through end to end regression tests before deploying the build to production. Tools like QA-Assist and services like CI/CD can very quickly help the developers to fix the issues and deploy code to a product without much hassle.

Webomates has also optimized the testing process by combining patented selenium based Automation and Artificial Intelligence with crowdsourcing and manual testing. These services help in providing good results if applied to Integration test cases.

If you are interested in learning more about Webomates CQ service please click here and schedule a demo or reach out to us at info@webomates.com

Tags: Black Box Testing, integration Testing, Software Testing, White Box testing