Unit-3 Software Testing GTET

SATM (simple Automatic Teller Machine)

A simple Automatic Teller Machine (ATM) is a device that allows users to
perform basic banking transactions without the need for a human teller.
These transactions typically include withdrawing cash, depositing funds,
checking an account balance, transferring money between accounts, and
sometimes even paying bills or purchasing prepaid mobile phone credit.

basu..
Unit-3 Software Testing GTET

Levels of Testing in SATM System

1) Unit Testing: At this level, individual components of the ATM system are
tested in isolation.
For example, testing the functionality of the card reader, keypad, cash dispenser,
and receipt printer separately to ensure they perform as expected.
2) Integration Testing: Integration testing involves testing the interactions
between various components of the ATM system.
This includes testing how the card reader interacts with the keypad, how the cash
dispenser responds to withdrawal requests, and how the receipt printer
communicates with the transaction processing unit.
3) System Testing: System testing evaluates the entire ATM system as a whole.
This includes testing end-to-end scenarios such as card insertion, PIN entry,
transaction processing, cash withdrawal, balance inquiry, and receipt printing to
ensure the system functions correctly in real-world usage scenarios.

basu..
Unit-3 Software Testing GTET

4) Acceptance Testing: Acceptance testing is performed to validate whether the

ATM system meets the specified requirements and is acceptable for deployment.
It may involve testing by stakeholders, including bank representatives and end-
users, to ensure that the ATM system meets their needs and expectations.
5) Regression Testing: Regression testing ensures that any changes or updates to
the ATM system do not introduce new defects or break existing functionality.
It involves retesting previously tested features and functionalities to verify that
they still work as intended after modifications or enhancements.
6) Performance Testing: Performance testing evaluates the ATM system's
responsiveness, reliability, and scalability under various load conditions.
This includes testing the system's response times, transaction processing speed,
and concurrent user handling to ensure optimal performance during peak usage
periods.
7) Security Testing: Security testing assesses the ATM system's resistance to
potential security threats and vulnerabilities.
It involves testing for vulnerabilities such as card skimming, PIN interception,
unauthorized access, and data breaches to ensure the security and integrity of the
ATM system.

Step Description Expected Actual Result Pass/Fail

Result
1 Unit Testing: Test Card reader Card reader reads Pass
card reader successfully reads card
functionality card
2

basu..
Unit-3 Software Testing GTET

Structural and Behavioural of SATM

Structural Insights:
Physical Design: ATMs are designed with a secure enclosure containing the
necessary hardware components such as a card reader, cash dispenser, PIN pad,
and sometimes a printer for receipts.
User Interface: They have a user-friendly interface typically consisting of a
screen, keypad, and card slot. The interface is designed for ease of use and
accessibility for a wide range of users.
Connectivity: ATMs are connected to a network, usually through the internet or
a dedicated line, enabling communication with the bank's servers for transaction
processing.
Security Features: ATMs are equipped with various security measures such as
encryption for data transmission, PIN verification, tamper-resistant casing,
surveillance cameras, and sometimes even biometric authentication.
Cash Handling Mechanism: ATMs have a secure cash vault and a mechanism
for dispensing the correct amount of cash requested by the user.
Maintenance Access: There is typically a secure access point for authorized
personnel to maintain and service the ATM, including cash replenishment and
hardware maintenance.
Behavioral Insights:
User Interaction: ATMs are designed to guide users through the transaction
process with clear prompts on the screen and audio instructions if needed. The
interface is designed to be intuitive, minimizing the need for assistance.
Transaction Flow: The ATM software is programmed to guide users through the
steps required to complete various transactions such as cash withdrawals, balance
inquiries, fund transfers, and bill payments.
Error Handling: ATMs are equipped to handle various error scenarios such as
incorrect PIN entry, insufficient funds, communication errors, etc. They provide
informative messages to users to help them understand and resolve the issue.
Feedback Mechanism: ATMs may provide feedback to users after completing a
transaction, such as printing a receipt or displaying a confirmation message on
the screen. This feedback helps users confirm that their transaction was
successful.

basu..
Unit-3 Software Testing GTET

Security Prompts: ATMs incorporate security measures such as prompting users

