Integration Testing

Integration Testing:

Testing data flow between dependent modules is called integration testing.

INTEGRATION TESTING is defined as a type of testing where software modules are integrated logically and tested as a group

It is also termed as 'I & T' (Integration and Testing), 'String Testing' and sometimes 'Thread Testing'.

The main function or goal of this testing is to test the interfaces between the units/modules.

The individual modules are first tested in isolation. Once the modules are unit tested, they are integrated one by one, till all the modules are integrated, to check the combinational behaviour, and validate whether the requirements are implemented correctly or not.

Here we should understand that Integration testing does not happen at the end of the cycle, rather it is conducted simultaneously with the development. So in most of the times, all the modules are not actually available to test and here is what the challenge comes to test something which does not exist!

Example:

Banking application:

Sc1: Login as user A, click on amount transfer link, enter the data to the required fields and click on transfer button. Login as user A, click on amount balance link verify the amount balance.

Why Integration Test?

    A Module, in general, is designed by an individual software developer whose understanding and programming logic may differ from other programmers. Integration Testing becomes necessary to verify the software modules work in unity

    At the time of module development, there are wide chances of change in requirements by the clients. These new requirements may not be unit tested and hence system integration Testing becomes necessary.

    Interfaces of the software modules with the database could be erroneous

    External Hardware interfaces, if any, could be erroneous

    Inadequate exception handling could cause issues.

    Modules also interact with some third party tools or APIs which also need to be tested that the data accepted by that API / tool is correct and that the response generated is also as expected.

Advantages

There are several advantages of this testing and few of them are listed below.

• This testing makes sure that the integrated modules/components work properly.
• Integration testing can be started once the modules to be tested are available. It does not require the other module to be completed for testing to be done, as Stubs and Drivers can be used for the same.
• It detects the errors related to the interface.

Challenges

Listed below are few challenges that are involved in Integration Test.

#1) Integration testing means testing two or more integrated systems in order to ensure that the system works properly. Not only the integration links should be tested but an exhaustive testing considering the environment should be done to ensure that the integrated system works properly.

There might be different paths and permutations which can be applied to test the integrated system.

#2) Managing Integration testing becomes complex because of few factors involved in it like the database, Platform, environment etc.

#3) While integrating any new system with the legacy system, it requires a lot of changes and testing efforts. Same applies while integrating any two legacy systems.

#4) Integrating two different systems developed by two different companies is a big challenge as for how one of the systems will impact the other system if any changes are done in any one of the systems is not sure.

In order to minimize the impact while developing a system, few things should be taken into consideration like possible integration with other systems, etc.

Types of Integration Testing

Big Bang Approach:

Here all component are integrated together at once and then tested.

Advantages of Big Bang approach:

• It is a good approach for small systems.

Disadvantages of Big Bang Approach:

Fault Localization is difficult.

    Given the sheer number of interfaces that need to be tested in this approach, some interfaces link to be tested could be missed easily.

    Since the Integration testing can commence only after "all" the modules are designed, the testing team will have less time for execution in the testing phase.

    Testing takes place at once only which thereby leaves no time for critical module testing in isolation.

Incremental Approach: which is further divided into the following

•  Top Down Approach
•  Bottom Up Approach
•  Sandwich Approach - Combination of Top Down and Bottom Up

Top Down Approach:

What is Stub and Driver?

Incremental Approach is carried out by using dummy programs called Stubs and Drivers. Stubs and Drivers do not implement the entire programming logic of the software module but just simulate data communication with the calling module.

Stub: Is called by the Module under Test.

“Stubs” can be referred to as code a snippet which accepts the inputs/requests from the top module and returns the results/ response. This way, in spite of the lower modules, do not exist, we are able to test the top module.

Driver: Calls the Module to be tested.

In simple words, DRIVERS are the dummy programs which are used to call the functions of the lowest module in a case when the calling function does not exist.

Both Stubs and drivers are dummy piece of code which is used for testing the “non- existing” modules. They trigger the functions/method and return the response, which is compared to the expected behaviour.

Stubs	Driver
Used in Top down approach	Used in Bottom up approach
Top most module is tested first	Lowest modules are tested first.
Stimulates the lower level of components	Stimulates the higher level of components
Dummy program of lower level components	Dummy program for Higher level component

