You are on page 1of 14


Module Module


“STC – 2012”

Presented By


i|Nautix (A BNY Mellon Company)
Level 1, Tower 8,
Magarpatta City SEZ

ABSTRACT Integration testing is a systematic technique for constructing the software by incrementally integrating unit tested components and modules. This testing is basically done by Developers and Test engineers. The transfer of data and control between modules is tested. . caused due to the integrations of modules are eliminated. Smaller units are integrated in larger units and larger units into a complete system. This reduces the number of possibilities to a far simpler level and Errors or bugs.

This method reduces the number of possibilities to a far simpler level of analysis. 1. The way integration testing works is by getting the individual modules that have been through the unit testing phase and integrating each module into a group. caused due to the integration of the modules are eliminated. unit testing. many units are combined into components. These "design items". The integration testing phase will make sure when the modules are being integrated together that any problems.e. Integration testing identifies problems that occur when units are combined. and this is done after testing individual modules. which are in turn aggregated into even larger parts of the program. A component. for example errors or bugs. i. Integration testing does not deal with the integration of the whole system but deals with the integration of a process in the system. success and error cases being simulated via appropriate parameter and data inputs. By using a test plan that requires you to test each unit and ensure the viability of each before combining units. Introduction of Integration Testing Integration testing is the phase in software testing in which individual software modules are combined and tested as a group. are exercised through their interfaces using Black-Box testing. for example across procedure calls or process activations.e. i. and reliability requirements placed on major design items. The overall idea is a "building block" approach. you know that any errors discovered when combining units are likely related to the interface between units. in this sense. in which verified assemblages are added to a verified base which is then used to support the integration testing of further assemblages . Test cases are constructed to test that all components within assemblages interact correctly. In its simplest form. assemblages (or groups of units). refers to an integrated aggregate of more than one unit. two units that have already been tested are combined into a component and the interface between them is tested. What is the need of Integration testing? The need of integration testing is to verify functional. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. In a realistic scenario. It occurs after unit testing phase and before system testing. performance.

2. Types of Integration Testing 1. Big Bang Testing 2.1) Advantages: The Big Bang method is very effective for saving time in the integration testing process. or you can say that is handle in integration testing (top down approach). Drivers are considered as the dummy modules that always simulate the high level modules. Stubs are considered as the dummy modules that always simulate the low level modules.2. This process 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. Process continues until all of the modules are joined and tested successfully.1. that is handled in bottom up integration testing. 2. 2. 2.2) Drivers are also considered as the form of dummy modules which are always distinguished as "calling programs”. the entire integration process will be more complicated and may prevent the testing team from achieving the goal of integration testing.2. 2.1) Big Bang testing: In big bang testing huge number of modules are coupled to form a single software system and then it is used for integration.1) Stubs are dummy modules that are always distinguish as "called programs". 2.2) Incremental Integration testing: . . it is only used when main programs are under construction. Then the other related modules are added and tested for the proper functioning. Also it is very convenient for smaller systems.Incremental Integration testing is done by joining two or more modules that are logically related. if the test cases and their results are not recorded properly. Incremental Integration Testing 2.1. However.2) Disadvantages: Difficult to debug. it used when sub programs are under construction.

The driver has entity does not exist until the last module is added.1) Advantages: Fault localization is easier. Bottom-up integration testing requires the heavy use of drivers instead of stubs. C individually (using drivers) 2) Test A such that it calls B If an error occurs we know that the problem is in A or in the interface between A and B 3) Test A such that it calls C If an error occurs we know that the problem is in A or in the interface between A and C Usage of Stubs and drivers in Bottom up Integration Considering the same Example above: If we have Home and User modules get ready and Login module is not ready. These are then tested and added to the modules above them to form larger sub-systems which are then tested.3) Bottom Up Bottom-up integration testing is the opposite of Top-down integration testing.3. No time is wasted waiting for all modules to be developed unlike Big-bang approach 2. Sub-systems are initially formed at the bottom of the system hierarchy.2. So to extract the values from Login module We write a Short Piece of Dummy code for login which returns value for home and user. So these pieces of code is always called Drivers and it is used in Bottom Up Integration 2. .3. A B C 1) Test B. and we need to test Home and User modules Which return values from Login module.2) Disadvantages:- Driver modules are essential.

