STE(22518)

UNIT1: Basics of Software Testing

 Software Testing
• Def 1:
Executing the program/software with
intention to find bug/error
• Def 2:
activity to check whether the actual results
match the expected results and to ensure that
the software system is Defect free
• Def3:
to evaluate the functionality of a software
application with an intent to find whether the
developed software met the specified
requirements or not.
– According to SRS
– According to
customer/client
 Objectives of Software Testing
• Finding defects
• To find them as early as possible
• And to ensure that they get fixed
• Preventing bugs/ defects
• Ensure that software meets requirements as
per SRS
• Ensure that software meets requirements as
per User/ customer requirement
• To develop a quality software
• Gain customer satisfaction
 Software Bug
• A software has a bug when,
- It does not do the things which SRS says that it should
do
- It does the things that SRS says that it should not do
- It does the things which SRS does not mention.

- It does not do the things which SRS does not mention,

but should have mentioned
 What is Test case?
• set of actions executed to verify a particular
feature or functionality of your software
application
 Test case
• set of preconditions (prerequisites)
• procedures (inputs / actions)
• postconditions (expected results)
When to start Testing?(Entry Criteria)
 When to start Testing?
• Testing is done in different forms at every
phase of SDLC −
A) During the requirement gathering
phase, the analysis and verification of
requirements are also considered as
testing.

B) Reviewing the design in the design

phase with the intent to improve the
design is also considered as testing.

C)Testing performed by a developer on

completion of the code is also categorized
as testing.
When to Stop Testing?
 When to Stop Testing?(Exit Criteria)
• testing is a never-ending process
• No software is 100% bug free

•Deadlines
•Completion of test case execution
- test cases executed out of total no. of test cases
•Bug rate falls bellow a threshold
- Defect density is low (defects per unit of lines of code)
•No critical bugs are remaining to be resolved
•Customer asks to stop
•Management Decision
 Assignment
• Write at least 5 test cases for testing Gmail
Login Page
 How to Decide quality of software?
• Based on Whether the product meets SRS
requirements (Verification)
• Based on Whether product satisfies Customer
needs (Validation)
• SRS Compliance does not always mean Customer satisfaction:
→ change in requirements
→ Faulty SRS
 Verification and Validation
• Verification ensures:
Are we building product
correctly? → Process
• Validation ensures: Are
we building correct
product? → Product
 Static and Dynamic testing
• Static testing is testing the software without
executing the code/program
→ Mostly include documentation testing
→ Also include techniques like code review, inspection, walkthrough, etc
→ Significant as verification of software

• Dynamic Testing is testing the software by executing

the program/ software
→ Includes execution of software to check its validity
→ validation
 Quality Assurance Vs Quality Control
• Quality: The degree of
excellence
• Quality Assurance:
→ the maintenance of a desired level of
quality in a service or product, especially
by means of attention to every stage of
the process.

• Quality Control:
→ system of maintaining standards in
manufactured products by testing a
sample of the output against the
specification.
QA Vs QC
 V model
• Combines SDLC with STLC
• there is a testing phase parallel to each
development phase
• extension of the waterfall model
Problem with the Waterfall Model
• testing in the model starts only after implementation is done.
• costs of fixing a defect increase across the development
lifecycle. The earlier in life cycle a defect is detected, the
cheaper it is to fix it.
The V model
 Testing Techniques
Software
Testing

Black Box White Box

Testing Testing

Dynamic black Static White Dynamic White

Static Black Box
Box Box Box

Inspection, Code Coverage,

Documentation Boundary Value
Code Review, flow coverage,
Testing Analysis, etc
etc etc
 Black Box Testing Techniques
• due to time and budget considerations, it is not
possible to perform exhausting testing for each
set of test data
• We need an easy way or special techniques that
can select test cases intelligently from the pool of
test-case, such that all test scenarios are covered.
• We use two techniques - Equivalence
Partitioning & Boundary Value Analysis testing
techniques
 Equivalence Partitioning
• also known as Equivalence class partitioning (ECP)
• divides input domain into classes of data
• with the help of these classes of data, test cases can
be derived
 Boundary Value Analysis
to select input variable values at their:
• Minimum
• Just above the minimum
• A nominal value
• Just below the maximum
• Maximum
 Example
• As a simple example, let’s take a ticketing system
where children under age 6 are allowed to travel for
free, people under 18 as well as senior people older
than 64 pay $10 while adults need to pay $20.
 Requirement Based Testing
