Unit 2

Levels of Testing
Levels of Testing
Levels of testing echo the levels of abstraction found in the waterfall model of the SDLC. In
functional testing 3 levels of definition (specification, preliminary design, detailed design) correspond
directly to 3 levels of testing –system, integration & unit testing.

1. Unit Testing:
• Purpose: Test individual units or modules of the software in isolation.
• Example: Testing a function that calculates the sum of two numbers.
2. Integration Testing:
• Purpose: Test the interaction between different units or modules to ensure they work
together as expected.
• Example: Testing the interaction between a user authentication module and a database
access module.
3. System Testing:
• Purpose: Test the complete, integrated system to verify that it meets the specified
requirements.
• Example: Testing a web application to ensure all features work correctly, from user login
to data processing and reporting.
4. Acceptance Testing:
• Purpose: Test the system to ensure it meets the business requirements and is acceptable to
the end users.
• Example: Having end users test the system to ensure it meets their needs and is user-
friendly.

SDLC (Software Development Life Cycle)

SDLC is a sequence of activities carried out by analyst, designer and user to develop and implement
an information system. These activities can be carried out in different stages. SDLC can be broadly
classified into 7 phases.
1. Feasibility Study: The main aim is to determine whether the product is financially worthwhile and
technically feasible.
 2. Requirement analysis: In this phase the aim is to find exact requirement of the customers,
Requirements are classified into
a. Functional Requirements (Input /Output needs) and
b. Non-functional requirements (Constraints like time, cost etc). Finally a SRS document is
prepared as an output.
3. System Design: Software architecture is derived from SRS document. A new system is designed
according to the needs of the user.
4. Development: This is the actual phase where the system is developed. The whole design is built
and implemented.
5. Testing: During implementation phase each module of the design is coded and each module is unit
tested individually. This is to check if each individual module works correctly. This is the most
critical phase.
6. Deployment: The developed system is handed over to the client. The old system is dispensed and
the new system is put to operations and used.
7. Software Maintenance: In this phase adding enhancements, improvements and updates to the new
versions are done.

Different types of SDLC Models are:

1. Waterfall model
2. Spiral model
3. Prototype model
4. Iterative model
5. Agile model
Waterfall Model
This model is a software life cycle where the stages are depicted as cascading from one to another.
It was described by W.W. Royce in 1970. As the figure implies one development stage should be completed
before the next begins.
The waterfall model arranges all the phases sequentially so that each new phase depends on the
outcome of the previous phase. Conceptually, the design flows from one phase down to the next, like that
of a waterfall.

The Waterfall Model is characterized by rigidly defined phases that should be met during the development
process. These phases include:
1. Requirements Gathering: The development team begins by gathering all the requirements for the
software product. This phase includes elements like determining the desired features, scopes, and
boundaries of the project, as well as determining how the software will be tested.
2. Design: Next, the team begins to design the architecture of the software, including the functionality
that will be implemented, the interface design, and the hardware and software environment the
software will run in.
3. Implementation & Testing: Once the design is complete, the actual implementation and testing of
the software can begin. The team will write the code, debug, and test the software, resolving any
issues that arise.
4. Deployment: In the deployment phase, the team will deploy and install the software onto the
customer’s computer or network.
5. Maintenance: Finally, once the software has been deployed, the developers will need to provide
ongoing support, bug fixes, and other maintenance tasks to ensure the software is running as expected.
Advantages of Waterfall Model
a) Easy to explain to the user.
b) Stages and activities are well defined
c) Verification at each stage ensures early detection of errors
d) Widely used to identify and meet the milestones
e) Establishes communication between customer and developer to meet the specifications.
Disadvantages of Waterfall Model
a) The next stage begins only after the previous stage is complete, making it rigid.
b) User training is not given much importance.
c) Interaction with the user takes place right at the beginning and then at the time of deployment,
which creates a gap between the phases.
d) Due to its cascading flow there is very little interaction from the user.

Boehmia’s Spiral Model

Spiral model was proposed by Boehm in 1988.
• Each loop in the spiral represents a phase of the software process.
• Innermost loop is concerned with system feasibility, next loop system requirement, followed by system
design and so on Each loop is split into 4 sectors:
1. Objective setting – Project risks are identified, alternative strategies depending on these risks may
be planned.
2. Risk assessment and reduction - Project risks are identified  detailed analysis carried  steps taken
to reduce risks.
Ex: A prototype system (Toy like implementation with limited functional capabilities and low
reliability just for the purpose of examining)
3. Development and Validation – Choosing the most appropriate development model.
4. Planning – Project is reviewed and decisions are made whether to continue with further loop of the
spiral.

