Session 5 - Testing

8/14/2019 Session 5 - Testing

1/22

[email protected]

Application ModelingApplication Modeling

: Testing: Testing

MalligaRamalingam


2/22

[email protected]

How do we decide Software

Correctness?

VerificationThe process of evaluating a systemor component to determine whether

products of a given developmentphase satisfy conditions imposed atstart of that phase

Are we building the product right?

ValidationThe process of evaluating a systemor component during or at the end ofthe development process todetermine whether it satisfies


3/22

[email protected]

Approaches to V&V

Dynamic

Testing the product. Dynamic testingis one of the most widely usedvalidation techniques. Its aim is toreveal errors in a given program byexecuting it in a controlled

environment.Static

Analysing the product to deduce itscorrect operation as a logicalconsequence of design decisions.


4/22

[email protected]

Static Testing

Informal techniques

Reviews

Pair programming

Walkthrough

Team Review

Inspection

Audit

Formal Techniques

Correctness Proofs


5/22

[email protected]

Responsibilities for team

members

A Specific member of the team may beThe Moderator to moderate the review /walkthrough / inspection process

The reader to present the relevantmaterial in a logical fashtion

Other members to critically question thematerial being presented

The Recorder to document defects &deviations

The above roles may be shared


6/22

[email protected]

Comparison

3 to 6persons;Documentedattendanc

e;

2 to 7persons

Technicalexpertsand peer

mix

3 or morepersons:

Technicalexperts &peer mix

GroupDynamics

Detect andidentifydefects;verifyresolution

Detectdefects;Examinealternatives; Forumforlearning

Evaluateconformance tospecifications;Ensurechange

integrity

Objectives

InspectionWalkthroughReviewCategory &Attributes


7/22

[email protected]

Comparison

Relativelylow

Relativelylow

Moderate tohigh

ProceduresmaterialVolume

Teamdeclares exitdecision

AcceptanceRework &

verify

Rework &re-inspect

All decisionsmade byproducer;Ch

ange isPrerogrativeof the author

Review TeamrequestsProject Team

leadership orManagementto act onrecommendations

Decisionmaking &Change

Control



8/22

[email protected]

Comparison

Defect LogDefect LogReviewReport

Outputs

Other thanauthor

AuthorSoftwareElementRepresentati

ve

Presenter



9/22

[email protected]

Advantages of Static over

Dynamic Methods

Early detection of softwaredefects

Static methods expose defects,whereas dynamic methods showonly the symptom of the defect

Static methods expose a batch ofdefects, whereas it is usually oneby one in dynamic methods.


10/22

[email protected]

Some defects can be found only

by static testing

Examples:

Code redundancy ( when logic is notaffected)

Dead code

Violation of coding standards


11/22

[email protected]

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


12/22

[email protected]

Introduction to Testing

Testing is a process of executing aprogram with the intent of findingerrors

Facts on testingA deliberate effort to find non-conformances in code

Costs 50% to 80% of total developmentcosts

Has come to stay as inevitable value-added activity

Maximum returns should be derived fromtesting


13/22

[email protected]

Methods of testing

Black box testing

Equivalence Partitioning

Boundary Value AnalysisCause-Effect Analysis

Cause-Effect Graphing

Error Guessing

White box testing

Basis Path Testing


14/22

[email protected]

Documents Used

Test Specifications

The document specifying theconditions governing the items to betested

Test Cases

The document specifying the inputs,

expected results based on the testspecifications

Test Plan

The document describing the scope,


15/22

[email protected]

TestCase Design

This is the partitioning of the inputdomain into finite number of equivalentclasses such that testing of a

representative from each class isequivalent to testing for any othervalues, in that class

Steps in designing test cases forequivalence classes

For Arrange identify

One valid value within range

One invalid value above the range

One invalid value below the range


16/22

[email protected]

Test case Design:Method

Equivalence Partitioning

For Specific set of values identify

One valid case for each valueOne invalid value

Test cases for the type Account(savings, current) will be Savings,current, overdraft etc..


17/22

[email protected]

Testcase Design:Methods

Boundary value analysis

Exploring boundary conditions havea higher probability of detectingerrors

For a range of values

Two valid cases at both ends

Two invalid cases just beyond therange limits


18/22

[email protected]

Testcase Design:Methods

Cause Effect AnalysisDrawback of previous 2 methods they do not explore the combination

of input conditionsIs an approach for studying thespecifications carefully andidentifying the combinations of input

conditions and their effect in theforma of a table.

Useful when applications has fewinput combinations of inputconditions and readily visible


19/22

[email protected]

Blackbox testing Example

3%8%>=5000

2%5%[5004999]

No discount2%


20/22

[email protected]

BBT : Input variable AMT[1

MAX]

Equivalence ClassesC1={x/x in [1499]}C2={x/x in [5004999]}

C3={x/x in [5000MAX]}{Invalid Class}

Boundary Values

C1={x/x in [1499]}C2={x/x in [5004999]}C3={x/x in [5000MAX]}

{Invalid Class}

Test cases(-20,200)(1200)(7000,

MAX+100)(3.20,xyz,$@)

Test Cases(0,1,499)

(500,4999)(5000,MAX,MAX+1)

Test cases(M,NM,O)


21/22

[email protected]

BBT : Test cases

Use combination of inputs (AMT: 16 &MEM:3)

Use creativity to prune down/add

All invalid combinations need not betested many times

Check all valid output is coveredObservedResult

ExpectedResult

Test caseSNo


22/22

[email protected]

Basis Path testing

Use combination of inputs (AMT: 16 &MEM:3)

Use creativity to prune down/add

All invalid combinations need not betested many times

Check all valid output is coveredObservedResult

ExpectedResult

Test caseSNo