Unit 4- Integration Testing

Integration Testing
 Integration testing is testing in which a group of components is combined to
produce output.
 The focus of the integration testing level is to expose defects at the time of
interaction between integrated components or units.
 When we combine two units, we may like to test the interfaces amongst these
units.
 We combine two or more units because they share some relationship.
 This relationship is represented by an interface and is known as coupling.
 The coupling is the measure of the degree of interdependence between
units.
 Two units with high coupling are strongly connected – dependent on each other
 Two units with low coupling are weakly connected – low dependency on each
other
Cont..

 Coupling increases when

 the number of calls amongst units increases
 the amount of shared data increases
 A design with high coupling may have more errors.
 if coupling is high, a large number of test cases should be designed to test
that particular interface.
 When a new unit is added as a part of integration testing, then the software is
considered as a changed software.
 New paths are designed and new input(s) and output(s) conditions may
emerge and new control logic may be invoked.
 These changes may also cause problems with units that previously worked
flawlessly.
Cont..

Advantages of Integration testing

 It helps to find defects from links and interfaces between the modules.
 It boosts the confidence level of the team in the product as it validates the group of
modules together.
 Integration tests run faster than the end to end test scenarios.
 It results in higher code coverage.
Disadvantages of Integration testing
 Time taken for the whole process is more;
 The process of testing does not finish till all the modules of both the top and the
bottom levels are included and tested.
Types of integration testing
 Big Bang Approach
 Incremental Approach
Top Down Approach
Bottom Up Approach
Sandwich Approach
1) Big- bang approach
This method involves integrating all the modules and components and testing them
once as a single unit.
This method is also known as non-incremental integration testing.
This sort of testing generally suits smaller systems.
2) Incremental Approach
Incremental integration testing is performed by combining logically related two or
more modules.
Every module will be added one by one in the testing unit until the testers complete
the whole system.
Types of Incremental Approach:
 Top-Down approach
 The top-down testing strategy deals with the process in which higher level
modules are tested with lower level modules.
 Bottom-Up approach
 The bottom to up testing strategy deals with the process in which lower level
modules are tested with higher level modules.
 Sandwich Integration approach
 It is a combination of Bottom-up and Top-down Approaches.
 In this approach, bottom modules are tested with top modules, at the same time, the
top modules are tested with the lower modules.
Characteristics of Integration Testing
 We go for the integration testing only after the unit testing is completed on each
module of the application.
 We always do integration testing by picking module by module so that a proper
sequence is followed, and also we don't miss out on any integration scenarios.
 First, determine the test case strategy through which executable test cases can
be prepared according to test data.
 Examine the structure and architecture of the application and identify the
crucial modules to test them first and also identify all possible scenarios.
 Design test cases to verify each interface in detail.
 Choose input data for test case execution. Input data plays a significant role in
testing.
 If we find any bugs then communicate the bug reports to developers and fix
defects and retest.
 Perform positive and negative integration testing.
System Integration Techniques

 Integration testing need not wait until all the modules of a system are
coded and unit tested.
 Instead, it can begin as soon as the relevant modules are available.
 A module is said to be available for combining with other modules when the
module’s check-in request form is ready.
 Some common approaches to performing system integration are as follows:
 Incremental
 Top down
 Bottom up
 Sandwich

 Big bang
Incremental Approach

 In this approach, integration testing is conducted in an incremental

manner as a series of test cycles.
 In each test cycle, a few more modules are integrated with an existing
and tested build to generate a larger build.
 The idea is to complete one cycle of testing, let the developers fix all the
errors found, and continue the next cycle of testing.
 The complete system is built incrementally, cycle by cycle, until the
whole system is operational and ready for system-level testing.
Cont..

 In each cycle, a new layer is added to the core and tested to form a new
core.
 The new core is intended to be self-contained and stable.
 Self-contained means containing all the necessary code to support a
set of functions
 Stable means that the subsystem (i.e., the new, partial system) can
