You are on page 1of 12

SOFTWARE

QUALITY
ENGINEERING
(SQE)
Chapter 22: Software Testing Strategies
1
2
INTEGRATION
TESTING
 Integration Testing: The objective is to take unit-tested components and build a
program structure that has been dictated by design.
 Integration Test Case differs from unit testing in the sense it focuses mainly on the
interfaces & flow of data/information between the modules. Here priority is to be
given for the integrating links rather than the unit functions which are already tested.
 Example of Integration Testing (1): Let’s assume that an application has 3 modules
say 'Login Page', 'Mailbox' and 'Delete emails' and each of them is integrated logically.
 Here do not concentrate much on the Login Page testing as it's already been done
in Unit Testing But check how it's linked to the Mail Box Page and delete emails’. So
to perform integration testing in the following ways:
 Check the interface link between the Login and Mailbox module.
 Check the interface link between the Mailbox and Delete Mails Module.

3
 Example of Integration Testing (2):
 For example, when we check login and sign up features in an e-commerce
app, we view them as separate units (in unit testing).
 If we check the ability to log in or sign up after a user adds items to their
basket and wants to proceed to the checkout, we check the integration
between these two functionalities (integration testing).

4
 Example of Integration Testing (3): Let’s take an example of an online
shopping website that contains the following modules that are logically
integrated.
 User Sign-up/Login
 Product Catalogue
 Shopping Cart
 Billing

 The QA team reported that there were bugs like:


 after logging in, the user’s shopping cart did not show items they had added earlier
 the bill amount did not include shipping cost etc.

In this way, Integration Testing helps us identify issues which are present in
the working of the dependent modules as a whole.

5
 Stubs and Drivers
 Stubs and Drivers are the dummy
programs (piece of code) used in
integration testing to facilitate the
software testing activity.
 These programs act as a substitutes for
the missing modules in the testing.
 Both are created during the integration
testing and discarded afterwards.
 Stub: Is called by the Module under Test.
 Driver: Calls the Module to be tested.

6
 Stubs are used when one has the major module ready to test, but
the sub modules are still not ready yet. So in a simple language
stubs are "called" programs, which are called in to test the major
module's functionality.
 For example, in a situation where one webpage has three different
modules: Login, Home, User. Suppose login module is ready for
test, but the two minor modules Home and User, which are called
by Login module are not ready yet for testing. At this time, a piece
of dummy code is written, which simulates the called methods of
Home and User. These dummy pieces of code are the stubs.

7
 On the other hand, Drivers are the ones, which are the "calling"
programs. Drivers are used in bottom up testing approach. Drivers
are dummy code, which is used when the sub modules are ready but
the main module is still not ready.
 Taking the same example. Suppose this time, the User and Home
modules are ready, but the Login module is not ready to test. Now
since Home and User return values from Login module, so a
dummy piece of code is written, which simulates the Login module.
This dummy code is then called Driver.

8
 In the Incremental Integration Testing approach, testing is done by
integrating two or more modules that are logically related to each other and
then tested for proper functioning of the application. Then the other related
modules are integrated incrementally and the process continues until all the
logically related modules are integrated and tested successfully.
 Incremental Approach, in turn, is carried out by two different Methods:
 Bottom Up
 Top Down

9
 Top Down Integration Testing is a method in which integration testing
takes place from top to bottom following the control flow of software
system. The higher level modules are tested first and then lower level
modules are tested and integrated in order to check the software
functionality. Stubs are used for testing if some modules are not ready.

10
 Bottom-up Integration Testing is a strategy in which the lower level
modules are tested first. These tested modules are then further used to
facilitate the testing of higher level modules. The process continues until all
modules at top level are tested. Once the lower level modules are tested and
integrated, then the next level of modules are formed.

11
BOOK READING
 Contents covered so far.

12

You might also like