Advantages of Spiral Model

i. High amount of risk analysis
ii. Supports large and high-risk projects
iii. Spiral model is one of the most flexible SDLC models.
iv. Changes can be introduced later in the life cycle as well
v. Project monitoring is easy as each loop requires a review from concerned people.
Disadvantages of Spiral model
i. When to stop the spiral process is not clear.
ii. Cost involved in this model is usually high.
iii. Does not work well for smaller projects.
 Iterative Model
The iterative process suggests that teams begin software development with a small subset of
requirements. Then, they iteratively enhance versions over time until the complete software is ready for
production.

• Iterative development is a way of breaking down the software development of a large application
into smaller pieces.
• The team produces a new software version at the end of each iteration.

Advantages
• Early feedback from stakeholders
• Flexible to requirement changes
• Early risk identification
• Easier bug detection and fixes
• Delivers working software faster
Disadvantages
• Resource and time intensive
• Complex project management
• Documentation challenges
• Requires constant stakeholder involvement
• Can be more expensive overall
Prototype Model
Prototype is a partially developed product /dummy model that allow customers and developers to
analyze if the proposed system is suitable for the finished product.

• A prototype is a toy implementation which is built before starting actual development.

• The reason for developing a prototype is it is impossible to “get it right” the first time; we must
plan to throw away the first product in order to develop a good product.
• The developed prototype is submitted to the customer/user for evaluation, based on the customer
feedback the model is modified/refined. The cycle continues until the customer approves the
prototype.
• The reason for developing a prototype is it is impossible to “get it right” the first time; we must
plan to throw away the first product in order to develop a good product.
• The developed prototype is submitted to the customer/user for evaluation, based on the customer
feedback the model is modified/refined. The cycle continues until the customer approves the
prototype.

Advantages of Prototype Model

i. Modification in prototype is faster.
ii. Helps determine feasibility of the system.
iii. Software Developers commitment is higher.
Disadvantages of Prototype Model
i. Prototyping tools are expensive.
ii. Design and code for the prototype is usually thrown away.
iii. In order to get the prototype work quickly the quality is compromised.
Agile Model
Agile software development refers to a group of software development methodologies based on
iterative development, where requirements and solutions evolve through collaboration between self-
organizing cross-functional teams.
The Agile software development cycle can be broken down into the following six steps:
1. Concept: This is where the initial idea takes shape. Teams identify the opportunity or problem to
solve and outline basic requirements.
2. Inception: The project formally begins. Teams establish the initial scope, rough timelines, basic
architecture, and assemble required resources.
3. Iteration/Construction: This is the core of Agile development. Teams work in short sprints,
continuously building, testing, and refining features. Notice the self-referential loop in the diagram
- this represents the iterative nature of this phase.
4. Release: The software is prepared for deployment. This includes final testing, documentation, and
preparation of deployment procedures.
5. Production: The software is live and being used by end users. There's a feedback loop back to the
Iteration phase for updates and improvements based on real-world usage.
6. Retirement: Eventually, the software reaches end-of-life and is phased out, usually replaced by
newer solutions.

Advantages of Agile methodologies:

• Deployment of software is quicker and thus helps in increasing the trust of the customer.
• Helps in getting immediate feedback which can be used to improve the software in the next
increment.
• Increased collaboration and communication.
• Flexibility and adaptability
• Improved quality and reliability
Disadvantages of Agile methodologies:

• Lack of predictability
• Limited scope control
• Risk of team burnout
The SATM System
To better discuss the issues of integration and system testing, we need an example with larger
scope.
The ATM described here is minimal, yet it contains an interesting variety of functionality and
interactions that typify the client side of client–server systems.

When a bank customer arrives at an SATM station, screen 1 is displayed. The bank customer
accesses the SATM system with a plastic card encoded with a personal account number (PAN), which is a
key to an internal customer account file, containing, among other things, the customer’s name and account
information. If the customer’s PAN matches the information in the customer account file, the system
presents screen 2 to the customer. If the customer’s PAN is not found, screen 4 is displayed, and the card is
kept.

