Application Modeling

: Testing

Malliga
Ramalingam

malliga@onethink.com
 How do we decide Software
Correctness?

Verification
The process of evaluating a system
or component to determine whether
products of a given development
phase satisfy conditions imposed at
start of that phase
Are we building the product right?
Validation
The process of evaluating a system
or component during or at the end of
the development process to
malliga@onethink.com
determine whether it satisfies
 Approaches to V&V

Dynamic
Testing the product. Dynamic testing
is one of the most widely used
validation techniques. Its aim is to
reveal errors in a given program by
executing it in a controlled
environment.
Static
Analysing the product to deduce its
correct operation as a logical
malliga@onethink.com
consequence of design decisions.
 Static Testing

Informal techniques
Reviews
Pair programming
Walkthrough
Team Review
Inspection
Audit
Formal Techniques
Correctness Proofs
malliga@onethink.com
 Responsibilities for team
members

A Specific member of the team may be

The Moderator – to moderate the review /
walkthrough / inspection process
The reader – to present the relevant
material in a logical fashtion
Other members – to critically question the
material being presented
The Recorder – to document defects &
deviations
The above roles may be shared

malliga@onethink.com
 Comparison
Category & Review Walkthrough Inspection
Attributes
Objectives Evaluate Detect Detect and
conforman defects; identify
ce to Examine defects;
specificati alternative verify
ons; s; Forum resolution
Ensure for
Group change
3 or more learning
2 to 7 3 to 6
Dynamics integrity
persons: persons persons;
Technical Technical Document
experts & experts ed
peer mix and peer attendanc
mix
malliga@onethink.com e;
 Comparison
Category & Review Walkthrough Inspection
Attributes
Decision Review Team All decisions Team
making & requests made by declares exit
Change Project Team producer;Ch decision –
Control leadership or ange is Acceptance
Management Prerogrative Rework &
to act on of the author verify
recommenda
Procedures Moderate
tions to Relatively Rework &
Relatively
material high low re-inspect
low
Volume

malliga@onethink.com
 Comparison
Category & Review Walkthrough Inspection
Attributes
Presenter Software Author Other than
Element author
Representati
ve

Outputs Review Defect Log Defect Log

Report

malliga@onethink.com
 Advantages of Static over
Dynamic Methods

Early detection of software

defects
Static methods expose defects,
whereas dynamic methods show
only the symptom of the defect
Static methods expose a batch of
defects, whereas it is usually one
by one in dynamic methods.
malliga@onethink.com
Some defects can be found only
by static testing

Examples:
Code redundancy ( when logic is not
affected)
Dead code
Violation of coding standards

malliga@onethink.com
 Dynamic Testing

A tester is given a false statement

“The system works”
Job:
Selecting from infinite number of
possibilities, an input that
contradicts the statement

malliga@onethink.com
 Introduction to Testing

“Testing is a process of executing a

program with the intent of finding
errors”
Facts on testing
A deliberate effort to find non-
conformances in code
Costs 50% to 80% of total development
costs
Has come to stay as inevitable value-
added activity
Maximum returns should be derived from
malliga@onethink.com
testing
 Methods of testing

Black box testing

Equivalence Partitioning
Boundary Value Analysis
Cause-Effect Analysis
Cause-Effect Graphing
Error Guessing
White box testing
Basis Path Testing
malliga@onethink.com
 Documents Used

Test Specifications
The document specifying the
conditions governing the items to be
tested
Test Cases
The document specifying the inputs,
expected results based on the test
specifications
Test Plan
The document describing the scope,
malliga@onethink.com
 TestCase Design

“This is the partitioning of the input

domain into finite number of equivalent
classes such that testing of a
representative from each class is
equivalent to testing for any other
values, in that class”
Steps in designing test cases for
equivalence classes
For Arrange identify
One valid value within range
One invalid value above the range
malliga@onethink.com
One invalid value below the range
 Test case Design:Method

Equivalence Partitioning
For Specific set of values identify
One valid case for each value
One invalid value

Test cases for the type Account

(savings, current) will be Savings,
current, overdraft etc..
malliga@onethink.com
 Testcase Design:Methods

Boundary value analysis

Exploring boundary conditions have
a higher probability of detecting
errors
For a range of values
Two valid cases at both ends
Two invalid cases just beyond the
range limits

malliga@onethink.com
 Testcase Design:Methods

Cause Effect Analysis

Drawback of previous 2 methods –
they do not explore the combination
of input conditions
Is an approach for studying the
specifications carefully and
identifying the combinations of input
conditions and their effect in the
forma of a table.
Useful when applications has few
input combinations of input
malliga@onethink.com
conditions and readily visible
 Blackbox testing Example

Purchase Member(M) Non-

Amount(PA) Member(NM)

<500 2% No discount

[500…4999] 5% 2%

>=5000 8%
malliga@onethink.com 3%
 BBT : Input variable AMT[1…
MAX]
Equivalence Classes Test cases
C1={x/x in [1…499]} (-20,200)
C2={x/x in [500… (1200)
4999]} (7000,
C3={x/x in [5000… MAX+100)
MAX]} (3.20,xyz,$@)
{Invalid Class} Test Cases
Boundary Values (0,1,499)
C1={x/x in [1…499]} (500,4999)
C2={x/x in [500… (5000,MAX,
4999]} MAX+1)
C3={x/x in [5000…
MAX]}
malliga@onethink.com Test cases
{Invalid Class}
(M,NM,O)
 BBT : Test cases

Use combination of inputs (AMT: 16 &

MEM:3)
Use ‘creativity’ to prune down/add
All invalid combinations need not be
tested many times
SNo Check all valid
Test output
case is coveredObserved
Expected
Result Result

malliga@onethink.com
 Basis Path testing

Use combination of inputs (AMT: 16 &

MEM:3)
Use ‘creativity’ to prune down/add
All invalid combinations need not be
tested many times
SNo Check all valid
Test output
case is coveredObserved
Expected
Result Result

malliga@onethink.com