Despite there are a lot of types of software testing the Integration testing is especially relevant to client/server and distributed systems. That is why we prepared for you an interesting material about this type of testing with its main approaches, structure, and nuances you have to know. This is an introduction to Integration testing we prepared for you.
As software development agency we will begin our material with basic terms.
To start with, software testing is the process of evaluating a software item to detect differences between given input and expected output. In other words, software testing is a verification and validation process.
There are two basics of software testing: blackbox testing and whitebox testing.
Blackbox testing is a testing technique that ignores the internal mechanism of the system and focuses on the output generated against any input and execution of the system. It is also called functional testing. Whitebox testing is a testing technique that takes into account the internal mechanism of a system. It is also called structural testing and glass box testing. Blackbox testing is often used for validation and white box testing is often used for verification.
There are many different types of software testing like:
- Unit Testing
- Integration Testing
- Functional Testing
- System Testing
- Stress Testing
- Performance Testing
- Usability Testing
- Acceptance Testing
- Regression Testing
- Beta Testing
and so on…
But we will talk about Integration testing today.
Integration testing is testing where a group of components is combined to produce output. If software and hardware components have any relation the iteration between them is also tested with integration testing. In simple words, the integration testing is a testing of all integrated modules to verify the combined functionality after integration.
It may fall under both whitebox testing and blackbox testing. Modules are typically code modules, individual applications, client and server applications on a network, etc.
Here integration is the process of assembling unit-tested modules. We need to test the following aspects, which have not been addressed previously while independently testing the modules:
- Interfaces: To ensure “interface integrity,” the transfer of data between modules is tested. When data is passed to another module, by way of a call, there should not be any loss or corruption of data. The loss or corruption of data can happen due to mismatch or differences in the number or order of calling and receiving parameters.
- Module combinations may produce a different behavior due to combinations of data that are not exercised during unit testing.
Global data structures, if used, may reveal errors due to unintended usage in some module.
Integration testing approaches
While integrating the modules developers usually adopt four approaches of integration testing.
To illustrate these four methodologies, we will use the following arrangement of modules say M1, M2, M3, …, M7.
Top-Down Approach (TDA)
Involves development of all the topmost / parent modules beforehand followed by due integration with child modules.
This approach uses a Program called “Stub”. While integrating the modules with this Top-Down Approach, if at any stage it is found that some mandatory module is missing, then in such an event that particular module is replaced with a temporary program known as “Stub”.
The testing starts with M1. To test M1 in isolation, communications to modules M2, M3 and M4 needs to be simulated by the tester by some means, since these modules may not be ready yet. To simulate responses of M2, M3, and M4 whenever they are to be invoked from M1, “stubs” are created. Simple applications may require stubs, which would simply return the control to their superior modules. More complex situation demand stubs to simulate a full range of responses, including parameter passing. Stubs may be individually created by the tester or they may be provided by a software testing harness, which is a sort of software specifically designed to provide a testing environment.
In the above illustration, M1 would require stubs to simulate the activities of M2, M3, and M4. The integration of M3 would require a stub or stubs for M5 and M4 would require stubs for M6 and M7. Elementary modules i.e. the modules which do not call subordinates would not require any stubs.
Advantages of Top-down Approach:
a) This approach is advantageous if all major flaws are captured towards the top of the program
b) Early skeletal program allows demonstrations and boosts the morale
Disadvantages of Top-down Approach:
a) Stub modules are essential
b) Test conditions may be impossible, or very difficult, to create
c) Observation of test output is more difficult, as only simulated values will be used initially. For the same reason, program correctness can be misleading
Bottom-Up Approach (BUA)
Involves development of all the elementary modules or child modules beforehand followed by due integration with the corresponding parent modules.
This approach uses a Program called “Driver”. While integrating the modules with this Bottom-Up Approach, if at any stage it is found that some mandatory module is missing, then in such an event that particular module is replaced with a temporary program known as “Driver”.
If M5 is ready, we need to simulate the activities of its superior, M3. Such a “driver” for M5 would simulate the invocation activities of M3. As with the stub, the complexity of a driver would depend upon the application under test. The driver would be responsible for invoking the module under test, it could be responsible for passing test data and it might be responsible for receiving output data. Here as well, the driving function can be provided through a testing harness or may be created by the tester as a program.
For the above-mentioned Bottom-Up example, drivers must be provided for modules M2, M5, M6, M7, M3, and M4. However, there is no need for a driver for the topmost Module, M1.
Advantages of Bottom-Up Approach:
a) This approach is advantageous if all major flaws are captured towards the bottom of the program
b) Test conditions are easier to create
c) Observations of test results are easier since “live” data is used from the beginning.
Disadvantages of Bottom-Up Approach:
a) Driver modules are essential
b) The program as an entity does not exist until the last module is added
Big Bang Approach
Once all the modules are ready after testing individually; the approach of integrating them finally at once is known as big bang approach.
Though Big Bang approach seems to be advantageous when we construct independent module concurrently, this approach is quite challenging and risky as we integrate all modules in a single step and test the resulting system. Locating interface errors, if any, becomes difficult here.
To overcome the limitations and to exploit the advantages of Top-down and Bottom-up approaches, a hybrid approach in testing is used. As the name suggests, it is a mixture of the two approaches like Top-Down approach as well as Bottom-Up approach.
In this approach, the system is viewed as three layers consisting of the main target layer in the middle, another layer above the target layer, and the last layer below the target layer.
The Top-Down approach is used in the topmost layer and Bottom-Up approach is used in the lowermost layer. The lowermost layer contains many general-purpose utility programs, which are helpful in verifying the correctness during the beginning of testing.
The final decision on selecting an integration approach depends on system characteristics as well as on customer expectations. Sometimes the customer wants to see a working version of the application as soon as possible thereby forcing an integration testing approach aimed at producing a basic working system in the earlier stages of the testing process. However, if you work with Syndicode you have no need to think about it. Just share with us your requirements and we will do for you the integration testing with the most suitable approach.
Don’t forget to subscribe to our weekly newsletter!