Integration Testing is said to be an important level of testing as it involves testing of interfaces and flow of data between the units (Smallest Individual Modules in a software). Since Integration testing is performed on groups of units or modules, it is the only way to create real-time use cases for testing. The purpose of Integration testing is to detect defects in the interfaces and interactions between the integrated units. Learn more about Testing as a Service
There are a few points to remember during the planning and testing of integrations, which are described in this article. First, let’s see a few common challenges faced by project teams, and the mistakes they make, which lead to Product failures:
- Establishing interfaces between different systems and ensuring that the influence of one system on another does not create major issues.
- Test Strategy is critical in complex projects because many systems are involved, such as Databases, third party tools, different environments, etc.
- Considering all variations of test data, migrating data, and complex workflows going from one system to another is a tricky task.
- Integration tests are sometimes skipped totally, as the Product teams are satisfied with 100%-unit test coverage. This might lead to failures in the developed application as the interfaces are not tested at all.
- Not maintaining the right balance of the types of testing done during Project Execution.
Below are some points which will help QA teams to overcome most of the above challenges and avoid all possible mistakes during their integration test cycle.
Integration Testing – How to do it right?
- Do Integration testing before or after unit testing
In primitive Software Development days, where projects were implemented using the Age-old Waterfall Model, teams had to do Integration testing (if at all!) strictly after the unit testing was done. These days, with the evolution of DevOps and smaller release cycles, order of testing really does not matter. Few test engineers opine that performing Integration testing before the Unit testing is beneficial as whenever these tests fail, you can zero-down to the exact unit that’s causing the integration test to fail and then work on optimizing it.
- Always perform (System) Integration tests in environments copying Production Instance
Basically, Successful Integration tests provide confidence for the testers to perform end-to-end tests with the Application-under-test. In this regard, it is best that the environment, in which the Integration tests are planned to be done, mimic the customer’s environment. In other words, the Integration test environment should be a scaled-down version of the Production environment.
- Automating the Integration Tests would lead to efficient testing efforts
As far as possible, use automation testing tools, especially when you use the Top Down or Bottom Up approach, since regression testing is important each time you integrate a unit, and manual regression testing is not only time consuming but also inefficient. Tools such as: VectorCAST, Citrus, LDRA, Smart Integration Test Accelerator, Fitnesse, IBM Rational Integration Tester, Protractor, Tessy will help teams in effectively planning and performing Integration tests.
- Ensure Well-defined Test Strategy
Like any other testing, Test Strategy for Integration needs to be called out clearly and test cases and test data need to be prepared before the beginning of Integration testing. Also, critical modules need to be identified and their interactions should be tested on priority. Absence of a Design Document can almost make the Integration testing efforts useless. Not ensuring detailed Design document with clearly defined interactions between each unit can lead to wastage of Integration testing efforts. Understand the architecture of the application being built, write test cases to cover all the interfaces within the system and with external systems.
- Have a good Software Configuration Management system
Ensure that you have a robust Configuration Management system in place. Or else, the team will face a lot of difficulties in tracking the right version of each unit, especially if the number of units to be integrated is huge. Also, make sure that each unit is “unit-tested” before you start Integration Testing.
Integration testing – What not to do?
- Integration testing should not involve testing functionality
Business Logic should not be tested as a part of Integration Testing. Integration testing should be scoped only for testing interfaces between the Components or the external systems. Testing of data flowing through the integration can be tested but functional testing should be kept separate.
- Integration testing and unit testing should not overlap
Unit testing is usually done by Developers or white box testers, but Integration testing is done by specialized Integration testing teams. Thorough unit testing must be done before starting integration. The Integration test scenarios should be maintained in Separate test suites and tested using a build server.
- Test cases should not be too complex
The more complex the test cases are, the more difficult your Integration testing becomes. Usually, Integration testing involves checking the interfaces between components or with external systems. Hence, test cases can be very simple checking the mapping of components between systems, endpoints of systems and integration/sync retry mechanism.
- Integration test cases should not test beyond the Requirement Acceptance Criteria
Each sprint of Agile Development cycle contains User stories on which the teams would be working on. Each User Story should contain clear and concise Entry/Exit criteria and the User stories pertaining to Integration are no different. Hence, in this regard, Integration testing should only aim to cover the requirements around integration of the systems.
Integration testing sometimes seems quite intriguing, but it's not that difficult. Of course, having a dedicated integration testing team in the project is always good, but even functional testers can be trained and do well on integration testing. I hope this article helps your teams to plan and come up with the best integration testing strategies and techniques.
About the Author
Krishna Chaitanya Kalaparti, Software Engineer - QA
Krishna Chaitanya is Software Engineer – QA at Jade Global. He has 6+ years of experience in Functional Testing, Integration Testing, and Microsoft Dynamics 365. He is certified in Microsoft Dynamics 365 Customer Engagement.