What Is Integration Testing in Manual Testing?

Integration testing in manual testing is the practice of combining two or more unit-tested modules and verifying, by hand, that they work together correctly. Instead of writing automated scripts, a tester drives real scenarios through the user interface or APIs and confirms that data passes accurately from one module to the next, that interfaces behave as agreed, and that errors are handled cleanly across module boundaries. It sits after unit testing and before system testing, and its whole purpose is to expose defects that only appear when independent pieces of an application start talking to each other.

Why Integration Testing Matters in Manual Testing

A module can pass every unit test and still break the moment it is wired to its neighbours. Unit testing proves that a piece of code is internally correct; it says nothing about whether the data one module sends is the data another module expects. Integration testing fills exactly that gap. It is the bridge between unit testing, which looks inward at a single component, and system testing, which looks at the application as a whole.

Doing this manually gives a tester direct, observational control. You can follow a value as it leaves one screen, lands in a backend service, and reappears on another screen, and you can stop the instant something looks wrong. That hands-on visibility is why integration defects, mismatched data formats, broken API contracts, missing error messages, are so often caught first during manual integration testing, well before they reach end users.

What You Actually Test During Manual Integration Testing

Integration testing is about the seams between modules, not the inside of any one module. When testing manually, you focus your attention on the points where components hand work to one another.

• Interfaces and contracts: Confirm that each module calls the next with the parameters, formats, and sequence the receiving module expects, and that the response matches the agreed contract.
• Data passing: Follow values across the boundary and check that type, format, precision, and completeness survive the trip. A date, a currency amount, or a user ID should arrive intact and unaltered.
• Error and exception handling: Force one module to fail or return bad data and verify that the next module degrades gracefully, surfaces a clear message, and never silently corrupts the workflow.
• API responses: When modules talk over APIs, validate status codes, payload structure, and how the consuming side reacts to success, empty, and error responses.
• UI-to-backend flow: Drive an action from the interface and confirm it reaches the right service, updates the right store, and reflects back on screen, the full round trip that real users depend on.

Manual Integration Testing Approaches

The order in which you combine modules is your integration strategy. The same strategies apply whether you test manually or with automation, the difference is simply that a tester executes the scenarios and inspects the results by hand.

• Big-bang integration: Wait until every module is ready, combine them all at once, and test the assembled application as a whole. It is simple and needs no stubs or drivers, but defects surface late and are hard to pin to a specific interface. It suits small systems where all components are available together.
• Top-down integration: Start with the top-level, controlling modules and work downward through the hierarchy. Lower modules that are not built yet are replaced by stubs. This validates the main control flow and high-level logic early.
• Bottom-up integration: Start with the lowest-level modules, such as data access or utility functions, and work upward. Higher modules that are not ready are replaced by drivers. Foundational logic is verified first and grows toward the UI.
• Sandwich (hybrid) integration: Run top-down and bottom-up at the same time, meeting in a middle layer. It uses both stubs and drivers and is favoured for large systems built by several teams in parallel.

Integration Approaches at a Glance

Stubs and Drivers Explained

In incremental integration you rarely have every module finished at the same time. Stubs and drivers are temporary, throwaway pieces that stand in for the parts that are not ready yet, so testing can begin sooner.

• Stub: A dummy called (lower-level) module. It returns fixed, simulated responses so the higher module that depends on it can be tested before the real lower module exists. Stubs are the tool of top-down integration.
• Driver: A dummy calling (higher-level) module. It invokes a lower module and feeds it inputs so that lower module can be tested before its real caller is built. Drivers are the tool of bottom-up integration.

Neither is part of the shipped product. They exist only to satisfy a missing connection during testing and are removed once the real module is integrated.

A Manual Integration Testing Example

Consider an e-commerce checkout built from three modules: a Cart module, a Payment module, and an Order module. Each has passed its own unit tests. A manual integration test confirms they cooperate end to end.

• Add two items to the cart and proceed to checkout.
• Verify the line items, quantities, currency, and total handed from the Cart module into the Payment module are exactly what the cart displayed.
• Complete a successful payment and confirm the Payment module's response is correctly consumed by the Order module, producing an order with the right amount and items.
• Repeat with a declined card and verify the Payment module's failure is surfaced as a clear error, and that no order is created in the Order module.
• Check that an inventory or pricing change in the Cart module is reflected downstream rather than using stale data.

Every step exercises the data passing and error handling between modules, which is exactly what unit testing cannot reach and what integration testing exists to catch.

Manual vs Automated Integration Testing

Manual integration testing is flexible and needs no scripting, which makes it ideal for new or frequently changing interfaces, exploratory checks, and UI-driven flows that are awkward to automate. Its weaknesses are speed and repeatability: re-running a large manual suite every build is slow and error-prone. Automated integration testing reverses that trade-off, it is fast, consistent, and slots into a CI/CD pipeline, which is what you want for stable, high-frequency regression paths.

Manual integration testing makes the most sense early, when interfaces are still settling, when a flow runs only occasionally, or when the cost of building and maintaining automation outweighs the benefit. As the integration points stabilize, teams typically automate the repetitive paths and reserve manual effort for new and exploratory scenarios. When those automated checks need to run across many browsers, devices, and operating systems, a cloud testing platform such as lets you scale the same integration scenarios across real environments and wire them into CI/CD without managing local infrastructure.

Frequently Asked Questions

What is integration testing in manual testing?

It is when a tester manually combines two or more unit-tested modules and checks, by hand, that they work together correctly. The tester drives real scenarios through the UI or APIs and verifies that data passes accurately between modules, interfaces behave as expected, and errors are handled across module boundaries, all without an automation framework.

How is integration testing different from unit testing?

Unit testing checks a single module in isolation to confirm its internal logic is correct. Integration testing checks the connections between modules, verifying that data, calls, and responses flow correctly when those modules are combined. A module can pass unit testing yet still fail integration testing if its interface does not match what another module expects.

What are stubs and drivers in integration testing?

A stub is a dummy lower-level module that returns canned responses so a higher module can be tested before the real one is ready; stubs are used in top-down integration. A driver is a dummy higher-level module that calls a lower module and feeds it inputs so the lower module can be tested before its real caller exists; drivers are used in bottom-up integration.

Which integration testing approach should I use?

Use big-bang for small systems where every module is ready at once. Use top-down when the high-level control flow is built first and you want to validate the main workflow early. Use bottom-up when foundational modules such as data access are ready first. Use sandwich (hybrid) on large systems to combine top-down and bottom-up so middle layers are exercised from both directions.

When does manual integration testing make sense?

Manual integration testing fits early or one-off integrations, exploratory checks, UI-driven flows that are hard to script, and interfaces that are still changing frequently. In these cases the flexibility of testing by hand outweighs the cost of building and maintaining automation.

Should integration tests be manual or automated?

Both have a place. Manual integration testing is flexible and needs no scripting, which suits new or volatile interfaces and exploratory work. Automated integration testing is fast, repeatable, and fits CI/CD, which suits stable, high-frequency, and large regression suites. Most teams start manual and automate the stable, repetitive paths over time.

• Who Does Integration Testing?
• What Is Integration Testing in Software Testing?
• What Is Bottom Up Integration Testing?
• Difference Between Unit Testing and Integration Testing
• When Should You Run Integration Testing?