PRESIDENCY UNIVERISTY, BENGALURU

School of Information Science

Bachelor of Computer Applications

Software Testing
(BCA 321)
VI Semester 2022-23
Module 1: FUNDAMENTALS OF
SOFTWARE TESTING

• Phases of Software Project

• Quality assurance and Quality Control
• Software Development Life Cycle (SDLC) Models
• Software Testing and Its Types
• Software Testing Life Cycle (STLC)
Phases of Software Project

A software is developed by a series of

phases as follows:
1)Requirements gathering and analysis
2)Planning
3)Design
4)Development/Coding/Implementation
5)Testing
6)Deployment and Maintenance
 Requirements gathering and
analysis
• In this phase, the specific requirements of the software to be
built are gathered and documented.
• The requirements get documented in the form of a System
Requirements Specification (SRS) documented.
• SRS document acts as a bridge between the customer and
software designers
 Plannin
• The purpose of
g
Planning phase is to come up with a
schedule, scope and resource requirements for a
release.

• A plan explains requirements will be met and by what

time.

• It needs to take into consideration the requirementns-

what will be met and what will not be met
 Desig
•
n
Design Phase’s purpose is to figure out how to satisfy
requirements enumerated in the SRS document.

• It produces a representation (BluePrint) that will be

used by the following phase, the development phase.
This representation serves two purposes:

a) possible to verify all requirements are satisfies

b) Gives info to development phases to proceed with

coding.

• Design is split in High-Level Design (HDD) and Low-Level

Design (SDD)

• This phase produces System Design Description (SDD)

that will be used by development teams to produce the
programs that realize the design
Desig
n
 Development or
• DesignCoding
act as a blueprint for actual coding to
proceed.

• This phase comprises coding the programs in

choosen programming Language.

• In addition, this phase also involves the creation of

product documentation
 Testin
galso debugged and executed.
As the programs are coded, they are
After the coding is completed, the product is subjected to testing.

Testing is the process of exercising the software product in pre-

defined ways to check if the behavior is the same as expected
behavior.

Software testing is a process, to evaluate the functionality of a

software application with an intent to find whether the developed
software met the specified requirements or not and to identify the
defects to ensure that the product is defect free in order to produce
the quality product.

Software testing is a set of processes aimed at investigating,

evaluating and ascertaining the completeness and quality of
computer software. Software testing ensures the compliance of a
software product in relation with regulatory, business, technical,
functional and user requirements.
 Deployment and
Maintenance
Once the software is tested, it is given to clients who
deploy it in their environments.

As users starts using the product in their environment they

may observe discrepancies between the actual behavior
and what they were given to expect. Such defects need to
be corrected.

The product now enters the maintenance phase, where the

product is maintained or changed to satisfy customers
expectations that arises from environmental changes.

Maintenance can be one among the following:

Corrective (Fixing customer related problems)
Adaptive (Making the S/w run on new version of OS or DB)
Preventive(Changing to code to avoid security threat)
Costs Involved in Various Phases of Software project
Quality, Quality assurance and Quality
Control
Quality:
Quality is meeting the requirement, expectation, and needs of the customer
is free from the defects, lacks and substantial variants. There are standards
needs to follow to satisfy the customer requirements.

Quality Assurance is known as QA and focuses on preventing defect.

Quality Assurance ensures that the approaches, techniques, methods and
processes are designed for the projects are implemented correctly.

Quality assurance activities monitor and verify that the processes used to
manage and create the deliverables have been followed and are operative.

Quality Assurance is a proactive process and is Prevention in nature. It

recognizes flaws in the process. Quality Assurance has to complete before
Quality Control.
 Quality, Quality assurance and Quality
Control
Quality Control is known as QC and focuses on identifying a
defect. QC ensures that the approaches, techniques, methods and
processes are designed in the project are following correctly. QC
activities monitor and verify that the project deliverables meet the
defined quality standards.

Quality Control is a reactive process and is detection in nature. It

recognizes the defects. Quality Control has to complete after
Quality assurance
Quality, Quality assurance and Quality
Control
 Testing, Verification and
