Let’s start with the definition side first, shall we?
Certain types of testing that seems overlapping or similar to integration testing which may include regression, interoperability, platform, system, risk-based, field and compatibility testing.
Unit tested parts are combined to test overall functionality of the modules. Usually integration testing is considered as testing of interfaces involving different modules or units. Those modules are then observed and validated against acceptance criteria of implemented requirements, considering all modules as one system.
Integration testing is performed parallel to the development. By the times, it becomes a challenge to test the modules which are not developed yet with the developed ones.
Let’s continue towards the REDEFINITION!
What is integration?
Integration Testing provides confidence upon product in three terms:
In simple words, a process of constructing a product from properly designed and working units is called integration.
Keeping in mind the connectivity and interaction, I would like to add two more things:
1. Designing tests to determine the potential risk in integration
2. Testing performed knowing the potential risk in integration.
You can get encountered with a product (integrated) on which you only focus on exposing the borders, interactions and performance degree for reliability in that product verifying the functionality, not only aiming for defects but also to reduce their occurring at later stages.
So “Test designing and testing for integrated units is called integration testing.” When we talk about integration testing, there are 2 types of risks:
2. Potential Risk
They are as different as an apple and a banana.
Because Risk is followed by three parts:
1. Probability of occurrence
2. Influence on product
3. Partial uncertainty (may or may not but known)
Where as a “Potential Risk” is a ghost in dark you can’t see where it would be, so can’t aim it.
Potential Risk is followed by three points:
1. Significant uncertainty (you don’t know the occurrence probability of a bug)
2. Impact of that bug in product.
3. Mere existence of a potential bug
For instance, a new product under test collapses back to your actions (stressful inputs let’s say). So this is a potential risk now. You would be completely unaware of it by skipping the stress testing. If you perform stress testing you may interact with high risk (major and more bugs) or low risk (fewer bugs).
Similarly when things are taken apart, integration risk takes the birth. A product behaves not only because of its parts but also by the internal and external environments, interaction and influences of those parts, environments and interactions.
Answer to the question: what is the motivation of applying “Integration Testing” in our testing strategy?
1. To measure that all modules developed by different teams are up to the standard acceptance criteria or not.
2. To make sure that all modules works properly when integrated.
3. To measure the performance and working of external API’s with integrated modules.
4. Less time consuming when changes are requested and team has strict time schedule.
5. To check if the system is stable or not.
What to do while Integration Testing?
1. Cost Assessment: Write less time consuming and maximum risk avoiding tests.
2. Find New Paths: There is always another way to do one thing, find it.
3. Avoid Shortcuts: Don’t miss single ingredient in a scenario.
4. Test one at a time: Focus and record every move.
5. Don’t leave the test system in a bad/unknown state.
1. Design Document
2. Version Tracking and Control
3. Unit Tested Modules.
4. Automated unit tests.
Pros and cons of Integration Testing
1. Helps in understanding Test Behavior and infrastructure.
2. Helps in Quality Assurance accomplishment.
3. Makes the application Trustworthy and Reliable.
4. Makes Bug minimization afterwards.
5. Provides Customer Satisfaction.
6. Helps in Defects detection at early stage.
7. Makes less costly to fix the defects at early stage.
8. Provides confidence over individual modules and system.
1. Hard to test all critical paths.
2. Harder to localize source of errors.
3. Strict time schedule.
Integration testing is not only a technique; it’s an art of discovering the flaws of a product. Catch them before the client catch you.
Zeeshan Khalid is an experienced Software Quality Engineer. His focus of work is on Web and Mobile based technologies. Zeeshan currently works at Kualitatem Inc and lives in Lahore, Pakistan