A B C 1) Test A individually (use stubs for B and C) 2) Test A such that it calls B (stub for C) If an error occurs we know that the problem is in B or in the interface between A and B 3) Test A such that it calls C (stub for B) If an error occurs we know that the problem is in C or in the interface between A and C Usage of Stubs and drivers in Top down Integration For Example if we have 3 modules login. this piece of dummy code is always called Stubs and it is used in a top down integration. Using Top-down integration testing means that there is a visible system with a certain level of functionality early on. which will return values for Login. There is no need for test drivers as the user interface provides the means to enter test data. . but we call functions from home and user (which is not ready). Critical Modules are tested on priority. major design flaws could be found and fixed first.1) Advantages:- Fault Localization is easier. and user module. Possibility to obtain an early prototype. home.4) Top Down Top-down integration testing involves starting at the top of a system hierarchy at the user interface and using stubs to test from the top down until the entire system has been implemented.2. Login module is ready and need to test it. 2.4. To test at a selective module we write a short dummy piece of a code which simulates home and user.

for permitting a process to be officially completed. Entry criteria define what is needed to start the testing. and User acceptance testing (UAT) should have different conditions to be met before any of these phases commence. Entry and exit criteria needs to be defined in test plan or test strategy and are required to be signed off by business and project team. test phase. As we all know sometimes there can be no limit of testing and it can be done for a long time. 3. Environment needed to perform integration testing should be ready. But in real world where all the projects come with defined time scope. it tells the test team when to start testing.4. 3. System Integration Testing (SIT).2. All the issues found during system testing should fix and closed. Defects found during integration testing should be fixed and closed. Though entry and exit criterion would vary for all these phases yet they would have relationship to each other. Exit criteria tell the test team when to stop testing.3) Entry criteria for Integration Testing: Unit Tested Components/Modules Modules necessary for integration testing should be ready. Modules at lower level are tested inadequately. Different stages of testing such as System Testing (ST). All the test case should be executed and test results should be pass for the all the test cases.g. In other words.4) Exit criteria for Integration Testing: Successful Testing of Integrated Application. 3. Integration testing should be started as per the scheduled time. agreed upon with the stakeholders. . e.2) Disadvantages:- Needs many Stubs. Testing transition meeting will be held and sign off should be provided.2) Exit criteria can be defined as the set of generic and specific conditions. Test script needed for integration testing should be ready. By defining exit and entry criteria test team define boundaries of testing. Entry and Exit Criteria 3.1) Entry criteria can be defined as the set of generic and specific conditions for permitting a process to go forward with a defined task. we need to plan end of testing very cautiously to ensure testing has been completed covering all the scenarios 3. System testing should be completed before starting integration testing.

1.2) Revision History. resources. 4. Record all revisions to the document. what will be tested.3) Full Hardware/Software Integration Sequence.2.2) Elements to be integrated: Identify all the elements to be integrated by subsystem into which they will be integrated. 4. Specify any software dependencies for early hardware integration activities. Relate this sequence to any product features/functions that are being built up. 4. Specify any hardware dependencies for early software integration activities.5) Integration Strategy 4. the features to be tested. in how much time the test will take place.1.1. For each subsystem: Identify the sequence in which the software code functions and modules will be integrated.1. 4. 4.4. It identifies test items. who will do the testing.3) Purpose and Scope.) and the reason for the choosing that approach.5. and any risks requiring contingency planning. etc. For each subsystem: Identify the sequence of integrating software build(s) with the hardware modules. 4. describe the type of tests that will be used to verify that the elements integrated in this step perform as expected. For each subsystem: Identify the sequence in which the hardware elements will be integrated. and to what quality level the test will be performed..g. 4.2) Sequence of Feature/Function and Hardware/Software Integration 4. who will do each task. At each step. 4. . approach.3) Individual Steps and Test Description: For each step of the integration process identified above.1. and schedule of intended testing activities. Test Plan Definition A test plan can be defined as a document describing the scope.1) Software Integration Sequence.4) List of Reference Documents 4. the testing tasks. Describe in general the expected results of the test set.2) Hardware Integration Sequence.1) Integration Test Plan Template 4.1) Entry Criteria: Specify the criteria that must be met before integration of specific elements may begin (e. specify where re-running of tests from previous steps may be required to verify that integrating this new element has not caused previously tested functions to fail. functions must have been unit 4. Identify the product features/functions that are being built up at each step.5.2. bottom-up. Identify the order in which subsystems will be integrated. It is also be described as a detail of how the testing will proceed.5.2. 4. functional groupings.1.1) Introduction Subsystem Integration Sequence. State the purpose and scope of the document.3) Integration Strategy: Describe the integration approach (top-down.2.

define the responsibilities assigned to each and develop a schedule which shows the sequence of major test set execution and the amount of time estimated for that test set.9) Suspension. b) criteria for restarting testing following such a suspension.4.6) Responsibilities and Schedule: Identify all personnel skill types and quantities. availability of other hardware or software under development. environmental necessary for the integration testing. . Identify known risks and any assumptions 4.8) Key Dependencies: Define key dependencies in the schedule (people or equipment resources. 4. the discovery of major problems with a certain feature. etc. and Exit Criteria: Define criteria for a) suspending testing before completion (for instance. and c) the criteria for determining that integration test is complete and system test can begin. identify any program stubs or special test data required for each integration step. set-up procedures. In this plan summarize any special environmental requirements. 4.5) Program Stubs and Test Data Required: Based on the testing strategy and test design. The integration protocols will specify in detail all configuration information. parameters.7) Roles and Responsibilities 4.) 4. etc. Restart.4) Tools and Test Equipment Required: Identify all tools and test equipment needed to accomplish the integration.