Validation.
Verification focuses on: Are we building the product right?
Validation focuses on: Are we building the right product?
Testing, Verification and
Validation.
Testing, Verification and
Validation.
(Software Development Life Cycle (SDLC)
Models
A framework that describes the activities performed at
each stage of a software development project.

A software lifecycle model is a standardized format for

planning organizing, and running a new development
project

A (software/system) lifecycle model is a description of

the sequence of activities carried out in an SE project,
and the relative order of these activities.
Normally, a lifecycle model covers the entire lifetime of a
product.
Waterfall Model

• Requirements –
defines needed
information, function,
behavior, performance
and interfaces.
• Design – data
structures, software
architecture, interface
representations,
algorithmic details.
• Implementation –
source code, database,
user documentation,
testing.
Waterfall Strengths

• Easy to understand, easy to use

• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Good for management control (plan, staff,
track)
• Works well when quality is more important
than cost or schedule
 Waterfall Deficiencies

• All requirements must be known upfront

• Deliverables created for each phase are
considered frozen – inhibits flexibility
• Can give a false impression of progress
• Does not reflect problem-solving nature of
software development – iterations of phases
• Integration is one big bang at the end
• Little opportunity for customer to preview the
system (until it may be too late)
 When to use the
•Waterfall Model
Requirements are very well known
• Product definition is stable
• Technology is understood
• New version of an existing product
• Porting an existing product to a new
platform.
Structured Evolutionary Prototyping Model
• Developers build a prototype during the
requirements phase
• Prototype is evaluated by end users
• Users give corrective feedback
• Developers further refine the prototype
• When the user is satisfied, the prototype code is
brought up to the standards needed for a final
product.
 Structured Evolutionary Prototyping Steps
• A preliminary project plan is developed
• An partial high-level paper model is created
• The model is source for a partial requirements specification
• A prototype is built with basic and critical attributes
• The designer builds
o the database
o user interface
o algorithmic functions
• The designer demonstrates the prototype, the user evaluates
for problems and suggests improvements.
• This loop continues until the user is satisfied
Structured Evolutionary Prototyping Strengths
• Customers can “see” the system requirements as
they are being gathered
• Developers learn from customers
• A more accurate end product
• Unexpected requirements accommodated
• Allows for flexible design and development
• Steady, visible signs of progress produced
• Interaction with the prototype stimulates
awareness of additional needed functionality
Structured Evolutionary Prototyping
Weaknesses
• Tendency to abandon structured program development for “code-
and-fix” development
• Bad reputation for “quick-and-dirty” methods
• Overall maintainability may be overlooked
• The customer may want the prototype delivered.
• Process may continue forever (scope creep)
When to use Structured Evolutionary Prototyping

• Requirements are unstable or have to be clarified

• As the requirements clarification stage of a
waterfall model
• Develop user interfaces
• Short-lived demonstrations
• New, original development
• With the analysis and design portions of object-
oriented development.
Spiral or Iterative SDLC Model

• Adds risk
analysis, and
4gl RAD
prototyping to
the waterfall
model
• Each cycle
involves the
same
sequence of
steps as the
waterfall
process
model
 Spiral Quadrant Determine objectives, alternatives and constraints

• Objectives: functionality, performance,

hardware/software interface, critical success factors,
etc.
• Alternatives: build, reuse, buy, sub-contract, etc.
• Constraints: cost, schedule, interface, etc.
Spiral Quadrant Evaluate alternatives, identify and resolve risks

• Study alternatives relative to objectives and constraints

• Identify risks (lack of experience, new technology, tight
schedules, poor process, etc.
• Resolve risks (evaluate if money could be lost by continuing
system development
Spiral Quadrant Develop next-level product
• Typical activites:
o Create a design
o Review design
o Develop code
o Inspect code
o Test product
Spiral Quadrant Plan next phase

• Typical activities
o Develop project plan
o Develop configuration management plan
o Develop a test plan
o Develop an installation plan
Spiral Model Strengths

• Provides early indication of insurmountable risks,

without much cost
• Users see the system early because of rapid
prototyping tools
• Critical high-risk functions are developed first
• The design does not have to be perfect
• Users can be closely tied to all lifecycle steps
• Early and frequent feedback from users
• Cumulative costs assessed frequently
 Spiral Model Weaknesses

• Time spent for evaluating risks too large for small or low-
risk projects
• Time spent planning, resetting objectives, doing risk
analysis and prototyping may be excessive
• The model is complex
• Risk assessment expertise is required
• Spiral may continue indefinitely
• Developers must be reassigned during non-development
phase activities
• May be hard to define objective, verifiable milestones that
indicate readiness to proceed through the next iteration
When to use Spiral Model

• When creation of a prototype is appropriate

• When costs and risk evaluation is important
• For medium to high-risk projects
• Long-term project commitment unwise because of
potential changes to economic priorities
• Users are unsure of their needs
• Requirements are complex
• New product line
• Significant changes are expected (research and
exploration)
 Rapid Application Model
(RAD)
• Requirements planning phase (a workshop utilizing structured discussion of business
problems)
• User description phase – automated tools capture information from users
• Construction phase – productivity tools, such as code generators, screen generators,
etc. inside a time-box. (“Do until done”)
• Cutover phase -- installation of the system, user acceptance testing and user training
RAD Strengths

• Reduced cycle time and improved productivity with

fewer people means lower costs
• Time-box approach mitigates cost and schedule
risk
• Customer involved throughout the complete cycle
minimizes risk of not achieving customer
satisfaction and business needs
• Focus moves from documentation to code
(WYSIWYG).
• Uses modeling concepts to capture information
about business, data, and processes.
RAD Weaknesses

• Accelerated development process must give quick

responses to the user
• Risk of never achieving closure
• Hard to use with legacy systems
• Requires a system that can be modularized
• Developers and customers must be committed to
rapid-fire activities in an abbreviated time frame.
When to use RAD

• Reasonably well-known requirements

• User involved throughout the life cycle
• Project can be time-boxed
• Functionality delivered in increments
• High performance not required
• Low technical risks
• System can be modularized
V-Shaped SDLC Model

• A variant of the Waterfall

that emphasizes the
verification and
validation of the product.
• Testing of the product is
planned in parallel with a
corresponding phase of
development
 V-
Sha
• ped
Project and Requirements • Production, operation and
Ste – allocate resources
Planning maintenance – provide for
ps enhancement and corrections
• System and acceptance testing –
• Product Requirements and check the entire software system
Specification Analysis – complete in its environment
specification of the software
system • Integration and Testing – check
that modules interconnect
correctly
• Architecture or High-Level Design • Unit testing – check that each
– defines how software functions module acts as expected
fulfill the design

• Coding – transform algorithms

• Detailed Design – develop into software
algorithms for each architectural
component
V-Shaped Strengths

• Emphasize planning for verification and validation

of the product in early stages of product
development
• Each deliverable must be testable
• Project management can track progress by
milestones
• Easy to use
V-Shaped Weaknesses

• Does not easily handle concurrent events

• Does not handle iterations or phases
• Does not easily handle dynamic changes in
requirements
• Does not contain risk analysis activities
 When to use the
•V-Shaped Model
Excellent choice for systems requiring high
reliability – hospital patient control applications
• All requirements are known up-front
• When it can be modified to handle changing
requirements beyond analysis phase
• Solution and technology are known
Comparison of Life cycle
models
 SDLC - Agile Model

• Agile SDLC model is a combination of iterative and incremental process

models with focus on process adaptability and customer satisfaction by rapid
delivery of working software product.
• Agile Methods break the product into small incremental builds.
• These builds are provided in iterations. Each iteration typically lasts from about
one to three weeks.
• Every iteration involves cross functional teams working simultaneously on
various areas like −
o Planning
o Requirements Analysis
o Design
o Coding
o Unit Testing and
o Acceptance Testing.
• At the end of the iteration, a working product is displayed to the customer and
important stakeholders.
 What is Agile?

• Agile model believes that every project needs to be handled differently and the
existing methods need to be tailored to best suit the project requirements.
• In Agile, the tasks are divided to time boxes (small time frames) to deliver
specific features for a release.
• Iterative approach is taken and working software build is delivered after each
iteration.
• Each build is incremental in terms of features; the final build holds all the
features required by the customer.
Graphical illustration of Agile Model
• The Agile thought process had started early in the software development and started
becoming popular with time due to its flexibility and adaptability.
• The most popular Agile methods include Rational Unified Process (1994), Scrum (1995),
Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven
Development, and Dynamic Systems Development Method (DSDM) (1995).
• These are now collectively referred to as Agile Methodologies, after the Agile Manifesto was
published in 2001.
• Following are the Agile Manifesto principles −
o Individuals and interactions − In Agile development, self-organization and motivation
are important, as are interactions like co-location and pair programming.
o Working software − Demo working software is considered the best means of
communication with the customers to understand their requirements, instead of just
depending on documentation.
o Customer collaboration − As the requirements cannot be gathered completely in the
beginning of the project due to various factors, continuous customer interaction is very
important to get proper product requirements.
o Responding to change − Agile Development is focused on quick responses to change
and continuous development.
 Agile Vs Traditional SDLC Models

• Agile is based on the adaptive software development methods, whereas the traditional SDLC
models like the waterfall model is based on a predictive approach.
• Predictive teams in the traditional SDLC models usually work with detailed planning and have a
complete forecast of the exact tasks and features to be delivered in the next few months or during
the product life cycle.
• Predictive methods entirely depend on the requirement analysis and planning done in the
beginning of cycle.
• Any changes to be incorporated go through a strict change control management and prioritization.
• Agile uses an adaptive approach where there is no detailed planning and there is clarity on
future tasks only in respect of what features need to be developed.
• There is feature driven development and the team adapts to the changing product requirements
dynamically.
• The product is tested very frequently, through the release iterations, minimizing the risk of any
major failures in future.
• Customer Interaction is the backbone of this Agile methodology, and open communication with
minimum documentation are the typical features of Agile development environment.
• The agile teams work in close collaboration with each other and are most often located in the
same geographical location.
 AGILE – Pros and Cons
• Pros
o Project is divided into short and transparent iterations.
o It has a flexible change process.
o Quick release of the first product version.
o The correctness of functional requirement is implemented into the
development process.
o Customer can see the result and understand whether he/she is satisfied
with it or not
• Cons
o The development team should be highly professional and client-oriented.
o New requirement may be a conflict with the existing architecture.
o With further correction and change, there may be chances that the
project will cross the expected time.
o There may be difficult to estimate the final coast of the project due to
constant iteration.
o A defined requirement is absent
 Software Testing and Its Types

White Box Testing:

It is based on the knowledge about the internal logic of an application’s
code.
• It is also known as Glass box Testing. Internal software and code
working should be known for performing this type of testing.
• Under these tests are based on the coverage of code statements,
branches, paths, conditions, etc.
Black Box Testing
• Internal system design is not considered in this type of testing. Tests
are based on the requirements and functionality.
• Black-box testing is a method of software testing that examines the
functionality of an application without peering into its internal
structures or workings. This method of test can be applied virtually to
every level of software testing: unit, integration, system and
acceptance
Different Types Of Software Testing
Functional Testing types include:
• Unit Testing
• Integration Testing
• System Testing
• Sanity Testing
• Smoke Testing
• Interface Testing
• Regression Testing
• Beta/Acceptance Testing
Non-Functional Testing types include:
• Performance Testing
• Load Testing
• Stress Testing
• Volume Testing
• Security Testing
• Reliability Testing
• Compatibility Testing
• Usability Testing,
• Localization Testing
Unit Testing
• Testing of an individual software component or module is
termed as Unit Testing. It is typically done by the
programmer and not by testers, as it requires detailed
knowledge of the internal program design and code. It may
also require developing test driver modules or test
harnesses.
Integration Testing
• Testing of all integrated modules to verify the combined
functionality after integration is termed as Integration Testing
.
• Modules are typically code modules, individual applications,
client and server applications on a network, etc. This type of
testing is especially relevant to client/server and distributed
systems.
System Testing
• Under System Testing technique, the entire system is
tested as per the requirements. It is a Black-box type
Testing that is based on overall requirement
specifications and covers all the combined parts of a
system.

Sanity Testing
• Sanity Testing is done to determine if a new software
version is performing well enough to accept it for a
major testing effort or not. If an application is crashing
for the initial use then the system is not stable enough
for further testing. Hence a build or an application is
assigned to fix it.
Smoke Testing
• Whenever a new build is provided by the development
team then the Software Testing team validates the build
and ensures that no major issue exists.
• The testing team ensures that the build is stable and a
detailed level of testing is carried out further.
• Smoke Testing checks that no show stopper defect exists in
the build which will prevent the testing team to test the
application in detail.
• If testers find that the major critical functionality is broken
down at the initial stage itself then testing team can reject
the build and inform accordingly to the development team.
Smoke Testing is carried out to a detailed level of any
Functional or Regression Testing.
Graphical User Interface (GUI) Testing
• The objective of this GUI Testing is to validate the GUI
as per the business requirement. The expected GUI of
the application is mentioned in the Detailed Design
Document and GUI mockup screens.
• The GUI Testing includes the size of the buttons and
input field present on the screen, alignment of all text,
tables, and content in the tables.
• It also validates the menu of the application, after
selecting different menu and menu items.
• It validates that the page does not fluctuate and the
alignment remains same after hovering the mouse on
the menu or sub-menu.
Regression Testing is defined as a type of software testing to confirm
that a recent program or code change has not adversely affected
existing features.
Regression Testing is nothing but a full or partial selection of already
executed test cases which are re-executed to ensure existing
functionalities work fine.
Benefits of Regression Testing
• Increase chances of detecting bugs caused due to new changes
introduced in the software
• Helps in identifying undesirable side effects that might have been
caused due to a new operating environment
• Ensures better performing software due to
early identification of bugs and errors
• Highly beneficial in situations when continuous changes are
introduced in the product
• Helps in maintaining high product quality
Acceptance Testing / BETA Testing
• An Acceptance Test is performed by the client and verifies whether
the end to end the flow of the system is as per the business
requirements or not and if it is as per the needs of the end-user.
Client accepts the software only when all the features and
functionalities work as expected.
• It is the last phase of the testing, after which the software goes into
production. This is also called User Acceptance Testing (UAT).
Alpha Testing
• It is the most common type of testing used in the Software industry.
The objective of this testing is to identify all possible issues or defects
before releasing it into the market or to the user.
• Alpha Testing is carried out at the end of the software development
phase but before the Beta Testing. Still, minor design changes may
be made as a result of such testing.
• Alpha Testing is conducted at the developer’s site. In-house virtual
user environment can be created for this type of testing.
 Performance Testing

Testing the response time and stability of an application by

applying load is called Performance Testing.
Performance Testing should be carried out when
1) Product is stable
2) After completion of Functionality testing
3) After completion of system testing
Types of Performance Testing:
4) Load Testing
5) Stress Testing
6) Stability Testing
7) Volume Testing
8) Scalability Testing
Load Testing:
Testing the behavior of the Application by applying
load less than or equal to desired load
Desired Load  1000 users  Goal is: Response
time= 5 sec
Stress Testing:
Testing the behavior of the Application by applying
load greater than or equal to desired load
Stability Testing (Time):
Testing Application’s stableness for a particular
period of time by applying load.
Volume Testing (Data):
Testing the behavior of the Application by applying huge
volumes of data is called V.T
Scalability Testing:
Testing the behavior of the Application by
increasing/decreasing the scales in a particular intervals
is called S.T
Scenario 1: Downward Scalability
Goal = Response time 5 sec for 80 users
100 users  8 sec, 70 users 7 sec, 80 users 5 sec
Scenario 1: Upward Scalability
100 users  3 sec, 110 users 3 sec, 120 users 5 sec
150 users  System thrash
 Scalability Testing

