Answer.

Manual integration testing is an important stage in the software life cycle, conducted after unit testing. Its goal is to ensure that individual modules or components of the system interact correctly with each other.

Background: Initially, software testing was performed in phases: first, individual modules (unit tests) were checked, followed by testing the entire system. However, in practice, it became clear that most critical bugs arise precisely at the junction between modules. This led to the need for integration testing, which manually identifies inconsistencies in the behavior of different parts of the system.

Problem: The main difficulty is insufficient elaboration of interaction scenarios between modules and forgotten interdependencies. This leads to "invisible" bugs: everything works correctly during isolated testing, but failures occur after integration (for example, incorrect data handling between the API and the database).

Solution: Proper organization of manual integration testing includes:

Analyzing the system architecture and building a map of component interactions.
Developing integration test cases based on user scenarios and edge case data.
Simulating partial failures (for example, the failure of one of the services) and assessing the response of the entire system.
Documenting the results and recording dependencies between bugs.

Key features:

Maintaining an up-to-date architectural diagram.
Considering all hidden and explicit dependencies between parts of the system.
Paying special attention to data transfer and transformation scenarios at the junctions of modules.

Tricky questions.

What is the difference between integration and system manual testing?

Integration testing focuses on testing the connections between specific modules, while system testing checks the entire system as a whole from the perspective of its business functionality.

Should real external services be used during integration testing, or are emulators sufficient?

For critical integrations, a real environment is preferable, but one can start with emulators (mock/stub). Final testing should be conducted in an environment as close to PROD as possible.

Can all integration errors be discovered only through automation?

No: some defects are only detected manually when the tester notices non-obvious issues in data exchange business logic or in user scenarios not covered by automation.

Common mistakes and anti-patterns

Lack of a clear list of integration points.
Conducting tests without isolating the environment.
Insufficient detail in integration test cases.

Real-life example

Negative case

Integration testing between the payment module and the orders module was conducted only after all other tests were completed and without separate documentation.

Pros:

Time savings on preparing test cases.
Quick launch of tests without complex coordination.

Cons:

Serious bugs leaking into production related to double charging.
Release delays for fixing found bugs at the last moment.

Positive case

Integration scenarios were documented from the outset, and test data closely matched real user tasks.