stay up for 24 hours without any anomalies.
Cont..

 The number of system integration test cycles and the total integration
time are determined by the following parameters:
 Number of modules in the system
 Relative complexity of the modules (cyclomatic complexity)
 Relative complexity of the interfaces between the modules
 Number of modules needed to be clustered together in each test cycle
 Whether the modules to be integrated have been adequately tested before
 Turnaround time for each test–debug–fix cycle
Cont..

 Constructing a build is a process by which individual modules are

integrated to form an interim software image.
 A software image is a compiled software binary.
 A build is an interim software image for internal testing within the
organization.
 Eventually, the final build will be a candidate for system testing, and
such a tested system is released to the customers.
Cont..

 Constructing a software image involves the following activities:

 Gathering the latest unit-tested, authorized versions of modules
 Compiling the source code of those modules
 Checking in the compiled code to the repository
 Linking the compiled modules into subassemblies
 Verifying that the subassemblies are correct
 Exercising version control
Cont..

 A simple build involves only a small number of modules

 No special tool or procedure needs to be developed and documented for
a simple build.
 Organized, well-documented procedures are applied for complex builds.
 A build process becomes complicated if a large number of modules are
integrated.
 For complex builds, a version control tool is highly recommended for
automating the build process and for fast turnaround of a test–debug–fix
cycle.
Cont..

 The software developer fills out a check-in request form before a new
software module or a module with an error fix is integrated into a build.
 The form is reviewed by the build engineering group for giving approval.
 Once it is approved, the module can be considered for integration.
 The idea behind having a check-in request mechanism is:
 All the files requiring an update must be identified and known to other team
members.
 The new code must have been reviewed prior to its integration.
 The new code must have been unit tested.
 The scope of the check-in is identified.
Cont..

 A release note containing the following information accompanies a build:

 What has changed since the last build?
 What outstanding defects have been fixed?
 What are the outstanding defects in the build?
 What new modules or features have been added?
Check-in Request Form

Author Name of the person requesting this

check-in
Today’s date Month, day, year
Check-in request date Month, day, year
Category (Identify all that type) New Feature : (Y, N)
Enhancement : (Y, N)
Defect: (Y, N)
If yes: defect numbers
Are any of these major defects: (Y,
N) Are any of these moderate
defects: (Y, N)
Short description of check-in Describe in a short paragraph the
feature, the enhancement, or the
defect fixes to be checked in.
Check-in Request Form

Number of files to be checked in Give the number of files to be

checked in. Include the file names, if
possible.
Code reviewer names Provide the names of the code
reviewers.
Command line interface changes (Y, N); if yes, were they:
made Documented? (Y, N) Reviewed? (Y,
N, pending)
Does this check-in involve changes (Y, N); if yes, include the header file
to global header? names
Does this check-in involve changes (Y, N); if yes, were they
in output logging? documented? (Y, N)
Unit test description Description of the unit tests
conducted
Comments Any other comments and issues
Top-Down Approach

 Systems with hierarchical structures generally use top-down and

bottom-up approaches for integration.
 In a hierarchical system, a first, top-level module is decomposed into a
few second-level modules. Some of the second-level modules may be
further decomposed into third-level modules, and so on.
 Some or all the modules at any level may be terminal modules, where a
terminal module is no longer decomposed.
 An internal module, also known as a nonterminal module, performs
some computations, invokes its subordinate modules, and returns
control and results to its caller.
Cont..

 The Top-Down Approach in incremental integration testing is a

systematic testing strategy where integration testing begins with the
highest-level modules in the software hierarchy and progresses
downwards to the lower-level modules.
 This approach is used to verify that the high-level control structure of
the software works as expected before integrating and testing the lower-
level modules.
Cont..

 In top-down and bottom-up approaches, a design document giving the

module hierarchy is used as a reference for integrating modules.
 Fig shows Module hierarchy with three levels and seven modules.

 Module A is the topmost module; module A has been decomposed into

