Chapter 4

Software Testing
ISTQB / ISEB Foundation Exam Practice

1 Principles 2 Lifecycle 3 Static testing

4 Dynamic test
5 Management 6 Tools
techniques

Dynamic Testing Techniques

 1 2 3 ISTQB / ISEB Foundation Exam Practice
4 5 6
Dynamic Testing Techniques

Contents
What is a testing technique?
Black and White box testing
Black box test techniques
White box test techniques
Error Guessing
Why dynamic test techniques?


Exhaustive testing (use of all possible inputs
and conditions) is impractical
- must use a subset of all possible test cases
- must have high probability of detecting faults

Need thought processes that help us select
test cases more intelligently
- test case design techniques are such thought
processes
What is a testing technique?


a procedure for selecting or designing tests

based on a structural or functional model of
the software

successful at finding faults

'best' practice

a way of deriving good test cases

a way of objectively measuring a test effort

Testing
Testing should
should be
be rigorous,
rigorous, thorough
thorough and
and systematic
systematic
Advantages of techniques


Different people: similar probability find faults
- gain some independence of thought

Effective testing: find more faults
- focus attention on specific types of fault
- know you're testing the right thing

Efficient testing: find faults with less effort
- avoid duplication
- systematic techniques are measurable

Using
Using techniques
techniques makes
makes testing
testing much
much more
more effective
effective
Measurement


Objective assessment of thoroughness of
testing (with respect to use of each technique)
- useful for comparison of one test effort to another

E.g.

Project A Project B
60% Equivalence 40% Equivalence
partitions partitions
50% Boundaries 45% Boundaries
75% Branches 60% Branches
 1 2 3 ISTQB / ISEB Foundation Exam Practice
4 5 6
Dynamic Testing Techniques

Contents
What is a testing technique?
Black and White box testing
Black box test techniques
White box test techniques
Error Guessing
Three types of systematic technique

Static (non-execution)
• examination of documentation,
source code listings, etc.
Functional (Black Box)
• based on behaviour /
functionality of software
Structural (White Box)
• based on structure
of software
 Some test techniques
Static
Static Dynamic
Dynamic
Reviews etc.
Static Analysis
Behavioural
Behavioural
Inspection
Walkthroughs Structural Non-functional
Non-functional Functional
Functional
Structural
Desk-checking etc.
etc.
Equivalence
Control Usability Partitioning
Data Flow
Flow Performance
etc. Boundary
Value Analysis
etc.
Statement
Symbolic Cause-Effect Graphing
Execution Branch/Decision Arcs
Random
Definition Branch Condition LCSAJ
-Use State Transition
Branch Condition
Combination
Black box versus white box?

Black box appropriate Acceptance

Acceptance
at all levels but
dominates higher
levels of testing System
System

White box used

predominately Integration
Integration
at lower levels
to compliment
Component
Component
black box
 1 2 3 ISTQB / ISEB Foundation Exam Practice
4 5 6
Dynamic Testing Techniques

Contents
What is a testing technique?
Black and White box testing
Black box test techniques
White box test techniques
Error Guessing
Black Box test design and
measurement techniques

Techniques defined in BS 7925-2
- Equivalence partitioning
- Boundary value analysis Also a measurement
technique?
- State transition testing = Yes
- Cause-effect graphing = No

- Syntax testing
- Random testing

Also defines how to specify other techniques
Equivalence partitioning (EP)

- divide (partition) the inputs, outputs, etc. into areas

which are the same (equivalent)
- assumption: if one value works, all will work
- one from each partition better than all from one
invalid valid invalid

0 1 100 101
Boundary value analysis (BVA)

- faults tend to lurk near boundaries

- good place to look for faults
- test values on both sides of boundaries
invalid valid invalid

0 1 100 101
Example: Loan application
2-64 chars.
Customer Name
Account number 6 digits, 1st
non-zero
Loan amount requested
Term of loan £500 to £9000

Monthly repayment
1 to 30 years
Term:
Minimum £10
Repayment:
Interest rate:
Total paid back:
Customer name
Number of characters:

1 2 64 65
invalid valid invalid

Valid characters: A-Z

Any
-’ a-z
space other

Co nditio ns Valid Invalid Valid Invalid

Partitio ns Partitio ns Bo undarie s Bo undarie s
Cus to me r 2 to 64 c hars < 2 c hars 2 c hars 1 c hars
name valid c hars > 64 c hars 64 c hars 65 c hars
invalid c hars 0 c hars
Account number
valid: non-zero
first character:
invalid: zero

number of digits: 5 6 7
invalid invalid
valid

Co nditio ns Valid Invalid Valid Invalid

Partitio ns Partitio ns Bo undarie s Bo undarie s
Ac c o unt 6 dig its < 6 dig its 100000 5 dig its
numbe r 1 s t no n-ze ro > 6 dig its 999999 7 dig its
1 s t dig it = 0 0 dig its
no n-dig it
Loan amount

499 500 9000 9001

invalid valid invalid

Co nditio ns Valid Invalid Valid Invalid

Partitio ns Partitio ns Bo undarie s Bo undarie s
Lo an 500 - 9000 < 500 500 499
amo unt >9000 9000 9001
0
no n-nume ric
null
 Condition template
Conditions Valid Tag Invalid Tag Valid Tag Invalid Tag
Partitions Partitions Boundaries Boundaries
Customer 2 - 64 chars V1 < 2 chars X1 2 chars B1 1 char D1
name valid chars V2 > 64 chars X2 64 chars B2 65 chars D2
invalid char X3 0 chars D3
Account 6 digits V3 < 6 digits X4 100000 B3 5 digits D4
number 1st non-zero V4 > 6 digits X5 999999 B4 7 digits D5
st
1 digit = 0 X6 0 digits D6
non-digit X7
Loan 500 - 9000 V5 < 500 X8 500 B5 499 D7
amount >9000 X9 9000 B6 9001 D8
0 X10
non-integer X11
null X12
Design test cases

Test Description Expected Outcome New Tags

Case Covered
1 Name: John Smith Term: 3 years V1, V2,
Acc no: 123456 Repayment: 79.86 V3, V4,
Loan: 2500 Interest rate: 10% V5 .....
Term: 3 years Total paid: 2874.96

2 Name: AB Term: 1 year B1, B3,

Acc no: 100000 Repayment: 44.80 B5, .....
Loan: 500 Interest rate: 7.5%
Term: 1 year Total paid: 537.60
Why do both EP and BVA?


If you do boundaries only, you have covered all the
partitions as well
- technically correct and may be OK if everything works
correctly!
- if the test fails, is the whole partition wrong, or is a
boundary in the wrong place - have to test mid-partition
anyway
- testing only extremes may not give confidence for typical
use scenarios (especially for users)
- boundaries may be harder (more costly) to set up
 Test objectives?
Condition Valid Tag Invalid Tag Valid Tag Invalid Tag
Partition Partition Boundary Boundary


For a thorough approach: VP, IP, VB, IB

Under time pressure, depends on your test objective
- minimal user-confidence: VP only?
- maximum fault finding: VB first (plus IB?)