At screen 2, the customer is prompted to enter his or her personal identification number (PIN). If
the PIN is correct (i.e., matches the information in the customer account file), the system displays screen 5;
otherwise, screen 3 is displayed. The customer has three chances to get the PIN correct; after three failures,
screen 4 is displayed, and the card is kept. On entry to screen 5, the customer selects the desired transaction
from the options shown on screen. If balance is requested, screen 14 is then displayed.

If a deposit is requested, the status of the deposit envelope slot is determined from a field in the
terminal control file. If no problem is known, the system displays screen 7 to get the transaction amount.
Integration testing

• Integration testing is a software testing technique that focuses on verifying the interactions and data
exchange between different components or modules of a software application.
• The goal of integration testing is to identify any problems or bugs that arise when different
components are combined and interact with each other.
• Integration testing is typically performed after unit testing and before system testing.
• It helps to identify and resolve integration issues early in the development cycle, reducing the risk
of more severe and costly problems later on.

Decomposition integration testing

There are four types of integration testing approaches.
1. Big-Bang Integration Testing
• It is the simplest integration testing approach, where all the modules are combined and the
functionality is verified after the completion of individual module testing.
• In simple words, all the modules of the system are simply put together and tested.
• This approach is practicable only for very small systems. If an error is found during the integration
testing, it is very difficult to localize the error as the error may potentially belong to any of the
modules being integrated.

Advantages of Big-Bang Integration Testing

• It is convenient for small systems.
• Simple and straightforward approach.
• Can be completed quickly.
• Does not require a lot of planning or coordination.

Disadvantages of Big-Bang Integration Testing

• There will be quite a lot of delay because you would have to wait for all the modules to be
integrated.
• High-risk critical modules are not isolated and tested on priority since all modules are tested at
once.
• Not Good for long projects.
• High risk of integration problems that are difficult to identify and diagnose.
2. Bottom-Up Integration Testing
In bottom-up testing, each module at lower levels is tested with higher modules until all modules
are tested. The primary purpose of this integration testing is that each subsystem tests the interfaces among
various modules making up the subsystem. This integration testing uses test drivers to drive and pass
appropriate data to the lower-level modules.

Advantages of Bottom-Up Integration Testing

• In bottom-up testing, no stubs are required.
• A principal advantage of this integration testing is that several disjoint subsystems can be tested
simultaneously.
Disadvantages of Bottom-Up Integration Testing
• Driver modules must be produced.
• As Far modules have been created, there is no working model can be represented.

3. Top-Down Integration Testing

Top-down integration testing technique is used in order to simulate the behavior of the lower-level
modules that are not yet integrated. In this integration testing, testing takes place from top to bottom. First,
high-level modules are tested and then low-level modules and finally integrating the low-level modules to
a high level to ensure the system is working as intended.
Advantages of Top-Down Integration Testing
• Separately debugged module.
• Few or no drivers needed.
• It is more stable and accurate at the aggregate level.
Disadvantages of Top-Down Integration Testing
• Needs many Stubs.
• Modules at lower level are tested inadequately.
• It is difficult to observe the test output.

4. Mixed Integration Testing

A mixed integration testing is also called sandwiched integration testing. A mixed integration
testing follows a combination of top down and bottom-up testing approaches. This sandwich or mixed
approach overcomes this shortcoming of the top-down and bottom-up approaches. It is also called the
hybrid integration testing. also, stubs and drivers are used in mixed integration testing.

Advantages of Mixed Integration Testing

• Mixed approach is useful for very large projects having several sub projects.
• Parallel test can be performed in top and bottom layer tests.
Disadvantages of Mixed Integration Testing
• For mixed integration testing, it requires very high cost because one part has a Top-down approach
while another part has a bottom-up approach.
• This integration testing cannot be used for smaller systems with huge interdependence between
different modules.

Decomposition testing for SATM

The number of integration tests for a decomposition tree is the following
• For SATM have 42 integration test sessions, which correspond to 42 separate sets of
test cases
• For top-down integration nodes – 1 stubs are needed
• For bottom-up integration nodes – leaves drivers are needed
• For SATM need 32 stubs and 10 drivers
 Call Graph-Based Integration Testing
