GURU NANAK COLLEGE
(AUTONOMOUS)
A Sikh Minority Institution, Unit of Guru Nanak Education Society
Affiliated to University of Madras, Approved by AICTE | Accredited at
A++ Grade by NAAC
Guru Nanak Salai, Velachery, Chennai – 600 042
BACHELOR OF COMPUTER APPLICATIONS
Name and Designation of the Faculty: [Link] Bharathi S, Assistant Professor
Course Title: Software Engineering and Testing
Unit: IV Topic: Software Testing
Quality: In software engineering, quality is the degree to which a system, component, or
process meets specified requirements and user expectations. It encompasses reliability,
efficiency, maintainability, and usability.
Quality Assurance (QA) vs. Quality Control (QC)
These two terms are often used interchangeably, but they represent different phases of the
quality management process.
Feature Quality Assurance (QA) Quality Control (QC)
A set of activities designed
to ensure that the A set of activities designed
Definition development process is to evaluate the developed
adequate to ensure a system product to uncover defects.
will meet its objectives.
Process-oriented (Defect Product-oriented (Defect
Focus
Prevention). Detection).
Throughout the software
After the product (or a
When it happens development life cycle
phase) is built.
(SDLC).
1
Defining coding standards, Executing test cases, code
Example Activity
process checklists, audits. reviews, inspections.
TESTING:
Testing is the process of evaluating a system or its component(s) with the intent to find
whether it satisfies the specified requirements or not. In simple words, testing is executing a
system in order to identify any gaps, errors, or missing requirements in contrary to the actual
requirements.
Testing and Test Design are parts of quality assurance should also focus on bug prevention. A
prevented bug is better than a detected and corrected bug.
Tests are formal procedures, Inputs must be prepared, Outcomes should predicted, tests
should be documented, commands need to be executed,and results are to be observed. All
these errors are subjected to error
We do three distinct kinds of testing on a typical software system.
They are:
1. Unit / Component Testing: A Unit is the smallest testable piece of software that can be
compiled, assembled, linked, loaded etc. A unit is usually the work of one programmer and
consists of several hundred or fewer lines of code. Unit Testing is the testing we do to show
that the unit does not satisfy its functional specification or that its implementation structure
does not match the intended design structure. A Component is an integrated aggregate of one
or more [Link] Testing is the testing we do to show that the component does not
satisfy its functional specification or that its implementation structure does not match the
intended design structure.
2. Integration Testing: Integration is the process by which components are aggregated to
create larger components. Integration Testing is testing done to show that even though the
componenets were individually satisfactory (after passing component testing), checks the
combination of components are incorrect or inconsistent.
3. System Testing: A System is a big component. System Testing is aimed at revealing bugs
that cannot be attributed to components. It includes testing for performance, security,
accountability, configuration sensitivity, startup and recovery. Role of Models: The art of
2
testing consists of creating , selecting, exploring, and revising models. Our ability to go
through this process depends on the number of different models we have at hand and their
ability to express a program's behaviour.
Testing and Debugging
Testing − It involves identifying bug/error/defect in a software without correcting it.
Normally professionals with a quality assurance background are involved in bugs
identification. Testing is performed in the testing phase.
Debugging − It involves identifying, isolating, and fixing the problems/bugs. Developers
who code the software conduct debugging upon encountering an error in the code. Debugging
is a part of White Box Testing or Unit Testing. Debugging can be performed in the
development phase while conducting Unit Testing or in phases while fixing the reported
bugs.
Verification & Validation
These two terms are very confusing for most people, who use them interchangeably. The
following table highlights the differences between verification and validation.
S.N. Verification Validation
1 Verification addresses the concern: "Are Validation addresses the concern: "Are you
you building it right?" building the right thing?"
2 Ensures that the software system meets Ensures that the functionalities meet the
all the functionality. intended behavior.
3 Verification takes place first and includes Validation occurs after verification and
the checking for documentation, code, mainly involves the checking of the overall
etc. product.
4 Done by developers. Done by testers.
5 It has static activities, as it includes It has dynamic activities, as it includes
collecting reviews, walkthroughs, and executing the software against the
inspections to verify a software requirements.
6 It is an objective process and no It is a subjective process and involves
subjective decision should be needed to subjective decisions on how well a software
verify a software works.
3
SOFTWARE TESTING METHODS
Software testing methods are vital to ensure quality in the software development life cycle.
There are three main methods: black-box, white-box, and grey-box testing.
Black-box testing
Black-box testing, also known as behavioral or specification-based testing, focuses on a
system's functionality without considering its internal code structure. This approach mimics
the end-user experience, focusing on inputs and outputs to verify that the software behaves as
expected. Since the tester does not need to know the programming languages or understand
the code, anyone can do this type of testing.
Advantages
Well suited and efficient for large code segments
Clearly separates user's perspective from the developer's perspective through visibly
defined roles.
Limited coverage, since only a selected number of test scenarios is actually performed
Blind coverage, since the tester cannot target specific code segments or error-prone
areas.
Disadvantages
Code access is not required.
Large numbers of moderately skilled testers can test the application with no
knowledge of implementation, programming language, or operating systems.
Inefficient testing, due to the fact that the tester only has limited knowledge about an
application.
The test cases are difficult to design.
White-Box Testing
In contrast to black-box testing, white-box testing, also known as clear box, open box, or
glass box testing, involves examining the internal structures and workings of a software
4
application. This method is typically performed by developers with intimate knowledge of
the code, as it involves analyzing the logic and flow of the program. Testers often create
specific test cases to ensure that every line of code is executed and tested.
Advantages
As the tester has knowledge of the source code, it becomes very easy to find out
which type of data can help in testing the application effectively.
It helps in optimizing the code.
Extra lines of code can be removed which can bring in hidden defects.
Due to the tester's knowledge about the code, maximum coverage is attained during
test
scenario writing.
Disadvantages
Due to the fact that a skilled tester is needed to perform white-box testing, the costs
are
increased.
Sometimes it is impossible to look into every nook and corner to find out hidden
errors that may create problems, as many paths will go untested.
It is difficult to maintain white-box testing, as it requires specialized tools like code
analyzers and debugging tools.
Grey-box testing
Grey-box testing is a hybrid approach that combines elements of both black-box and white-
box testing. With this method, the tester has partial knowledge of the internal workings of the
system. This allows them to design more intelligent and targeted test cases while still
approaching the system from an end-user perspective. This method can be an efficient way to
find context-specific errors.
Advantages
Offers combined benefits of black-box and white-box testing wherever possible.
Grey box testers don't rely on the source code;instead they rely on interface definition
and functional specifications.
Based on the limited information available, a grey-box tester can design excellent test
scenarios especially around communication protocols and data type handling.
The test is done from the point of view of the user and not the designer
5
Disadvantages
Since the access to source code is not available, the ability to go over the code and test
coverage is limited.
The tests can be redundant if the software designer has already run a test case.
Testing every possible input stream is unrealistic because it would take an
unreasonable amount of time; therefore, many program paths will go untested.
A Comparisons of Test Methods
Black-Box Testing Grey-Box Testing White-Box Testing
The internal workings of an The tester has limited Tester has full knowledge of
application need not be knowledge of the internal the internal workings of the
known. workings of the application. application.
Also known as closed-box Also known as translucent Also known as clear-box
testing, data-driven testing, or testing, as the tester has testing, structural testing, or
functional testing. limited knowledge of the code-based testing.
insides of the application.
Performed by end-users and Performed by end-users and Normally done by testers and
also by testers and also by testers and developers.
developers. developers.
Testing is based on external Testing is done on the basis of Internal workings are fully
expectations - Internal high-level database diagrams known and the tester can
behavior of the application is and data flow diagrams. design test data accordingly.
unknown.
It is exhaustive and the least Partly time-consuming and The most exhaustive and
time-consuming. exhaustive. time-consuming type of
testing.
Not suited for algorithm Not suited for algorithm Suited for algorithm testing.
testing. testing.
This can only be done by Data domains and internal Data domains and internal
trial-and-error method. boundaries can be tested, if boundaries can be better
known. tested.
6
LEVELS OF TESTING
Unit Testing
Unit Testing is a level of software testing where individual units/ components of a
software are tested. The purpose is to validate that each unit of the software performs
as designed.
Unit Testing is the first level of testing and is performed prior to Integration Testing.
A unit is the smallest testable part of software. It usually has one or a few inputs and
usually a single output.
It is executed by the Developer.
Unit Testing is performed by using the White Box Testing method
Example: - A function, method, Loop or statement in program is working fine.
Drivers
Drivers are used in bottom-up integration testing approach. It can simulate the behavior of
upper-level module that is not integrated yet. Drivers modules act as the temporary
replacement of module and act as the actual products. Drivers are also used for interact with
external system and usually complex than stubs. Driver: Calls the Module to be tested.
7
Now suppose you have modules B and C ready but module A which calls functions from
module B and C is not ready so developer will write a dummy piece of code for module A
which will return values to module B and C. This dummy piece of code is known as driver.
Stubs
Stubs are used in top down integration testing. It can simulate the behavior of lower-level
module that are not integrated. They are act as a temporary replacement of module and
provide same output as actual product. When needs to intact with external system then also
stubs are used. Stub: Is called by the Module under Test.
Assume you have 3 modules, Module A, Module B and module C. Module A is ready and we
need to test it, but module A calls functions from Module B and C which are not ready, so
developer will write a dummy module which simulates B and C and returns values to module
A. This dummy module code is known as stub.
Integration Testing
Definition: Integration testing is the phase in software testing where individual software
modules (which have already been unit-tested) are combined and tested as a group.
Primary Goal: The main objective is not to test the internal logic of individual modules, but
to expose faults in the interaction and communication between these integrated units.
Analogy: If unit testing is checking if each individual gear of a watch works perfectly on its
own, integration testing is putting all the gears together to ensure they turn each other
correctly without jamming.
Why is Integration Testing Necessary?
Even if every module passes unit testing perfectly, integration testing remains critical
because:
Interface Errors: Data might be lost, truncated, or misinterpreted across the interface
between two modules.
Developer Discrepancies: Modules are often built by different developers who might have
slightly varying interpretations of the design logic or data formatting structures.
Database Constraints: Interacting modules might inadvertently violate database constraints
when executed together.
8
Shared Resources: Issues can arise with global data structures or shared memory that are
modified by multiple modules simultaneously.
Approaches to Integration Testing
[Link] Bang Approach
2. Incremental Approach
Big Bang Approach
Mechanism: All components or modules are integrated simultaneously, and the entire system
is tested at once.
Pros: Convenient for very small, simple systems.
Cons: Fault localization is extremely difficult. If a bug is found, figuring out exactly which
interface caused the failure is highly complex.
Incremental Approach
Modules are integrated logically, one by one or in small batches, until the entire system is
tested. This makes defect isolation much easier.
Incremental approaches are two types, they are
1. Top-Down Testing
2. Bottom up Testing
3. Bi-Direction Testing
Top-Down Integration Testing
In this approach, testing begins with the highest-level module (often the main user interface
or the main control logic) and progressively moves downward through the system's hierarchy
to the lowest-level modules.
The Mechanism: The main control module is tested first. Subordinate modules are integrated
step-by-step.
The Missing Pieces (Stubs): Because you are starting at the top, the lower-level utility
modules (like database connectors or calculation engines) might not be built yet. You must
use Stubs—dummy programs that simulate these lower-level functions by returning
hardcoded data so the top-level module can be tested without crashing.
9
Advantages:
Major Flaws Caught Early: If there is a fundamental flaw in the system's overall
architecture or design, it is exposed immediately.
Early Prototype: It provides a working (though limited) version of the application very early
in the cycle, which is great for demonstrating progress to stakeholders.
UI Focus: User interface issues are caught right away.
Disadvantages:
Stub Overhead: Writing and maintaining many Stubs can be time-consuming.
Core Logic Delayed: Crucial, low-level logic and computations are tested last. If a
fundamental mathematical or database error exists at the bottom, it might force a massive
redesign of the top layers once discovered.
Bottom-Up Integration Testing
In this approach, testing begins at the very bottom of the hierarchy with the most
fundamental, atomic modules. Once those are verified, they are clustered together and
integrated upward until the main control module is finally tested.
The Mechanism: Lowest-level modules are tested individually, then grouped into "builds" or
"clusters" to test their combined functionality.
The Missing Pieces (Drivers): Because you are starting at the bottom, the higher-level
modules that normally tell these bottom modules what to do aren't ready. You must use
Drivers—dummy programs that act as a temporary "boss," sending test data into the lower-
level modules and reading the output.
Advantages:
Solid Foundation: Core logic, calculations, and utility functions are thoroughly tested and
stabilized before anything else is built on top of them.
No Stubs Required: You don't need to fake lower-level data because the lower levels
actually exist.
Great for Object-Oriented Design: Works exceptionally well for systems where self-
contained objects or microservices need to be verified independently.
10
Disadvantages:
Late Prototype: The system doesn't look or act like a complete application until the very
end, meaning stakeholders have to wait a long time to see a working UI.
Major Flaws Caught Late: If the overarching design or control flow is flawed, you won't
find out until the top modules are finally attached at the end of the project.
Integration Testing Process
Test Plan Creation: Define the strategy, scope, and specific approach (e.g., Top-Down vs.
Bottom-Up).
Test Case Design: Develop scenarios focusing strictly on the data flow, API calls, and
interfaces between the specific modules.
Execution: Run the tests, utilizing the appropriate Stubs or Drivers to fill in missing gaps.
Defect Logging & Fixing: Record any interface failures, crashes, or data loss, and route
them back to the development team.
Retesting: Re-run the integration tests after fixes are deployed to ensure the connection is
now stable.
Bi-Directional Testing /Sandwich Integration Testing
11
Bi-directional Integration is a kind of integration testing process that combines top-
down and bottom-up testing.
With an experience in delivering Bi-directional testing projects custom software
development services provide the best quality of the deliverables right from the
development of software process.
Bi-directional Integration testing is a vertical incremental testing strategy that tests the
bottom layers and top layers and tests the integrated system in the computer software
development process.
Using stubs, it tests the user interface in isolation as well as tests the very lowest level
functions using drivers.
Bi-directional Integration testing combines bottom-up and top-down testing.
Bottom-up testing is a process where lower level modules are integrated and then
tested.
This process is repeated until the component of the top of the hierarchy is analyzed. It
helps custom software development services find bugs easily without any problems.
Top down testing is a process where the top integrated modules are tested and the
procedure is continued till the end of the related module.
Top down testing helps developers find the missing branch link easily
This technique is called as Sandwich Integration.
Advantages:
1. Sandwich approach is useful for very large projects having several subprojects.
2. Both Top-down and Bottom-up approach starts at a time as per development schedule.
3. Units are tested and brought together to make a system Integration is done downwards.
Disadvantages:
1. It require very high cost for testing because one part has Top-down approach while another
12
part has bottom-up approach.
2. It cannot be used for smaller system with huge interdependence between different
modules. It makes sense when the individual subsystem is as good as complete system.
System Integration Testing (SIT)
SIT is an important testing phase in the software development lifecycle that ensures that the
different components of a system are integrated and work together correctly. SIT helps to
identify and resolve any issues or defects before the system is deployed for user acceptance
testing or production, thereby reducing the risk of costly and time-consuming rework.
Objective of System Integration Testing:
The objective of SIT is to:
To meet software with user requirements.
To maximize the memory usage.
To control data flow in within the system.
To test the control flow of the system.
To find the errors and bugs in the system.
To minimize time consumption for testing process.
13
Major States of SIT:
There are three major states of system integration testing:
1. Data state within the integration layer: Integration layer is the medium used for data
transformation. Different web services are involved in this layer which is used as medium
for data sending and receiving. There are several check-points where the validation of
data is checked and there are several protocols used in it. Middleware is also used as
medium for transformation which allows the data mapping against the cross-checking.
2. Data state within the database layer: Database layer consists of several steps involved
in it. It checks whether the data is transformed from integration layer to database layer.
Data properties are checked and data validation process is performed. Mainly SQL is used
for data storing and data manipulation process.
3. Data state within the application layer: Application layer is used to create a data map
for databases and check its interaction with user interface. Data properties are also
checked in it.
System Integration Testing Techniques
Top-down Integration Testing
Bottom-up Integration Testing
Sandwich Integration Tsting
Big-bang Integration Testing
Top-down Integration Testing
14
• Module A has been decomposed into modules B, C, and D
• Modules B, D, E, F, and G are terminal modules
• First integrate modules A and B using stubs C` and D` (represented by grey boxes)
• Next stub D` has been replaced with its actual instance D
• Two kinds of tests are performed:
– Test the interface between A and D
– Regression tests to look for interface defects between A and B in the presence
of module D
• Stub C` has been replaced with the actual module C, and new stubs E`, F`, and G`
• Perform tests as follows:
– first, test the interface between A and C;
– second, test the combined modules A, B, and D in the presence of C
• The rest of the process depicted in the right hand side figures.
15
Figure : Top-down integration of modules A, B, D and C
Bottom-up
• We design a test driver to integrate lowest-level modules E, F, and G
• Return values generated by one module is likely to be used in another module
• The test driver mimics module C to integrate E, F, and G in a limited way.
• The test driver is replaced with actual module , i.e., C.
• A new test driver is used
• At this moment, more modules such as B and D are integrated
• The new test driver mimics the behavior of module A
• Finally, the test driver is replaced with module A and further test are performed
Bottom-up integration of module E, F, and G : Bottom-up integration of module B, C, and D with F, F,
and G
Big-bang and Sandwich
16
Big-bang Approach
• First all the modules are individually tested
• Next all those modules are put together to construct the entire system which is tested
as a whole
Sandwich Approach
• In this approach a system is integrated using a mix of top-down, bottom-up, and big-
bang approaches
• A hierarchical system is viewed as consisting of three layers
• The bottom-up approach is applied to integrate the modules in the bottom-layer
• The top layer modules are integrated by using top-down approach
• The middle layer is integrated by using the big-bang approach after the top and the
bottom layers have been integrated
References:
1. Roger [Link],Software Engineering A Practitioner’s Approach-6 th Edition,
McGraw-Hill,2005 .
2. [Link], 1997, Software Engineering – 1997 - Fourth Ed., McGraw Hill.
3. Software Testing: A Craftsman's Approach, by Paul C. Jorgensen, Third Edition. Eric
Matthes, “Python Crash Course”, 3rd Edition: A Hands-On, Project-Based
Introductionto Programming.
4. “Ron Patton”, Software Testing-Second Edition, 2014.
5. [Link]
6. [Link]
17
18