While unit testing verifies each module or unit individually, integration testing validates that all of the units work well together. It tests the communication paths between modules, either in smaller aggregates or the entire system as a whole. The purpose of this kind of testing is to verify the requirements of major items, or groups of units. Here’s an easy-to-understand example of integration testing: eBay and PayPal are two independent applications, but when you make a purchase on eBay, you’re offered the option of paying with PayPal. Testing this communication between the two applications is an example of integration testing. A further example is the confirmation email you receive from one or both systems after your purchase and payment is complete.

There are different types of integration testing. Big bang, where all of the modules are tested as a whole. Top-down or bottom-up, where low or top level modules are integrated and tested one by one. Or even a combination of the former two, called sandwich testing. Some of these integrations may be in-house developed units, or they could be third party items such as libraries, web services, or DBMS.

Defects found in this kind of testing are generally related to inter-process communication or parameter and data inputs. Two units may have passed unit testing and work well as individuals, but fail to communicate vital information with one another. By testing the units in aggregate, it’s easier to identify the source of the issues.

QA Mentor’s Application Architecture Inspection Services as well as our Testing Execution On-Demand Service can be used to perform Integration testing either after or independent of unit testing. We can provide your team with the necessary expertise and oversight to fix flaws in your module communication, with the goal to catch the errors early, reduce your costs, and lower your risks.