• In this technique, test cases, conditions and
data are derived from requirements
• includes functional tests and also non-
functional attributes such as performance,
reliability or usability.
 Static White Box Testing Techniques
• Code is available
• Code is not executed
• It includes carefully and methodically reviewing the
software design, architecture, or code for bugs without
executing it
• Also referred as structural analysis
• Includes:
→Technical Reviews
→ Peer Review
→ Walkthroughs
→ Inspections
 Peer Review
• The easiest way to get team members together and
doing their first formal reviews of the software is peer
reviews.
• Sometimes called buddy reviews.
• This method is really more of an "I'll show you mine if
you show me yours" type discussion.
• Peer reviews are often held with just the programmer
who designed the architecture or wrote the code and
one or two other programmers or testers acting as
reviewers.
• These reviews are not based on the procedure and not
documented.
 Walkthroughs
• In walkthrough, author guides the review team via the
document to fulfil the common understanding and
collecting the feedback.
• Walkthrough is not a formal process.
• In walkthrough, a review team does not require to do
detailed study before meeting while authors are
already in the scope of preparation.
• Walkthrough is useful for higher-level documents i.e
requirement specification and architectural
documents.
• Describe and evaluate the content of the document.
• Study and discuss the validity of possible alternatives
and proposed solutions.
 Inspections
• The trained moderator guides the Inspection. It is
most formal type of review.
• The reviewers are prepared and check the
documents before the meeting.
• In Inspection, a separate preparation is achieved
when the product is examined and defects are
found. These defects are documented in issue
log.
• In Inspection, moderator performs a formal
follow-up by applying exit criteria.
 Technical Review
• Technical review is a discussion meeting that
focuses on technical content of the
document. It is a less formal review.
• It is guided by a trained moderator or a
technical expert.
• The goal is to evaluate the value of technical
concept in the project environment.
Formality
 Dynamic White Box Testing
• Code is available/ accessible
• Code is executed to test
• It verifies:
→Internal security holes
→Broken or poorly structured paths in the coding
processes
→The flow of specific inputs through the code
→Expected output
→The functionality of conditional loops
→Testing of each statement, object, and function on an
individual basis
 Code coverage
• Code coverage is a measure which describes the
degree of which the source code of the program
has been tested.
• finds the areas of the program not exercised by a
set of test cases.
• Code Coverage Methods:
→Statement Coverage
→Decision Coverage
→Branch Coverage
 Statement Coverage
• It ensures that all the executable statements
in the source code are executed at least once
• purpose of Statement Coverage is to cover all
the possible paths, lines and statements in
source code.
• However, it can not assure full coverage of code in certain cases:
Statement Coverage= 5/7*100= 71%

e. g.
 Decision/Branch Coverage
• The goal of decision coverage testing is to cover and validate all the
accessible source code by checking and ensuring that each branch
of every possible decision point is executed at least once.
In example below, we have two paths to test.
• (1) 1A-2C-3D-E-4G-5H
• (2) 1A-2B-E-4F
However, this method may not test following program
fully:
PRINT “Hello World”
IF Date$ = “01-01-2000” AND Time$ = “00:00:00” THEN
PRINT “Happy New Year”
END IF
PRINT “The date is: “; Date$
PRINT “The time is: “; Time$
END
 Condition coverage
• also known as Predicate Coverage
• each one of the Boolean expression have been
evaluated to both TRUE and FALSE.
Path Coverage
• involves using the source
code of a program in
order to find every
possible executable path
• this method is designed to
execute all or selected
path through a computer
program
• E.g. there are 3 paths or
condition that need to be
tested to get the output,
• Path 1: 1,2,3,5,6, 7
• Path 2: 1,2,4,5,6, 7
• Path 3: 1, 6, 7
 Cyclomatic Complexity
• a testing metric used for measuring the
complexity of a software program
• measure of independent paths in the source
code of a software program
• Cyclomatic complexity can be calculated by
using control flow graphs
• Mathematical representation:
• Mathematically, it is set of independent paths
through the graph diagram. The Code
complexity of the program can be defined
using the formula -
C=E-N+2
Where,
• C- Cyclomatic Complexity
• E - Number of edges
• N - Number of Nodes
• Calculate Cyclomatic Complexity for the program:

A = 10
IF B > C THEN
A=B
ELSE A = C
ENDIF
Print A
Print B
Print C
• The graph
shows seven
shapes(nodes),
seven
lines(edges),
hence
cyclomatic
complexity is
7-7+2 = 2.