Who is responsible for integration testing?

Component integration testing

Component integration testing is the process of ensuring that individual units of code interact together according to specifications. Sometimes this is called component unit testing; that terminology, however, can be misleading, as component integration testing is distinct from unit testing.

Unit testing is the lowest level of testing. It is used to verify that each individual piece of code functions as designed. Narrow in scope and usually automated, unit testing is done on the developer's own branch prior to being pulled into the main line.

Component integration testing has a broader focus. Its purpose is to verify the interactions between modules and ensure that all components work together as intended. Automated component testing is an effective way to find defects early and build in quality. When components are written by multiple developers working independently of each other, the component integration test usually takes place as a part of the continuous integration process or in a specific integration environment.

Who will perform integration testing depends on a company's practices and preferences.

Who will perform integration testing depends on a company's practices and preferences. In most organizations, component integration testing is the responsibility of the developer. However, in organizations that have implemented test-driven development, testers may be involved. In this scenario, the tester would be responsible for the development of the test scenarios and the developer would be responsible for the writing the script for the test. In an Agile or DevOps environment, the testers could be responsible for the component integration testing, especially if they are software development engineers in test.

In situations where the module under test is complex, it may be useful to involve a tester or another developer in the component integration test in order to find defects as early as possible.

Systems integration testing

Systems integration testing has a more comprehensive scope. Systems integration testing focuses not only on all of the workflows through the application, but also on the integrations and interactions with other applications. In the spirit of quality engineering, i.e., building in quality from the start, it is best to begin systems integration testing as the modules of the workflows are completed and component tested. In addition, APIs should be tested as early in the development process as possible.

Systems integration testing should conclude with an end-to-end test of all functionality and data flows. Upstream and downstream applications that provide and accept data from the application under test must be a part of this test. Hardware as well as any embedded testing that is required should be included in the end-to-end systems test. Systems integration testing is black box testing, and can be manual or automated.

The principles of a sound test automation strategy apply when planning an automated end-to-end test. The automation strategy should follow the automation pyramid with the bulk of automated testing at the unit and component integration levels with less in the functional and end-to-end system test. The test cases and test suites chosen for automation must be optimized to ensure the most test coverage in the fewest number of test cases. This is critical, especially if continuous integration and continuous testing has been implemented. Most importantly, the application must be in a stable condition; if the application is in early phases of development or undergoing major upgrades, the cost of the maintenance required to automate the suite will outweigh its benefits.

In general, system integration testing, especially the end-to-end test, is the responsibility of the testers. To ensure that the end-to-end workflow scenarios test the ways in which users will interact with the application, testers often enlist the product owner or business analyst to help develop the high-level test scenarios or review the end-to-end test cases. This approach can be helpful, as the product owners are closer to the users and have a full understanding of their approach to working with the application under test. To ensure that the most technically complicated workflows are thoroughly tested at this level, it might be helpful to consult developers.

In Agile and DevOps environments, any team member may develop and execute end-to-end tests. Of course, developers should not test their own code. In continuous integration, testers may determine the test scenarios, developers code the automated scripts and release engineers ensure that the tests are implemented into the continuous integration pipeline and results are visible and reviewed by the team.

While it's important to know who is responsible for integration testing, it is also worth recognizing how practices shift over time. As organizations move away from quality assurance and embrace quality engineering, the entire team becomes responsible for quality. All types of testing become a team effort.