Oleksandr - Fotolia
Boost QA velocity with incremental integration testing
The longer it takes to perform tests, the less Agile your team is. Here are four common approaches to integration tests that help reduce bottlenecks and delay.
An application doesn't simply exist on an island. Modern apps are often complex, multicomponent builds, and testers must verify those individual elements can communicate effectively between each other.
Integration testing, also called string testing, validates the connectivity and flow of data between two or more components and identifies bugs within the interaction. Integration testing is a popular QA approach to modular programming, in which each module is a separate component of code that can be used in multiple places throughout the codebase.
Some teams execute integration tests in a big bang approach after code creation, linking and unit testing. However, incremental integration testing presents an alternative approach to big bang. In incremental processes, the team can begin integration tests as early as the development stage, when components pass unit tests -- even if the connecting components for the software are not ready for test.
There are several strategies for incremental integration testing, including bottom-up, top-down and a hybrid approach blending elements of both, as well as automation. Each method has benefits and limitations, and gets incorporated into an overall test strategy in different ways. These incremental approaches help enable shift-left testing, which means automation shapes how teams can perform the practice.
Bottom-up integration testing
Bottom-up integration testing starts with the submodules and moves up to the main modules. If higher-level modules are not completed, drivers can simulate their functionality for testing purposes. Think of a driver as a simple calling program, as it just provides the data that the lower-level module needs to go through its test.
Bottom-up integration testing helps find bugs in the lower modules of the code as early as possible, before these issues affect higher-level modules. These test scenarios are simpler and easier to create than top-down ones, and they form the basis for an end-to-end test.
Use bottom-up incremental integration testing in combination with object-oriented programming languages to develop applications. However, it takes time to create and validate the drivers. And, as the team generates higher-level modules, testers will repeat the integration tests more often.
Top-down integration testing
The top-down integration test approach starts with the main modules and works back through the submodules. Stubs, which are versions of the unit of code under development, can simulate the functionality of submodules that aren't through development yet. Modules call stubs, which enable testers to find bugs in the call functionality, even when the full functionality of the submodule is unavailable. Stubs can display trace messages or parameters, return values from tables or return values chosen by parameters.
Top-down incremental integration testing reveals bugs in the main modules early on. This approach elucidates the viability of the integration early in the process, which helps reduce the likelihood of costly design flaws. However, stubs are complicated to create, and it's difficult to execute test cases without I/O functionality. Furthermore, such tests can require specific data that might be unavailable, in which case synthetic data comes in handy.
Nonetheless, the top-down approach is still beneficial for teams that develop software with process-oriented programming languages, such as C.
Hybrid integration testing
Often, the best approach is hybrid, or sandwich, integration testing, which combines both top-down and bottom-up techniques.
Hybrid integration testing exploits bottom-up and top-down during the same test cycles. Testers use both drivers and stubs in this scenario. The hybrid approach is multilayered, testing at least three levels of code at the same time. Hybrid integration testing offers the advantages of both approaches, all in support of shift left. Some of the disadvantages remain, especially as the test team must work on both drivers and stubs.
Apply automation to integration testing
As a growing number of organizations adopt DevOps and Agile methodologies, they investigate automating integration tests to increase test velocity. The more teams can apply automation to the lower levels of the test pyramid, the more they can catch critical bugs earlier in the development cycle, where they are less costly and easier to remediate.
Commercial tools like VectorCast build on unit tests to create automated integration tests for usage with C++ and Ada programming languages. IBM's Rational Integration Tester is another option for integration testing within Agile and iterative methodologies. FitNesse is an open source option that works for most programming languages, and teams commonly use it in conjunction with an approach called acceptance test driven development, as the tool offers the functionality to build from unit tests.