modules B, C, and D. Modules B, D, E, F, and G are terminal modules, as
these have not been further decomposed.
Cont..
Cont..
Key Steps in the Top-Down Approach:

 Start with the Main Control Module:

 Testing begins with the top-level module, often the main control module or the
module that handles the core functionality of the software.
 Stubs:
 Since lower-level modules may not be ready or fully developed, stubs are
used to simulate their behavior.
 A stub is a simple implementation that mimics the interface of a lower-level
module, but with limited functionality.
 It returns expected outputs without performing the actual operations.
What is Stub and Driver?
 The term stubs and drivers refers to the replica of the modules, which acts as a
substitute to the undeveloped or missing module.
 The stubs and drives are specifically developed to meet the necessary
requirements of the unavailable modules and are immensely useful in getting
expected results.
 Stubs and drivers are used in top-down integration and bottom-up integration
testing respectively and are created mainly for the testing purpose.

Module Stubs Drivers

Stub:
 Stubs are developed by software developers to use them in place of modules, if
the respective modules aren’t developed, missing in developing stage, or are
unavailable currently while Top-down testing of modules.
 Stubs are used when the lower-level modules are needed but are unavailable
currently.
 Stubs are mainly used in Top-Down integration testing.
Stubs are divided into four basic categories based on what they do :
 Shows the traced messages.
 Shows the displayed message.
 Returns the corresponding values that are utilized by modules.
 Returns the value of the chosen parameters(arguments) that were used by the
testing modules.
Driver:

 Drivers serve the same purpose as stubs, but drivers are used in Bottom-up
integration testing and are also more complex than stubs.
 Drivers are used when high-level modules are missing and can also be used when
lower-level modules are missing.
Key Steps in the Top-Down Approach:

 Incremental Integration:
 Once the top-level module is tested and verified, the next set of lower-level
modules is integrated one by one.
 Each time a new module is integrated, the system is tested to ensure that the
new module interacts correctly with the already tested modules.
 Replace Stubs with Real Modules:
 As lower-level modules are developed and become available, the stubs are
replaced with the actual modules.
 Testing continues to ensure that each new module integrates smoothly with
the existing system.
Cont..

 Progression Downwards:
 This process continues, with integration and testing moving downwards
through the module hierarchy until all modules have been integrated and
tested.
 Test Case Design:
 Test cases are designed to validate the integration at each level, focusing on
the interactions between modules and the correct functioning of the
integrated system.
Example: Online Bookstore Website

 Imagine you're developing an online bookstore that has the following

features:
1. Homepage: Displays the main navigation and featured books.
2. Search Functionality: Allows users to search for books.
3. Book Details Page: Shows details about a specific book.
4. Shopping Cart: Allows users to add books to a cart and proceed to
checkout.
5. Checkout Process: Handles payment and order confirmation.
Top-Down Approach in Testing
 Start with the Homepage (Top-Level Module):
• Begin by testing the Homepage since it's the top-level module that users first
interact with.
• At this stage, the Search Functionality, Book Details Page, Shopping
Cart, and Checkout Process might not be fully developed yet.

 Use Stubs for Lower-Level Modules:

• Since the lower-level modules (Search, Book Details, Shopping Cart, Checkout)
aren’t ready, you create stubs for these.
• For example:
• Search Stub: Simulates a search function by returning a list of dummy books.
• Book Details Stub: Shows a generic book details page with placeholder text.
• Shopping Cart Stub: Displays a basic cart with dummy items.
• Checkout Stub: Shows a mock checkout page without real payment
processing.
Cont..
 Test the Homepage with Stubs:
• You integrate the homepage with these stubs and test the navigation between
the homepage and the stubs.
• This ensures that the homepage is functioning correctly and that users can
navigate to different sections.
 Incremental Integration:
 Once the Search Functionality is fully developed, you replace the Search Stub
with the actual search module.
 Test the integration to make sure the homepage correctly interacts with the