• The objective is to find out the maximum capability of the

product parameters.
• Scalability Testing is a non-functional test methodology in
which an application’s performance is measured in terms of
its ability to scale up or scale down the number of user
requests or other such performance measure attributes.
• Scalability testing can be performed at a hardware,
software or database level.
•If this testing is done properly, major errors with respect to
performance in the software, hardware, and database can be
uncovered in the developed applications.
Reliability Testing

• Reliability testing is defined as a software testing type,

that checks whether the software can perform a failure-
free operation for a specified period of time in a specified
environment.
• Reliability testing in software assures that the product is
fault free and is reliable for its intended purpose.
• Reliability is achieved by focusing on the following
activities.
• Defined engineering process
• Review of work products at each stage
• Change management procedures.
Compatibility Testing
• It is a testing type in which it validates how software
behaves and runs in a different environment, web
servers, hardware, and network environment.
• Compatibility testing ensures that software can run on a
different configuration, different database, different
browsers, and their versions. Compatibility testing is
performed by the testing team.
Usability Testing
• Under Usability Testing, User-friendliness check is done.
The application flow is tested to know if a new user can
understand the application easily or not, Proper help
documented if a user gets stuck at any point. Basically,
system navigation is checked in this testing.
• What is Localization Testing?
• Localization testing is the software testing process for
checking the localized version of a product for that
particular culture or locale settings. The areas affected
by localization testing are UI and content.
• What is Globalization Testing?
• Globalization testing is to ensure that application can
function in any culture or locale (language, territory and
code page) It is also called as Internationalization
Testing.
Software Testing Life Cycle (STLC)

