Integration Testing
Objective of Integration testing is to make sure that the interaction of two or more components produces results that satisfy functional requirement. In integration testing, test cases are developed with the express purpose of exercising the interface between the components.
Integration testing can also be treated as testing assumption of fellow programmer. During the coding phase, lots of assumptions are made. Assumptions can be made for how you will receive data from different components and how you have to pass data to different components. During Unit Testing, these assumptions are not tested. Purpose of unit testing is also to make sure that these assumptions are valid. There could be many reasons for integration to go wrong, it could be because
  • Interface Misuse - A calling component calls another component and makes an error in its use of interface, probably by calling/passing parameters in the wrong sequence.
  • Interface Misunderstanding - A calling component makes some assumption about the other components behavior which are incorrect. 


Integration Testing can be performed in three different ways based on the from where you start testing and in which direction you are progressing. Top down testing can proceed in a depth-first or a breadth-first manner. For depth-first integration each module is tested in increasing detail, replacing more and more levels of detail with actual code rather than stubs. Alternatively breadth-first would proceed by refining all the modules at the same level of control throughout the application. In practice a combination of the two techniques would be used. 

Entry Criteria

Main entry criteria for Integration testing is the completion of Unit Testing. If individual units are not tested properly for their functionality, then Integration testing should not be started.

Exit Criteria

Integration testing is complete when you make sure that all the interfaces where components interact with each other are covered. It is important to cover negative cases as well because components might make assumption with respect to the data.
Recent Updates
Guerrilla Testing Tips
One CPU better than two
TG Tips For Automation?
Is It Really Done?
Exploratory Testing
Automated Testing
Model Based Testing
Live News
 
Read More
Accessibility API Testing Article Backword BigBang Blackbox Blog Bottomup Boundary CaseStudies Certification DefectReport DistanceTest Equivalence FitNesse Geeks Graybox Guerrilla Testing Tips GUI HTA Humor Hybrid Internationalization Installation Integration Is it done? JUnit Measurement Mercury Quality Centre News One CPU better than two Patent Performace Checklist Rational Test Suite Regression Requirement Verification Research Rational Functional Tester Security Selenium SilkTest System Testing Templates TestComplete Tools Testing Types Testing Tools In News Testing Terms In News Testometer Test Plan TG Tips For Automation Top Down Integration Trait UAT UI Testing CheckList Unit Testing Usability VMWare Web Application Security Web Application Testing Checklist Whitebox Testing
Disclaimer  |  Privacy Policy  |  g e e k AT T e s t i n g G e e k DOT c o m
© Copyright 2008, www.TestingGeek.com