real search feature.
 Next, you integrate and test the Book Details Page, replacing the stub with
the actual module.
 Continue this process for the Shopping Cart and finally the Checkout Process.
Cont..

 Progress Downwards:
• As each lower-level module is integrated and tested, you move downwards in
the hierarchy until all features are fully integrated.
• For instance, after integrating the Search, you test how it interacts with the
Book Details Page.
• After integrating the Shopping Cart, you test how items are added from the
Book Details Page to the cart.
• Finally, you test the Checkout Process to ensure it works with the items in the
Shopping Cart.
Bottom-Up Approach

 The Bottom-Up Approach in incremental integration testing is the

opposite of the top-down approach.

 In this method, testing starts with the lowest-level modules (those that
do not depend on other modules) and gradually moves upward through
the hierarchy, integrating and testing higher-level modules as you go.

 This approach ensures that the foundational components of the system

are thoroughly tested before they are integrated into larger subsystems.
Key Steps in the Bottom-Up
Approach:
 Start with the Lowest-Level Modules:
 Begin testing with the modules at the lowest level of the software hierarchy,
typically the utility or helper functions that other modules depend on.
 Drivers:
 Since higher-level modules may not be available for testing yet, drivers are
used to simulate the behavior of these higher-level modules.
 A driver is a piece of code that calls the module being tested, passing its
inputs and verifying its outputs.
Cont..
 Incremental Integration:
 Once the lowest-level modules are tested and verified, they are integrated
into higher-level modules.
 Each time a new higher-level module is integrated, the system is tested to
ensure correct interaction with the already tested modules.
 Replace Drivers with Real Modules:
 As higher-level modules are developed, drivers are replaced with the actual
modules.
 Testing continues to verify that the integration works correctly.
 Progression Upwards:
 This process continues until the top-level module is integrated and the entire
system has been tested.
 Test Case Design:
 Test cases focus on the detailed functionality of each low-level module and
the interactions as modules are integrated.
Example: Online Bookstore Website

 The online bookstore has the following features:

1. Database Access Layer: Manages data storage and retrieval (e.g.,
fetching book details).
2. Search Functionality: Allows users to search for books based on
various criteria.
3. Shopping Cart: Manages the user's selected items before purchase.
4. Checkout Process: Handles payment and order confirmation.
5. Homepage (Top-Level Module): Displays the main navigation and
featured books.
Bottom-Up Approach in Testing
 Start with the Database Access Layer (Lowest-Level Module):
• Begin by testing the Database Access Layer. This module is responsible for
retrieving and storing book details, user information, and order data.
• Testing this layer involves verifying that data is correctly saved, updated,
deleted, and fetched from the database.
• For instance, when a user searches for a book, this layer should return
accurate results based on the search query.
 Use Drivers to Simulate Higher-Level Modules:
 Since higher-level modules like the Search Functionality or Shopping Cart
depend on the Database Access Layer, you create drivers to simulate these
higher-level interactions.
 For example, a driver might simulate a search query and check if the
Database Access Layer returns the correct book information.
Cont..

 Incremental Integration:
• Once the Database Access Layer is thoroughly tested, integrate it with the
Search Functionality.
• Replace the driver used for search simulation with the actual Search module.
Test this integration to ensure that search queries correctly retrieve data from
the database.
• Similarly, integrate and test the Shopping Cart module next. Ensure that it
can retrieve book details from the database and correctly add items to the
cart.
Cont..

 Progress Upwards:
• After integrating the Shopping Cart, move on to the Checkout Process. Test
this module by ensuring that it correctly interacts with both the Database
Access Layer (to store order details) and the Shopping Cart (to retrieve cart
items).

• Finally, integrate the Homepage, which is the top-level module that ties
everything together. The Homepage should correctly display featured books,
handle search queries, and allow navigation to the Shopping Cart and
Checkout Process.
Cont..

 Complete System Testing:

• Once all modules are integrated, perform a full system test.
• This involves verifying that users can navigate from the Homepage to search
for books, add them to the Shopping Cart, and complete the Checkout Process
without issues.
• The integration of all modules ensures that the website functions as expected
from the user's perspective.
Sandwich Approach

 The sandwich approach in incremental integration testing is a hybrid

method that combines both top-down and bottom-up integration
strategies.
 This approach is particularly useful when different components of a
system are developed at varying rates or when the system has multiple
levels of integration, such as a user interface, middle layer, and data
layer.
Cont..
 Three layers
 Top Layer:
 In this part of the sandwich, top-down integration testing begins.
 Higher-level modules (closer to the user interface) are tested first, and stubs
are used to simulate lower-level modules.
 Bottom Layer:
 Simultaneously, bottom-up integration testing starts from the lower-level
modules (like database or utility functions), using drivers to simulate higher-
level modules.
 Middle Layer:
 Once both top-down and bottom-up layers are tested and stabilized, the
middle layer modules are integrated and tested.
 This "sandwiches" the middle layer between the already tested top and
bottom layers.
Example: E-commerce Application

 Three main components:

 User Interface (UI) Layer:
 Responsible for displaying products, handling user inputs, and managing the
shopping cart.
 Business Logic Layer:
 Processes orders, manages inventory and applies business rules.
 Database Layer:
 Handles data storage, retrieval, and management of user accounts, product
information, and order history.
Working of sandwich approach

 Top-Down Testing (UI Layer):

• Start by testing the UI components.
• For instance, the product search functionality, shopping cart updates,
and checkout process are tested.
• Use stubs to simulate responses from the business logic layer.
• For example, when a user adds an item to the cart, a stub will return a
predefined response as if the inventory check has passed.
Cont..

 Bottom-Up Testing (Database Layer):

• Concurrently, begin testing of the database layer. Validate that data
retrieval (e.g., fetching product details) and storage (e.g., saving user
orders) work correctly.
• Use drivers to simulate the interaction from the business logic layer.
• For instance, when an order is placed, the driver would simulate
business logic and directly pass the data to the database for saving.
Cont..

 Middle Layer Testing (Business Logic Layer):

• After the UI and database layers are tested, the business logic layer is
integrated.
• Test interactions between the UI and database via the business logic.
• For instance, when a user adds a product to the cart, it checks inventory
levels, updates the database, and then returns the updated cart details
to the UI.
Big Bang Approach

 The Big Bang approach in software testing is a method where all

components or modules of a software system are integrated together at
once, after which the system is tested as a whole.

 This approach is often considered the simplest but can be risky because
it waits until everything is developed before any integration testing
begins.
How the Big Bang Approach Works?

 Development Phase:
 Each module or component of the software is developed independently
without any prior integration testing.
 Integration Phase:
 Once all the modules are developed, they are integrated together in one go.
 Testing Phase:
 After integration, the system is tested as a whole to identify any defects or
issues.
Example: Developing a Mobile
Banking Application
 Consider the development of a mobile banking application that includes
several modules, such as:
1. User Authentication: Handles login, registration, and password
management.
2. Account Management: Displays account balances, transaction history,
and account details.
3. Fund Transfers: Allows users to transfer money between accounts or
to other users.
4. Bill Payments: Manages the payment of bills and viewing payment
history.
Applying the Big Bang Approach:

 Independent Development:
 Each module—User Authentication, Account Management, Fund Transfers, and
Bill Payments—is developed by separate teams without any prior integration
testing between them.
 Integration:
 Once all the modules are completed, they are integrated together in one large
step. This means that the User Authentication module is combined with the
Account Management, Fund Transfers, and Bill Payments modules all at once.
 System Testing:
 After integration, the entire mobile banking application is tested as a single
system. The testing team checks the flow from user login to account
management, fund transfers, and bill payments.
Challenges and Risks:

 Late Detection of Defects:

 Since integration and system testing happen only after all modules are