• What is Software Testing Life Cycle (STLC)?

Software Testing Life Cycle (STLC) is a sequence of
specific activities conducted during the testing process to
ensure software quality goals are met.
STLC involves both verification and validation activities.
Contrary to popular belief, Software Testing is not just a
single/isolate activity, i.e. testing. It consists of a series of
activities carried out methodologically to help certify your
software product.
STLC Phases
• There are following six major phases in every Software
Testing Life Cycle Model (STLC Model):
• Requirement Analysis
• Test Planning
• Test case development
• Test Environment setup
• Test Execution
• Test Cycle closure
STLC Model Phases
What is Entry and Exit Criteria in STLC?
• Entry Criteria: Entry Criteria gives the prerequisite
items that must be completed before testing can begin.
• Exit Criteria: Exit Criteria defines the items that must
be completed before testing can be concluded
You have Entry and Exit Criteria for all levels in the
Software Testing Life Cycle (STLC)
Requirement Phase Testing

It studies the requirements from a testing point of view to

identify testable requirements and the QA team may interact
with various stakeholders to understand requirements in
detail. Requirements could be either functional or non-
functional.
Activities in Requirement Phase Testing
• Identify types of tests to be performed. Gather details
about testing priorities and focus.
• Prepare Requirement Traceability Matrix (RTM).
• Identify test environment details where testing is supposed
to be carried out.
• Automation feasibility analysis (if required).
 Test Planning in STLC