to cover the keypad while entering their PIN, advising users to be cautious of
surroundings, and warning about card skimming devices.
Accessibility: ATMs are designed to accommodate users with disabilities,
incorporating features such as tactile keypads, audio instructions, and options for
text enlargement on the screen.

Closer look at SATM system in integration testing

Integration testing of a simple Automatic Teller Machine (ATM) system involves
verifying that individual components or modules of the system work together as
expected.
1) Identifying Modules:
• Break down the ATM system into smaller modules or components such as
user interface, transaction processing, account management, cash
dispensing, receipt printing, etc.
2) Testing Approach:
• Top-Down Integration: Start with testing the main module (e.g.,
transaction processing) and gradually integrate and test lower-level
modules.
• Bottom-Up Integration: Begin with testing individual modules and
gradually integrate and test higher-level modules.

3) Interface Testing: Ensure that each module communicates correctly with

other modules. This involves checking inputs, outputs, and data exchange
between modules.

basu..
Unit-3 Software Testing GTET

4) Transaction Processing:
• Verify that transactions initiated by users are correctly processed and
updated in the system.
• Test various transaction types such as balance inquiry, cash withdrawal,
fund transfer, etc., ensuring each transaction is processed accurately.
5) Account Management:
• Test the functionality related to account creation, modification, and
deletion.
• Ensure that account information is correctly retrieved and updated during
transactions.
6) Cash Handling:
• Test cash dispensing functionality to ensure the correct amount is
dispensed for withdrawals.
• Verify that the ATM accurately tracks the cash available in the machine and
handles low cash scenarios appropriately.
7) Error Handling:
• Test how the system handles errors such as invalid inputs, insufficient
funds, network failures, etc.
• Verify that appropriate error messages are displayed to users and
transactions are rolled back or halted when necessary.
8) Concurrency Testing:
• Check how the system handles multiple transactions occurring
simultaneously, ensuring data integrity and proper synchronization.
9) Security Testing:
• Verify that the system enforces proper security measures such as user
authentication, encryption of sensitive data, and protection against
unauthorized access.
9) Performance Testing:
• Evaluate the system's response time, throughput, and resource utilization
under normal and peak loads.
• Ensure that the ATM system can handle a reasonable number of concurrent
users without degradation in performance.
10) Regression Testing:

basu..
Unit-3 Software Testing GTET

After making changes or fixes to the system, re-run integration tests to ensure that
existing functionalities have not been adversely affected.
11) Mocking and Stubs:
Use mocks or stubs to simulate the behavior of external dependencies such as
banking systems or network services during testing.
12) Documentation:
• Document integration test cases, including inputs, expected outputs, and
actual results, for future reference and maintenance.
Test Scenario Expected Outcome Actual Outcome Pass/Fail
Transaction Processing module
User enters correct verifies credentials, allows access
account number and to account, and prompts for Transaction proceeds as
PIN transaction. expected. Pass
Transaction Processing module
User enters incorrect rejects access, displays error Error message displayed, access
PIN message. denied. Pass

Transaction Processing module

User selects balance retrieves account balance and Correct account balance
inquiry displays it to the user. displayed on the screen. Pass
Correct amount of cash
Transaction Processing module dispensed by Cash Dispensing
User selects withdrawal verifies balance, requests cash module, and account balance
and enters valid amount from Cash Dispensing module. updated accordingly. Pass
User attempts Transaction Processing module
withdrawal with rejects transaction, displays error Error message displayed,
insufficient funds message. withdrawal not processed. Pass

Transaction Processing module

ATM runs out of cash detects low cash condition, Error message displayed,
during withdrawal displays error message. withdrawal not processed. Pass
Multiple users attempt Transaction Processing module Both transactions processed
withdrawals handles concurrent transactions correctly without data
simultaneously without errors. corruption. Pass
Error in communication Transaction Processing module
between modules fails to communicate with Cash Error message displayed,
(mock scenario) Dispensing module. transaction halted. Pass
ATM displays blank
screen or crashes ATM system fails to respond to Issue logged, further
unexpectedly user inputs. investigation required. Fail

basu..
Unit-3 Software Testing GTET

Deference between Top-Down Integration and Bottom-Up Integration