Created By The name of the author of the test case. Requirement Any prerequisites or preconditions that must be fulfilled prior to executing Prerequisites the test. Test Case Definition A test case is a set of conditions or variables under which a tester will determine whether a system under test satisfies requirements or works correctly. to be filled after executing the test. Executed By The name of the person who executed the test. Pass or Fail. . Execution Test The environment (Hardware/Software/Network) in which the test was Environment executed. Remarks Any comments on the test case or test execution. that normally a test management tool is used by companies and the format is determined by the tool used. Test Procedure Step-by-step procedure to execute the test. Test Case The summary / objective of the test case. however. 5. Test Case ID The ID of the test case. Expected Result The expected result of the test.5. or links to the test data. Note. Actual Result The actual result of the test. Summary Related The ID of the requirement this test case relates/traces to.1 TEST CASE TEMPLATE A test case can have the following elements. Other statuses can be ‘Not Executed’ if testing is not Status performed and ‘Blocked’ if testing is blocked. The test data. Date of Creation The date of creation of the test case. that are to be used while Test Data conducting the test. Test Suite ID The ID of the test suite to which this test case belongs. Date of The date of execution of the test. The process of developing test cases can also help find problems in the requirements or design of an application.

Check the link between Inbox and deleted select the message to be deleted message messages in a deleted from the inbox should appear in mobile and click on delete the deleted 2 application option messages folder . Here priority is to be given for the integrating links rather than the unit functions which are already tested.5.3 Integration Test Case: Integration Test case differs from other test cases in the sense it focuses mainly on the interfaces & flow of data/information between the modules. Test Test Case Case ID Objective Test Case Description Expected Result Check the link between Login Enter the Login and Home page credentials on Login Page should be of any page and click on directed to Home 1 application Submit button page.

so if the client is involved with the project a lot it would be less likely in terms of having to make a lot of changes in the integration process. for example test plan. . fixed and re-done so this will cause a delay in the time taken. There is however one problem that may cause time delay in the integration process that is the when using testing data to test the process if faults or errors or reported this will have to be documented.6. Conclusion:- Integration testing is best to be used in an iterative process as this way it will save time in the long run and will help when trying to keep to a budget. The reason why a iterative process is the best for integration testing is simply because this allows for more feedback from the client. Integration testing again uses black box testing as all the integration stage is doing is checking for the correct outputs. The best integration testing type would be top-down as this is the fastest way for the integration process to be completed.

New York. 17(4):40–52. 2nd ed. Wolf.E. SIGSOFT Software Engineering Notes. Software Testing Techniques. J. Van No strand Reinhold. The Art of Software Testing. New York. Bezier. October 1992 . D. John Wiley & Sons. 1990 G. 1979. Perry and A. Foundations for the Study of Software Architecture. Meyers.L. Reference Materials B.7.. Inc.

8.Tech in Information Technology from JECRC Foundation. degree: . She has Overall 8 months of experience . Jaipur (Rajasthan). Core Responsibilities:- 1) Analyzing the requirements from the client 2) Preparing Test cases 3) Preparing Test Scenarios 4) Defect Tracking 5) Communicating with the Test Lead / Test Manager 6) Conducting Review Meetings within the team College attended.During her testing experience she is certified with ISTQB and ICTP (Internal certification).Currently she is working in iNautix(A BNY Mellon Company) as a Quality Assurance Analyst.She completed her B. Author’s Biography Current position/core responsibilities: . .