Test Planning in STLC is a phase in which a Senior QA

manager determines the test plan strategy along with efforts
and cost estimates for the project.
Moreover, the resources, test environment, test limitations and
the testing schedule are also determined. The Test Plan gets
prepared and finalized in the same phase.
Test Planning Activities
• Preparation of test plan/strategy document for various types of
testing
• Test tool selection
• Test effort estimation
• Resource planning and determining roles and responsibilities.
• Training requirement
Test Case Development Phase

The Test Case Development Phase involves the

creation, verification and rework of test cases & test
scripts after the test plan is ready. Initially, the Test data
is identified then created and reviewed and then
reworked based on the preconditions.
Then the QA team starts the development process of test
cases for individual units.
Test Case Development Activities
• Create test cases, automation scripts (if applicable)
• Review and baseline test cases and scripts
• Create test data (If Test Environment is available)
Test Environment Setup

It decides the software and hardware conditions under

which a work product is tested. It is one of the critical
aspects of the testing process and can be done in
parallel with the Test Case Development Phase.
Test team may not be involved in this activity if the
development team provides the test environment.
Test Environment Setup Activities
• Understand the required architecture, environment set-
up and prepare hardware and software requirement list
for the Test Environment.
• Setup test Environment and test data
• Perform smoke test on the build
Test Execution Phase