Aspect Top-Down Integration Bottom-Up Integration
Integration starts from the top level Integration starts from the bottom
Overview and moves down. level and moves up.
Higher-level modules are integrated Lower-level modules are integrated
Process first. first.
Uses stubs to simulate lower-level Uses drivers to simulate higher-level
Simulation modules. modules.
Early testing of major system Early testing of lower-level
Advantages functionalities. functionalities.
Higher-level architecture might not be
Disadvantages Lower-level modules are tested later. fully tested.
Dependency
Management Stub creation required. Driver creation required.
May miss defects in lower-level May miss defects in higher-level
Risk Management modules. modules.
Higher-level functionalities are Lower-level functionalities are tested
Testing Approach tested first. first.
May require additional effort to May require additional effort to create
Complexity create stubs. drivers.
Suitable for systems with well- Suitable for systems with complex
Scalability defined architectures. lower-level modules.
Provides early insight into system Offers early validation of lower-level
Visibility behavior. functionalities.
Integration of high-level modules Integration of low-level modules
Integration Time happens early. occurs early.
Debugging may involve tracing Debugging may involve identifying
Debugging issues across layers. issues at lower levels.
System Helps in understanding system Provides insight into the functionality
Understanding architecture. of components.
Changes may require modifications Changes may affect integration of
Change Management across layers. lower-level modules.
Collaboration between teams may Collaboration may be easier as teams
Collaboration be challenging. work on modules.

basu..
Unit-3 Software Testing GTET

Decomposition-based integration testing

Decomposition-based integration testing is a strategy used in software testing to
ensure that individual components or modules of a software system work
correctly together when integrated.
• Decomposition: The software system is broken down into smaller,
manageable components or modules. Each module is then tested
independently to ensure that it performs its intended functions accurately.
Sandwich Integration
Sandwich Integration is an integration approach in software development that
combines elements of both top-down and bottom-up integration strategies.
It involves integrating modules or components of a system simultaneously from
both the higher-level and lower-level ends of the system hierarchy.
Advantages
• Combines top-down and bottom-up approaches.
• Ensures critical functions and components are tested early.
• Allows teams to work on different parts simultaneously.
• Adjustments can be made based on feedback.
• Comprehensive Testing: Ensures thorough testing of the entire system.
Call Graph-Based Integration
Call Graph-Based Integration Testing is a software testing technique that focuses
on analyzing the call graph of a software system to guide integration testing
efforts.
Call Graph:
• A call graph is a directed graph that represents the calling relationships
between different modules, functions, or methods in a software system.
• In simple terms, it shows how different parts of the software interact with
each other by calling one another.
• Nodes: Each node represents a component, module, function, or method in
the software.
• Edges: The edges between nodes represent the calling relationships
between these elements. If component A calls component B, there will be
an edge from node A to node B in the call graph.

basu..
Unit-3 Software Testing GTET

Pairwise integration
Pairwise integration testing is a method used in software testing where modules
or components are integrated and tested in pairs.
Modules are grouped into pairs based on certain criteria, such as dependencies,
functionality, or criticality.
Each pair typically consists of two modules that need to interact with each other
to perform a specific task or function.
This approach focuses on testing the interactions between pairs of modules.
Advantages
• Saves time compared to testing every possible combination.
• Catches important problems early in the development process.
• Focuses testing efforts on critical module interactions, saving resources.
• Easier to manage than testing every combination, keeping testing
straightforward.
• Helps ensure the final product works well and is reliable.
Neighbourhood Integration
refer to a testing approach where components or modules that are closely related
or neighbouring in terms of functionality, dependencies, or system architecture
are integrated and tested together as a group.
• Concentrates on specific, closely related parts of the software.
• Helps find and fix problems early in development.
• Saves time and resources by testing only critical areas.
• Enhances teamwork between developers working on related components.
• Helps developers grasp how different parts of the software work together.
Path-based integration
Path-based integration testing is a software testing approach where tests are
designed and executed based on the paths through which data or control flows
within a software system during its operation.
Identify integration issues, such as data inconsistencies, interface mismatches, or
control flow errors, as early as possible in the development process.
This method focuses on identifying different sequences of operations or functions
that the software can take and then designing tests to cover these paths.

basu..
Unit-3 Software Testing GTET

basu..