integrated, defects related to module interactions might be discovered very
late in the development process.
 Complex Debugging:
 If a defect is found, it can be challenging to pinpoint which module or
interaction between modules caused the issue, as all components were
integrated simultaneously.
 Time and Cost:
 Fixing defects at this stage can be more time-consuming and costly, as
multiple modules might need to be revisited and revised.
When to Use Big Bang Testing

 Small, Simple Systems:

 Big Bang testing might be appropriate for smaller systems with fewer
components where the risk of complex integration issues is low.

 Limited Time and Resources:

 In situations where there is limited time or resources, and the system is not
too complex, Big Bang might be used to quickly get a working system for
testing.
Summary

 Top-down integration strategies are most effective in terms of defect

correction.

 Top-down and big-bang strategies produced the most reliable systems.

 Bottom-up strategies are generally least effective at correcting defects

and produce the least reliable systems.

 Systems integrated by the sandwich strategy are moderately reliable in

comparison.
Module Integration Testing

 Module Integration Testing involves combining individual modules of a

software application and testing them as a group.

 This testing phase aims to identify issues that may arise when modules
interact with each other.

 To effectively conduct module integration testing, especially when some

modules are not yet fully developed, stubs and drivers are used.
Stub-Driver Design in Module
Integration Testing
 Stubs and Drivers are temporary codes used in module integration
testing to simulate the behavior of incomplete modules:

 Stub: A stub is a piece of code that simulates the behavior of lower-

level modules that a higher-level module depends on. It is used when
the lower-level modules are not yet developed or available for testing.

 Driver: A driver is a piece of code that simulates the behavior of higher-

level modules that interact with a module under test. It is used when the
higher-level modules are not yet available.
Process of Stub-Driver Design

 Identify Modules to Test:

 Determine which module is ready for integration testing and which dependent
modules (higher or lower) are not yet available.

 Design and Implement Stubs:

 When a higher-level module (Module A) depends on a lower-level module
(Module B) that is not yet developed, create a stub for Module B.
 The stub mimics the interface and behavior of Module B but provides
simplified or hardcoded responses that allow Module A to be tested.
Cont..

 Design and Implement Drivers:

• When a lower-level module (Module B) needs to be tested but the higher-level
module (Module A) that would call it is not ready, create a driver for Module A.
• The driver simulates the calls to Module B as the higher-level module would
do, enabling testing of Module B.

 Perform Integration Testing:

• Test the integrated module using the stubs and drivers. Validate that the
module under test behaves correctly when interacting with the simulated
modules.
• As real modules become available, replace stubs and drivers with the actual
code and continue integration testing.
Example: Online Shopping System

 Consider an online shopping system with the following modules:

1. User Interface Module (UI Module): Handles user interactions, such

as adding items to the cart.
2. Cart Module: Manages the shopping cart, including adding and
removing items.
3. Payment Module: Processes payments.
Testing Cart Module Using Stub-Driver
Design:
 Testing with a Stub:
• The Cart Module is ready for testing, but the Payment Module is still
under development.
• A stub is created for the Payment Module, which simulates the payment
process by returning a success message whenever a payment is
initiated.
• The Cart Module is tested to ensure that it correctly interacts with the
Payment Module stub, such as proceeding to checkout and "processing"
a payment.
Cont..

 Testing with a Driver:

• The Cart Module needs to be tested, but the UI Module that interacts
with it is not yet available.
• A driver is created to simulate the UI Module's behavior, such as adding
items to the cart and removing them.
• The Cart Module is tested using the driver to ensure it correctly handles
the actions initiated by the UI Module.
Advantages of Stub-Driver Design

 Early Testing: Allows testing of modules even when dependent

modules are incomplete, enabling earlier detection of defects.

 Isolated Testing: Helps isolate and test individual modules in isolation

from the rest of the system, simplifying the debugging process.

 Flexibility: Provides flexibility in managing dependencies and testing