It is carried out by the testers in which testing of the software

build is done based on test plans and test cases prepared.
The process consists of test script execution, test script
maintenance and bug reporting. If bugs are reported then it
is reverted back to development team for correction and
retesting will be performed.
Test Execution Activities
• Execute tests as per plan
• Document test results, and log defects for failed cases
• Map defects to test cases in RTM
• Retest the Defect fixes
• Track the defects to closure
Test Cycle Closure

Test Cycle Closure phase is completion of test

execution which involves several activities like test
completion reporting, collection of test completion
matrices and test results.
Testing team members meet, discuss and analyze
testing artifacts to identify strategies that have to be
implemented in future, taking lessons from current test
cycle.
The idea is to remove process bottlenecks for future test
cycles.
 BOUNDARY VALUE ANALYSIS (BVA)
TESTING

• Boundary value testing is focused on the values at

boundaries. This technique determines whether a
certain range of values are acceptable by the
system or not.
• It is very useful in reducing the number of test
cases. It is most suitable for the systems where an
input is within certain ranges.
• Boundary value analysis (BVA) is based on testing
the boundary values of valid and invalid partitions.
• The Behavior at the edge of each equivalence
partition is more likely to be incorrect than the
behavior within the partition, so boundaries are an
area where testing is likely to yield defects.
• The basic assumption of boundary value analysis is,
the test cases that are created using boundary values
are most likely to cause an error.