Call graph-based integration uses the call graph of a program instead of the decomposition tree for
integration testing. The call graph shows the calling relationships between program units like methods.
Pairwise integration restricts testing to pairs of units that call each other based on the call graph edges.
Neighborhood integration tests groups of interconnected units within a radius of one edge from a central
unit. Call graph integration aims to reduce stubs and drivers but can have faults isolation and
redundancy issues for large neighborhoods of units.

Call Graph-Based integration for SATM

Two types of call graph-based integration testing

1. Pair-wise Integration Testing
The idea behind Pair-Wise integration testing

• Eliminate need for developing stubs / drivers

• Use actual code instead of stubs/drivers
• In order not to deteriorate the process to a big-bang strategy
• Restrict a testing session to just a pair of units in the call graph
• Results in one integration test session for each edge in the call graph
 2. Neighborhood Integration Testing
• The set of nodes that are one edge away from the given node
• All the immediate predecessor nodes and all the immediate successor nodes of a given node
• Reduces the number of test sessions
• Fault isolation is more difficult

Advantages

• Aim to eliminate / reduce the need for drivers / stubs

• Closer to a build sequence
• Neighborhoods can be combined to create “villages”
• Suffer from fault isolation problems
Disadvantages

• Redundancy: Nodes can appear in several neighborhoods

• Assumes that correct behavior follows from correct units and correct interfaces
• Call-graph integration is well suited to devising a sequence of builds with which to implement a
system

Path-Based Integration Testing

• Combine structural and behavioral type of testing for integration testing as we did for unit testing
• Focus on interactions among system units
• Rather than merely to test interfaces among separately developed and tested units
• Interface-based testing is structural while interaction-based is behavioral
Key concepts of path-based integration
Source node: A program statement fragment at which program execution begins or resumes.
• For example, the first “begin” statement in a program.
• Also, immediately after nodes that transfer control to other units.

Sink node: A statement fragment at which program execution terminates. The final “end” in a program as
well as statements that transfer control to other units.

Module execution path: A sequence of statements that begins with a source node and ends with a sink
node with no intervening sink nodes.

Message: A programming language mechanism by which one unit transfers control to another unit.
• Usually interpreted as subroutine invocations
• The unit which receives the message always returns control to the message source.

System Testing
System Testing is a type of software testing that is performed on a completely integrated system to evaluate
the compliance of the system with the corresponding requirements. In system testing, integration testing
passed components are taken as input.
• The goal of integration testing is to detect any irregularity between the units that are integrated.
System testing detects defects within both the integrated units and the whole system. The result of
system testing is the observed behavior of a component or a system when it is tested.
• System Testing is carried out on the whole system in the context of either system requirement
specifications or functional requirement specifications or the context of both. System testing tests
the design and behavior of the system and also the expectations of the customer.

System Testing Process

System Testing is performed in the following steps:
• Test Environment Setup: Create testing environment for the better-quality testing.
• Create Test Case: Generate test case for the testing process.
• Create Test Data: Generate the data that is to be tested.
• Execute Test Case: After the generation of the test case and the test data, test cases are executed.
 • Defect Reporting: Defects in the system are detected.
• Regression Testing: It is carried out to test the side effects of the testing process.
• Log Defects: Defects are fixed in this step.
• Retest: If the test is not successful then again test is performed.

Threads
Thread is the smallest unit of work that any system can perform. Due to thread multiple tasks
execute simultaneously at a time. So, while developing software application we make use of threading
concept a lot. While testing, these needs to be tested properly as well.

Thread Testing is a Software based approach used during foremost integration testing phase. The
basic motto of this testing is to verify the key functionality which conveys specific task. Application of
thread testing is little critical as it takes place via integrated client, server and network. Threads are checked
separately and then tested incrementally as subsystem and then performed as whole system.

There are generally two types of thread testing i.e.

1. Single Thread Testing

• Simplicity: Single-Threaded software programs are easier for developers to build, maintain and
Test. Single-Threaded Testing does not require developers to implement sophisticated
synchronization mechanisms.
• Lesser overhead: The complex synchronization mechanisms in Multi-Threaded programs have a
significant amount of overhead, which is in contrast to the case for Single-Threaded program
Testing.
• Avoiding problems in concurrency: Single-Threaded programs are easy to diagnose and fix due
to the absence in complex concurrency problems like deadlocks or race conditions.
• Better use of resources: Single-Threaded programs are generally able to utilize CPU core
resources more effectively as they do not have overhead problems. This helps developers to
perform Testing on Single-Threaded programs much better and without complications.
 2. Multi Thread Testing