Bottom-up Integration

In the bottom-up strategy, each module at lower levels is tested with higher modules until all modules are tested. It takes help of Drivers for testing

Diagrammatic Representation:

Advantages:

• Fault localization is easier.
• No time  is wasted waiting for all modules to be developed unlike Big-bang approach

Disadvantages:

 The higher level design flaws will be detected only at the end.

Top-down Integration:

In Top to down approach, testing takes place from top to down following the control flow of the software system.

Takes help of stubs for testing.

Diagrammatic Representation:

Advantages:

• Fault Localization is easier.
• Possibility to obtain an early prototype.
• Critical Modules are tested on priority; major design flaws could be found and fixed first.

Disadvantages:

• Needs many Stubs.
• Modules at a lower level are tested inadequately.

How to do Integration Testing?

The Integration test procedure irrespective of the Software testing strategies (discussed above):

1.   Prepare the Integration Tests Plan

2.   Design the Test Scenarios, Cases, and Scripts.

3.   Executing the test Cases followed by reporting the defects.

4.   Tracking & re-testing the defects.

5.   Steps 3 and 4 are repeated until the completion of Integration is successful

Black Box Testing.

Testing the functionality of an application according to the customers requirement specification is called Black Box Testing.

The different types of BBT are:

Functional Testing
Integration Testing
System Testing
Acceptance Testing
Smoke Testing
Ad-hoc Testing 
Exploratory Testing
Regression Testing
Globalization Testing
Performance Testing
Usability Testing
Recovery Testing
Reliability Testing. etc...

White Box Testing

White-box testing is a testing technique which checks the internal functioning of the system. In this method, testing is based on coverage of code statements, branches, paths or conditions. White-Box testing is considered as low-level testing. It is also called glass box, transparent box, clear box or code base testing.

Difference between Black Box Testing and White Box testing.

Difference between Black Box Testing and White Box testing.

S.No	Black Box Testing	White Box Testing
1	The main objective of this testing is to test the Functionality / Behavior of the application.	The main objective is to test the infrastructure of the application.
2	This can be performed by a tester without any coding knowledge of the AUT (Application Under Test).	Tester should have the knowledge of internal structure and how it works.
3	Testing can be performed only using the GUI.	Testing can be done at an early stage before the GUI gets ready.
4	This testing cannot cover all possible inputs.	This testing is more thorough as it can test each path.
5	Some test techniques include Boundary Value Analysis, Equivalence Partitioning, Error Guessing etc.	Some testing techniques include Conditional Testing, Data Flow Testing, Loop Testing etc.
6	Test cases should be written based on the Requirement Specification.	Test cases should be written based on the Detailed Design Document.
7	Test cases will have more details about input conditions, test steps, expected results and test data.	Test cases will be simple with the details of the technical concepts like statements, code coverage etc.
8	This is performed by professional Software Testers.	This is the responsibility of the Software Developers.
9	Programming and implementation knowledge is not required.	Programming and implementation knowledge is required.
10	Mainly used in higher level testing like Acceptance Testing, System Testing etc.	Is mainly used in the lower levels of testing like Unit Testing and Integration Testing.
11	This is less time consuming and exhaustive.	This is more time consuming and exhaustive.
12	Test data will have wide possibilities so it will be tough to identify the correct data.	It is easy to identify the test data as only a specific part of the functionality is focused at a time.
13	Main focus of the tester is on how the application is working.	Main focus will be on how the application is built.
14	Test coverage is less as it cannot create test data for all scenarios.	Almost all the paths/application flow are covered as it is easy to test in parts.
15	Code related errors cannot be identified or technical errors cannot be identified.	Helps to identify the hidden errors and helps in optimizing code.
16	Defects are identified once the basic code is developed.	Early defect detection is possible.
17	User should be able to identify any missing functionalities as the scope of this testing is wide.	Tester cannot identify the missing functionalities as the scope is limited only to the implemented feature.
18	Code access is not required.	Code access is required.
19	Test coverage will be less as the tester has limited knowledge about the technical aspects.	Test coverage will be more as the testers will have more knowledge about the technical concepts.
20	Professional tester focus is on how the entire application is working.	Tester/Developer focus is to check whether the particular path is working or not.