Tuesday, March 16, 2010
Software Testing Demystified Part 3
In the last post, I talked about the Unit Testing phase. Let me take up the topic of Integration Testing this time. Practically, Unit and Integration testing phases go together. Although we find many teams named as System Integration Testing teams, they typically are involved in System Testing and little integration.
Integration Testing is an extension of Unit Testing. When talking about software development, the normal process that gets followed is that we create small chunks of code or functions, and then integrate them with one other to build up a functionality. Integration Testing also follows a similar format of testing the application. In integration testing, we test the different software modules or pieces of code, when integrated with other pieces of code. These pieces of code could be different functionality as well. Let us call them as Components. Then in this case, we can say that a unit integrated to one or more other units makes up a Component. So when you hear about Component Testing as a term, then you should not give a bad look. It could be interpreted as the same Integration Testing itself. In integration testing phase, one basically tests functionality. This might be a simple or complex functionality which includes more than one code units. This is one of the advantages of this testing phase. We have a deliverable as the output, after testing. The integrated module is actually a functionality of our software application. Thereby, this phase of testing could be correlated to the incremental model of software development!
Integration testing phase can identify the issues which occur when multiple units are combined to work together. This phase of software testing helps to isolate most of the data and control flow related issues that may remain hidden in the unit testing phase. This is basically because, when combined, these units share the same data and controls while executing. There are different methods through which Integration Testing could be performed. We can divide these into three basic methods, which are described below.
Integration Testing is an extension of Unit Testing. When talking about software development, the normal process that gets followed is that we create small chunks of code or functions, and then integrate them with one other to build up a functionality. Integration Testing also follows a similar format of testing the application. In integration testing, we test the different software modules or pieces of code, when integrated with other pieces of code. These pieces of code could be different functionality as well. Let us call them as Components. Then in this case, we can say that a unit integrated to one or more other units makes up a Component. So when you hear about Component Testing as a term, then you should not give a bad look. It could be interpreted as the same Integration Testing itself. In integration testing phase, one basically tests functionality. This might be a simple or complex functionality which includes more than one code units. This is one of the advantages of this testing phase. We have a deliverable as the output, after testing. The integrated module is actually a functionality of our software application. Thereby, this phase of testing could be correlated to the incremental model of software development!
Integration testing phase can identify the issues which occur when multiple units are combined to work together. This phase of software testing helps to isolate most of the data and control flow related issues that may remain hidden in the unit testing phase. This is basically because, when combined, these units share the same data and controls while executing. There are different methods through which Integration Testing could be performed. We can divide these into three basic methods, which are described below.
- A Top-Down approach – In this approach, the high-level modules are tested and integrated first and there by reaching the smallest components. This allows the high-level logic and data flow to be tested early in the process and thereby reduces the necessity of drivers. But, Stubs are required in testing the high-level modules. Stubs are nothing, but pieces of code written to provide expected input to the high-level modules. The major disadvantage of this approach is its inability to support an early release of limited functionality.
- A Bottom-Up approach – Here the lowest-level modules, commonly termed as Utility modules, are tested and integrated first. This approach minimizes the requirement of Stubs, but Drivers are required to be written to drive/run the low lying modules. This approach also suffers from the disadvantage of not able to produce an early release of limited functionality.
- The Umbrella approach – Testing along the data and control flows of the code being tested. This approach is actually having the flavors of both the above mentioned testing approaches, and proves to be a better adaptable integration testing method, because it supports the early releases of limited functionality. This also minimizes the tedious processes of writing Stubs and Drivers. A disadvantage of this method that needs to be mentioned is that it is lesser systematic.
There are many tools available in market for performing automated integration testing. An example is invalidator, which helps testers to perform integration testing of code written in Java, XML etc. There is also MActor, which facilitates testing XML integration. Most of the times, it becomes easier to follow an automated way while performing an Integration Test.
Labels: Integration Testing, Software Testing Demystified
// posted by Kishore Krishnan @ 11:42 AM 
Subscribe to Posts [Atom]
Post a Comment