Multi-Thread Testing involves Testing various active transactions concurrently. This type of
Testing is conducted by the preparation of multiple Threads for an application service or for Testing a
client request’s responsiveness.

• Enhanced performance and user concurrency: One of the biggest benefits of multi-
threaded applications is an improvement in performance and concurrency. Multi-Threaded
programs generally keep the software performance unaffected.
• Reduced number of required users: Since a single server can execute many service Threads, the
required number of servers to start the application is reduced. Multi-Thread programs are generally
beneficial for conversational servers.
• Improved GUI responsiveness: Multi-Thread Testing can help improve the responsiveness of a
User Interface or UI. The user will experience enhanced smoothness and quicker response times
between the initiated action and its response in the program.

Basis Concepts for requirements Specification

1. Data: Raw facts and figures that can be processed to produce meaningful information. This
includes numbers, text, images, or any other form of recorded information.
2. Action: A specific operation or task that is performed, often in response to an event or trigger. In
computing, this could be a user interaction, system process, or automated response.
3. Devices: Hardware components or equipment that can connect to or interact with a system, such
as computers, smartphones, sensors, or IoT devices.
4. Events: Occurrences or happenings that can trigger actions or responses in a system. These could
be user interactions (like clicking a button), system states (like low memory), or external triggers.
5. Threads: Individual sequences of programmed instructions that can be executed independently
and simultaneously within a program. Threads allow for concurrent processing and are fundamental
to modern computing.
Finding the threads
1. Functional Testing Approaches:
• Test case execution paths to identify concurrent operations
• End-to-end workflows that involve multiple parallel processes
• Integration points where multiple threads interact
• User scenarios that trigger parallel processing
2. Performance Testing Methods:
• Load testing to monitor thread creation and management
• Stress testing to identify thread bottlenecks
• Thread pool behavior under different load conditions
• Thread synchronization issues under concurrent user load
3. Testing Tools:
• JMeter for measuring thread performance
• Thread analyzers like JProfiler or YourKit
• Memory leak detection tools that track thread lifecycle
• Test automation frameworks that support multi-threading
4. Code Review Focus Areas:
• Thread creation and termination points
• Resource sharing between threads
• Thread synchronization mechanisms
• Error handling in multi-threaded scenarios

Structural Strategies
1. Thread Architecture:
• Single-threaded vs multi-threaded design
• Thread pooling structures
• Parent-child thread hierarchies
• Thread groups for logical organization
2. Thread Management:
• Thread lifecycle control
• Priority-based organization
• Resource allocation patterns
• Thread state monitoring
3. Synchronization Structures:
• Mutex implementation
• Semaphore patterns
• Lock hierarchies
• Critical section design

Functional Strategies
1. Task Distribution:
• Work stealing algorithms
• Load balancing mechanisms
• Task partitioning approaches
• Queue-based distribution
 2. Communication Patterns:
• Message passing protocols
• Shared memory access
• Event notification systems
• Inter-thread signaling
3. Error Handling:
• Exception propagation
• Thread failure recovery
• Deadlock detection
• Resource cleanup
4. Performance Optimization:
• Thread pooling
• Caching strategies
• Context switching minimization
• Resource contention management

Atomic System Function Testing Example

We can illustrate ASF testing on our integrationNextDate pseudocode.
Identifying Input and Output Events
Recall that an ASF begins with a port input event, conducts some processing, and, depending on
the project-chosen granularity, ends with one or more port output events. We can identify ASFs from
source code by locating the nodes at which port inputs and outputs occur. Table lists the port input and
output events in integrationNextDate and the corresponding node numbers.
Identifying Atomic System Functions

The next step is to identify the ASFs in terms of the port input and output events. Table contains
the first attempt at ASF identification. There is a subtle problem with this first set of ASFs. They presume
that the states in the ASF graph in Figure are independent, but they are not. As we have seen, dependent
nodes often lead to impossible paths.
The ASF graph shows all the ways both valid months, days, and years can be entered, but the
transition to ASF-8 (or to ASF-9) depends on the history of previous ASFs. Since FSMs have no memory,
these transitions are necessarily undefined