The software comprises various modules that multiple programmers or coders have written. The integration testing level focuses on exposing faults that occur during the interaction of integrated components or units.
Integration testing combines and tests the modules used in unit testing. This level of testing is intended to discover problems in how integrated units interact. Integration testing is made more accessible with test drivers and test stubs.
What is Integration Testing
Integration testing is a level of software testing where individual units or components are combined and tested as a group. The primary goal of integration testing is to verify the interfaces between different components and ensure that they work together seamlessly when integrated.
In software development, applications are typically built by combining different modules, classes, packages, or services. While these individual units may work correctly when tested in isolation, they may encounter issues or conflicts when integrated with other units due to interface mismatches, data compatibility problems, or resource-sharing conflicts.
The primary goal of integration testing is to verify that different modules or components of a software system communicate and exchange data as designed. Even when individual components work flawlessly in isolation, integration can introduce unexpected problems such as:
- Data transfer errors: Mismatches in data types, formats, or transmission between modules.
- Timing issues: Components working at different speeds, leading to race conditions or synchronization errors.
- Interface incompatibilities: Misunderstandings about the way modules should interact with each other.
- Unexpected side effects: Changes in one module inadvertently break functionality in another.
Guidelines For Integration Testing:
We always perform integration testing by selecting modules one by one to ensure that the appropriate process is followed and that no integration cases are missed.
- First, decide on a test case method that will allow you to create executable test cases based on the test data.
- Examine the application’s structure and design, identifying the essential modules to test initially, as well as all conceivable situations.
- Choose the data that will be used to run the test case. Input data is essential. If the total balance is Rs. 15 000, and we are sending Rs. 1500, we perform positive tests. If it does, the exam will be passed.
Negative testing indicates that if the entire balance is Rs. 15, 000 and we’re sending Rs. 20,000, we’ll check if the amount transfer happens or not.
Some Common Examples of Integration Testing:
Let’s assume that we are performing integration testing on a Gmail application.
The login page, which includes features like the username, password, and submits, will be the first to be functionally tested. Integration testing will be possible only then.
Scenario 1:
We begin by logging in as P users and clicking Compose mail, then doing functional testing for the various components.
Now we’ll click Send and double-check for Save Drafts.
After that, we send a message to Q and check P’s Send Items folder to see if the message was received.
Now we’ll log out as P and log in as Q, then go to the Inbox and see if the letter has been resent.
Scenario 2:
We also execute integration testing on Spam folders, according to Scenarios 2. For example, if a contact has been flagged as spam, any email sent by that person should be directed to the spam folder rather than the Inbox.
Note: We may undertake solely functional testing on some features, and we may perform both functional and integration testing on other features, depending on the feature’s requirements.
Prioritizing is critical, and it should be done at all stages. This means opening the application and deciding which feature should be tested first. Then, when performing testing, we should focus on one feature and test it thoroughly before moving on to the next.
Only positive integration testing or both positive and negative integration testing is required for one of the two features, and this is dependent on the features required.
Reason Behind Integration Testing:
Even though all modules of the software application have been unit tested, there are still issues for the following reasons:
A distinct software developer develops each module, and the programming logic for each module may differ from that of the others. As a result, integration testing is required to evaluate the compatibility of software elements. This helps to see if the interaction of software modules with the database is correct or not.
Requirements might be changed or modified during module development. These additional requirements may not be able to be tested at the unit level, necessitating integration testing.
Integration Testing Techniques And Different Types
This testing can be divided into two types:
1. Unit / Component Testing-
Unit integration testing is carried out after unit testing, and it is usually automated. However, iterative and incremental development frequently includes unit integration tests.
2. Integration Testing of the System-
The interaction and interfaces between systems emphasize this type of testing (A system is a group of interacting or interrelated entities that form a unified whole).
It makes no difference whether the other method is internal or external to be merged with (developed by someone else over which the organization has no control). These systems are frequently exposed to the elements.
Various Approaches for Integration Testing:
This software testing can be approached in four ways:
1. The Big Bang-
This is a method in which all or most of the units are merged and tested simultaneously.
Advantage: Very convenient for the small systems
Disadvantage: Delays can be expected, as you will be required to wait for the modules to get integrated first and then proceed.
2. Top-down-
Top-level units are checked first, followed by lower-level units in this approach of software testing. This is the approach taken while using a top-down development strategy.
Advantage: Very few or no drivers are needed and it gets separately debugged into the module.
Disadvantage: Modules at the lower levels get tested inadequately.
3. Bottom-Up-
This is a technique in which lower-level units are tested first, followed by upper-level units one by one. When a bottom-up development strategy is used, this approach is used.
Advantage: Many of the disjoint subsystems can be tested together, hence avoiding wastage of time.
Disadvantage: Here complexity occurs when the system is made up of plenty of larger numbers of small subsystems.
4. Sandwich And Hybrid-
This is a combination method for Integration Testing.
Advantage: Testing is useful for larger projects which have multiple sub-projects.
Disadvantage: Cannot be used for smaller systems that have interdependence between the modules.
Ending Thoughts:
After unit testing, integration testing is the next step in the software testing process. This testing level focuses on exposing faults that occur during the interaction of integrated components or units.
The team employs components that have already been thoroughly tested as independent units to conduct integration testing. Then, a quality assurance team sorts these items into sets and tests them according to the test strategy.
This method entails a testing team interacting with an app and its units through the user interface, such as clicking on buttons and links, scrolling, and swiping.
Source: This article was originally published at testgrid.io
Top comments (0)