Headlines News :
Home » , » Integration Testing

Integration Testing

Written By Sambasivarao on Wednesday, November 6, 2013 | Wednesday, November 06, 2013


Introduction: Integration testing is the phase in software testing in which individual software modules are combined and tested as a group. It occurs after unit testing phase and before system testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
Need of integration testing: The need of integration testing is to verify functional, performance, and reliability requirements placed on major design items. These "design items", i.e. assemblages (or groups of units), are exercised through their interfaces using Black-Box testing, success and error cases being simulated via appropriate parameter and data inputs. Test cases are constructed to test that all components within assemblages interact correctly, for example across procedure calls or process activations, and this is done after testing individual modules, i.e. unit testing. The overall idea is a "building block" approach, in which verified assemblages are added to a verified base which is then used to support the integration testing of further assemblages.
Approaches used in Integration testing: There are 4 approaches used in Integration testing.
  1. Big Bang Testing
  2. Top-Down Testing
  3. Bottom-Up Testing
  4. Sandwich Testing
Big Bang Testing: In this approach, all or most of the developed modules are coupled together to form a complete software system or major part of the system and then used for integration testing. The Big Bang method is very effective for saving time in the integration testing process. However, if the test cases and their results are not recorded properly, the entire integration process will be more complicated and may prevent the testing team from achieving the goal of integration testing.
Top-Down Testing: In this approach, the highest-level modules are tested first and progressively lower-level modules are tested after that.
Bottom-Up Testing: Bottom-up integration testing begins with unit testing followed by higher level combinations of units called modules. This approach is helpful only when all or most of the modules of the same development level are ready. This method also helps to determine the levels of software developed and makes it easier to report testing progress in the form of a percentage.
Sandwich Testing: This is an approach to combine top down testing with bottom up testing.
From above mentioned approaches only Top-Down & Bottom-Up are used mostly. So the main advantage of bottom-up approach is that bugs are more easily found as compared with top-down approach, it is easier to find the missing branch link and show the whole software process to user early.
Steps to perform integration testing:
Step 1: Create a Test Plan 
Step 2: Create Test Cases and Test Data 
Step 3: Once the components have been integrated execute the test cases 
Step 4: Fix the bugs if any and re test the code 
Step 5: Repeat the test cycle until the components have been successfully integrated

Essentials of Effective Integration testing:
There are various factors that affect Software Integration and hence Integration Testing:
1. Software Configuration Management: Since Integration Testing focuses on Integration of components and components can be built by different developers and even different development teams, it is important the right versions of components are tested. This may sound very basic, but the biggest problem faced in n-tier development is integrating the right version of components. Integration testing may run through several iterations and to fix bugs components may undergo changes. Hence it is important that a good Software Configuration Management (SCM) policy is in place. We should be able to track the components and their versions. So each time we integrate the application components we know exactly what versions go into the build process.
2. Automate Build Process where necessary: A Lot of errors occurs because the wrong versions of components were sent for the build or there are missing components. If possible write a script to integrate and deploy the components this helps reduce manual errors.
3. Document: Document the Integration process/build process to help eliminate the errors of omission or oversight. It is possible that the person responsible for integrating the components forgets to run a required script and the Integration Testing will not yield correct results.
4. Defect Tracking: Integration Testing will lose its edge if the defects are not tracked correctly. Each defect should be documented and tracked. Information should be captured as to how the defect was fixed. This is valuable information. It can help in future integration and deployment processes.
Some keynotes on need of integration testing:
  • More stable than GUI tests
  • Useful in writing precise component level tests.
  • Drives better code design
  • Tester understands the internal working of application allowing better writing of test cases
  • Easy to integrate in a continuous integration environment

****Use of Stubs and Drivers in Integration Testing ****
While doing an Integration testing, if we don’t have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs and drivers are used for a Top down Integration testing and Bottom up Integration Testing.
For e.g.: If we have Modules X, Y and Z. X module is ready and we need to test it, but it calls functions from y and z (which are not yet ready). To test at such a module, we write a small dummy piece a code which Simulates Y and Z and which will return values for X. This piece of dummy code is called Stub in a Top down Integration Testing.
So Stubs are called Functions in Top down Integration.
Similar to the above: If we have Y and Z modules ready and x module is not ready, and we need to test Y and Z modules which accepts values from X, So to get the values from X We write a small piece of dummy code for X which returns values for Y and Z. So this piece of code is called Driver in Bottom up Integration testing.
So Drivers are calling Functions in Bottom Up Integration.

Difference between System Integration Testing and Integration Testing
System integration testing takes multiple integrated systems that have passed system testing as input and tests their required interactions. Following this process, the deliverable systems are passed on to acceptance testing.
Integration testing is the phase in software testing in which individual software modules are combined and tested as a group. It occurs after unit testing and before system testing. Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready for system testing.

Source [Author: Gagan Talwar : utest.com]
Share this article :

0 comments:

Speak up your mind

Tell us what you're thinking... !

Page views

Blog Archive

 

Proudly powered by Blogger
Copyright © 2011. Useful One! - All Rights Reserved
Template Design by Creating Website Published by Mas Template