schedules, allowing parallel development and testing.
Application Programming Interface Testing
 API testing is a type of software testing that focuses on the testing of individual API
methods and the interactions between different APIs.
 This type of testing is typically performed at the integration level, after unit testing
is completed, and before user interface testing begins.
 It is used to validate that the API behaves correctly and that it meets the
requirements of the system.
 API testing can be performed manually or using automated testing tools. Some
common tasks that are performed during API testing include:
 Testing the functionality of the API to ensure it behaves as expected.
 Verifying that the API returns the correct response for different input values Checking for
error handling and validation of input.
  Testing for security risk.
 Checking for performance and scalability of the API.
 API testing is important because it ensures that the different components of a
system can communicate with each other correctly and that the system can
handle a large volume of requests.
API testing typically includes the following steps:
 Reviewing the API documentation to understand the functionality and
expected inputs and outputs.
 Writing test cases that exercise the different functionality of the API.
 Executing the test cases and comparing the expected results with the actual
results.
 Analysing the results and identifying any issues that need to be fixed.
 Types of API Testing:
1) Functional Testing
 Ensures that the API functions as expected, according to the defined specifications
and requirements.
 Example: Verifying that an API returns the correct response when provided with
valid input parameters.
2) Security Testing
 Validates the security features of the API, ensuring it is protected against
unauthorized access, data breaches, and other vulnerabilities.
 Example: Testing for security issues such as SQL injection, cross-site scripting (XSS),
and ensuring that sensitive data is properly encrypted.
3) Performance testing
 Assesses the API’s performance in terms of response time, throughput, and
scalability.
 Example: Measuring how fast the API responds to requests under different network
conditions or loads.
Cont..

4) Interoperability testing
 Ensures that the API can interact correctly with other APIs, systems, or components.
 Example: Verifying that the API correctly handles data from another service or API
and returns the expected result.

5) Usability Testing
 Assesses the API’s usability from the perspective of developers and end-users,
ensuring that it is easy to understand, use, and integrate.
 Example: Reviewing the API documentation and error messages to ensure they are
clear and helpful.
Cont..

Tools which are used for API Testing :

 Postman
 Katalon Studio
 Soap UI
 Parasoft
 REST assured
 Ping API
 Assertible
API Authentication:
Authentication:
 The processes of certifying the identity of users trying to access resources on the
server and this is what is known as API authentication.
 Common Methods of API Authentication
1) HTTP Basic Authentication
2) API Key Authentication
3) OAuth Authentication

1) HTTP Basic Authentication:

HTTP Basic Authentication is the simplest form of identification. This technique
combines username and password to form a single value and passes it through a
special HTTP header known as authorization where they are encoded with Base64.
2) API Key Authentication
The API key is usually a long series of numbers and letters that you either include in
the request header or request URL.
When the client authenticates the API key, the server stamps their identity and allows
them to access data.

3) OAuth Authentication
OAuth is a technique that does both authentication and authorization. It is a form of
API authentication that allows applications to communicate with API server to
provide access.
OAuth authentication is fundamentally a more secure and powerful system than the
others.
Test Automation or Automation testing
 Test Automation is the best way to increase the effectiveness, test
coverage, and execution speed in software testing.

Automated software testing is important due to the following reasons:

 It is difficult to test for multilingual sites manually.
 Test Automation in software testing does not require Human
intervention.
 Test Automation increases the speed of test execution
 Automation helps increase Test Coverage
Which Test Cases to Automate?

Test cases to be automated can be selected using the following

criterion
 High Risk – Business Critical test cases
 Test cases that are repeatedly executed
 Test Cases that are very tedious or difficult to perform manually
 Test Cases which are time-consuming
The following category of test cases are not suitable for
automation:
 Test Cases that are newly designed and not executed manually at
least once
 Test Cases for which the requirements are frequently changing
Automated Testing Process:

 Following steps are followed in an Automation Process