• There is 18 and 30 are the boundary values that's why

tester pays more attention to these values, but this
doesn't mean that the middle values like 19, 20,
21….27,28, 29 are ignored. Test cases are developed
for each and every value of the range.
Boundary Value Testing

• Any program can be considered to be a

function in the sense that prog. I/p form
its domain & prog. o/p form its range.
• Input domain testing is the best known
functional testing technique.
Boundary Value Analysis

• When function F is implemented as a

pogram, the input variables x1 & x2 will
have some boundaries
F(x1, x2), a ≤ x1 ≤ b, c ≤ x2 ≤ d
[a,b] [c,d] are ranges of x1 & x2.
• Input space(domain) of our function F is shown above.
• Any point within the shaded rectangle is a legitimate input to
the
function F.
• Boundary value analysis focuses on the boundary of the input
space to identify test cases.
Cont.,

• Errors tend to occur near the extreme

values of an input variable
oe.g. loop conditions (< instead of ≤),
counters
• Basic idea: use input variable values at their minimum
(min), just above the minimum (min+), a nominal value
(nom), just below their maximum (max-), and at their
maximum (max).
• Testing tool (T) generates such Test Cases for Properly
specified program. min, min+, max-, max.
Cont.,

• The boundary value analysis test cases

are obtained by holding the values of all
but one variable at their nominal values,
and letting that variable assume its
extreme values <x
<x
,x
1nom
,x
2min>

1nom 2min+>
<x1nom, x2nom>
<x1nom, x2max->
<x1nom, x2max>
<x1min, x2nom>
<x1min+, x2nom>
<x1nom, x2nom>
<x1max-, x2nom>
<x1max, x2nom>
1) Example on Boundary Value Analysis Test Case Design Technique:

Assume, we have to test a field which accepts Age 18 – 56

• Test case 4: Enter the value 55 (56-1) = Valid
• Test case 5: Enter the value 56 = Valid
• Test case 6: Enter the value 57 (56+1) =Invalid
Example 2:
Assume we have to test a text field (Name) which accepts the length between 6-12 characters.
EXAMPLE 3 Design boundary value test cases for a Pizza delivery app.
Pizza values 1 to 10 is considered valid. A ORDER SUCCESS message is shown.
While value 11 to 99 are considered invalid for order and an ERROR message will
appear,
"Only 10 Pizza can be ordered"

• Minimum boundary value is 1

• Maximum boundary value is 10
• Valid Inputs: 1,2,9,10
• Invalid Inputs: 0 ,11
• Test case 1: Entered value on App 0 (min-1) = Invalid ERROR
• Test case 2: Entered value on App 1 (min) = Valid ORDER SUCCESS
• Test case 3: Entered value on App 2 (min+1) = Valid ORDER SUCCESS
• Test case 4: Entered value on App 9 (max-1) = Valid ORDER SUCCESS
• Test case 5: Entered value on App 10 (max) = Valid ORDER SUCCESS
• Test case 6: Entered value on App 11 (max+1) = Invalid ERROR
THANK YOU