Step 1) Test Tool Selection
Step 2) Define scope of Automation
Step 3) Planning, Design and Development
Step 4) Test Execution
Step 5) Maintenance

Step 1) Test Tool Selection

 Test Tool selection largely depends on the technology the Application
Under Test is built on.
 Each type of tool or framework may serve different demands,
therefore having a thorough understanding of multiple tool types is
also a important factor in choosing your best tool.
Step 2) Define scope of Automation
 The scope of automation means the area of your Application Under
Test that will be automated.
 Following points help determine scope:
 The features that are important for the business
 Scenarios which have a large amount of data
 Common functionalities across applications
 Technical feasibility
 The extent to which business components are reused
 The complexity of test cases
 Ability to use the same test cases for cross-browser testing
Step 3) Planning, Design and Development
 In this step, we create an Automation strategy & plan, which contains
the following details-
 Automation tools selected
 Framework design and its features
 In-Scope and Out-of-scope items of automation
 Schedule and Timeline of scripting and execution
 Deliverables of Automation Testing
Step 4) Test Execution
 Automation Scripts are executed during this phase. The scripts need
input test data before there are set to run. Once executed they provide
detailed test reports.
 Execution can be performed using the automation tool directly or
through the Test Management tool which will invoke the automation tool.
Step 5) Maintenance
 Test Automation Maintenance Approach is an automation testing
phase carried out to test whether the new functionalities added to the
software are working fine or not.
 Maintenance in automation testing is executed when new automation
scripts are added and need to be reviewed and maintained in order to
improve the effectiveness of automation scripts.
Key Elements of Integration Testing

 Test Set-up
 Test Parameters
 Test Integration
 Test Results
 Actions
 Test Automation
Test Set-up
 Test Set-up involves preparing the environment where the integration
tests will be conducted.
 This includes configuring the hardware, software, network, and other
necessary resources.

 Example: Suppose you are testing the integration of a shopping cart

module with a payment gateway in an e-commerce application. The test
set-up would involve:
• Setting up the development environment (e.g., a local server or cloud
environment).
• Installing the necessary software components like the web server,
database server, and payment gateway API.
• Configuring the database with test data, including user accounts and
products.
Test Parameters

 Test Parameters are the inputs or conditions under which the

integration tests are executed.
 These parameters define the scenarios that will be tested.

 Example: For the shopping cart and payment gateway integration:

• Test with different payment methods (credit card, PayPal, etc.).
• Test with different user roles (registered user, guest user).
• Test with various cart values (small amount, large amount).
Test Integration

 Test Integration refers to the actual process of combining and testing

the integrated modules to ensure they work together as expected.

 Example: In the context of the e-commerce application:

• Integrate the shopping cart module with the payment gateway.
• Execute a test where a user adds items to the cart and proceeds to
checkout.
• Verify that the payment gateway processes the transaction correctly and
that the order is confirmed.
Test Results

 Test Results are the outcomes of the executed integration tests. They
indicate whether the test scenarios passed or failed.

 Example: After running the integration tests:

• The test result may show that the payment gateway correctly processes
the payment and sends a confirmation email to the user.
• However, it may also reveal a failure, such as the payment gateway not
handling declined transactions properly, or the order status not being
updated in the database.
Actions

 Actions are the steps taken based on the test results.

 This could involve fixing defects, re-running tests, or updating
documentation.

 Example: If the test result indicates a failure:

• The development team would investigate and fix the issue in the
payment gateway integration.
• Once the issue is resolved, the test would be re-executed to ensure the
fix is successful.
• The test documentation may also be updated to include the new test
scenarios.
Test Automation

 Test Automation involves using tools to automatically execute

integration tests, reducing manual effort and increasing test coverage.

 Example: Using a test automation tool like Selenium:

• Automate the process of adding items to the cart, checking out, and
processing payments.
• Set up the automation scripts to run nightly to ensure that any new code
changes do not break the integration.
• The automated tests can generate reports showing which tests passed
or failed.