4

3
Manageme 5 Standards
2 Life cycle Infrastructu
1 Overview nt and
components re
component Organizing
components
8 Test s
6 Static 7 Dynamic
manageme 9 Tools
tesing testing
nt

Dynamic techniques
Learning objectives
Explain the characteristics and differences between
specification-based testing, structure-based testing and
experience-based testing
Compare the terms test condition, test case and test
procedure
Write test cases from given software models using
techniques: equivalence partitioning, boundary value
analysis, decision tables, state transition testing
Write test cases from given control flows using techniques:
statement coverage, decision coverage

Slide 2
References
Dorothy Grahamet, Erik van Veenendaal, Isabel Evans, Rex
Black. Foundations of software testing: ISTQB Certification

Lee Copeland (2004). A Practitioner's Guide to Software

Test Design. Artech House. ISBN:158053791x

Slide 3
 1 2 3 4 5

6 7 8 9

Contents
Dynamic techniques
Test condition – Test case – Test
procedure
Black-box techniques
White-box techniques
Experience-based techniques
Choosing test techniques
Categories of dynamic techniques
Specification-based (black-box techniques)
view software as black-box with input and output

Structure-based (white-box or glass-box techniques)

see the internal structure of the software

Experience-based
use the tester’s experience, knowledge and intuition

Slide 6
Where to apply?
Black box appropriate at
all levels but dominates Acceptance
Acceptance
higher levels of testing
White box used
System
System
predominately at lower
levels
Experience-based
Integration
Integration
techniques used when
there is no specification
or inadequate or out of Component
Component
date
Slide 7
 Dynamic technique

Experience-based Specification-based
Structure-based
Error guessing Equivalence
Partitioning
Exploratory testing
Statement Boundary
Value Analysis
Decision
Decision Tables
Condition
Condition State
Combination Transition
Use Case
testing
Slide 8
 1 2 3 4 5

6 7 8 9

Contents
Dynamic techniques
Test condition – Test case – Test
procedure
Black-box techniques
White-box techniques
Experience-based techniques
Choosing test techniques
Test process

Planning and Control

Analysis & Evaluating Check

Execution
Design Reporting completion

Identify conditions

Design test cases

Specify test procedures

Slide 10
Task 1: identify test conditions

Test condition determine 'what' is to be tested, e.g.

“number items ordered > 99”
“the ID must be numeric”
Based on (test basis):
system requirement
technical specification
code
business process
experienced user's knowledge of the system
(sometimes)
Prioritise the test conditions to ensure most
important conditions are covered
Slide 11
Task 2: design test cases
A set of input values, expected results, pre-conditions,
post-conditions, developed for a test condition
input values: all inputs needed
expected result: predict the outcome of each test case
pre-condition: specifies things that must in place before the
test can be run
post-condition: specifies anything that applies after the test
case completes

Prioritise the test cases

Slide 12
Task 3: specify test procedures

Also referred to as a test script

When to used:
describes the sequential steps to be taken in
running a set of tests
some test cases may need to be run in a
particular sequence

Slide 13
Test condition – Test case – Test procedure
Example: Check Login functionality
Test Test Case Pre- Test Procedure Input Expected
Condition Name cond Results

Check Login Check valid 1) Launch application User Name: Login must
functionality User Name 2) Enter User Name admin be
& Password 3) Enter Password Password: successfull
4) Click Login 123456

Slide 14
 1 2 3 4 5

6 7 8 9

Contents
Dynamic techniques
Test condition – Test case – Test
procedure
Black-box techniques
White-box techniques
Experience-based techniques
Choosing test techniques
Black-box techniques
Based on specifications (thông số kỹ thuật) or models of
what the system should do
Known as specification-based techniques (kỹ thuật dựa
trên đặc tả)
Including both functional and non-functional aspects
Some techniques
equivalence partitioning
boundary value analysis
decision tables testing
state transition testing
use case testing

Slide 16
Equivalence partitioning
(EP)

Divide (partition) the inputs, outputs,...

into areas which makes the system
behave “in the same manner”
we need test only one condition from each
partition
if one element works correctly, all will
work correctly
Rule: each
Ex1. Please inputinput
x>10 condition has at least two
invalid
equivalence classes for it 10 valid
 the condition – valid
Ex2.one class
Please that
input x insatisfies
[a,b]
class invalid a valid b invalid
second class that doesn't satisfy the conditionSlide – 17
Equivalence partitioning
Guidelines
Range of values  one valid and two invalid classes
“integer x shall be between 100 and 200” 
{integer x | 100 x 200},
{integer x | x < 100},
{integer x | x > 200}

Specific value within a range  one valid and two invalid

equivalence classes
“value of integer x shall be 100” 
{integer x | x = 100},
{integer x | x < 100},
{integer x | x > 100} Slide 18
Equivalence partitioning
Guidelines
Set of values  one valid and one invalid equivalence class
“weekday x shall be a working day” 
x {Monday, Tuesday, Wednesday, Thursday, Friday},
x {Saturday, Sunday}

Set of values, and each case will be dealt with differently 

a valid equivalence class for each element and only one
invalid class for values outside the set
“a discount code must be input as P for a preferred
customer, R for a standard reduced rate, or N for none,
and if each case is treated differently” 
code=P, code=R, code=N, code=not one of P, R, N
Slide 19
Equivalence partitioning
Guidelines
Boolean  one valid and one invalid equivalence class
“condition x shall be true” 
x = true, x = false

One or several equivalence classes for illegal values, that

is, for values that are incompatible with the type of the
input parameter and therefore out of the parameter’s
domain
“integer values x” 
{real-number x}, {character-string x}

Slide 20
Equivalence partitioning
Guidelines
If an input condition specifies a ‘must be’ situation
“first character of the identifier must be a letter” 
{first character is a letter}, {first character is not a letter}

Equivalence classes can be of the output desired in the

program

If there is reason to believe that the system handles each

valid/invalid/illegal input value differently, then each value
shall generate an equivalence class

Slide 21
Example EP 1

Expected
from 18 to 50

invalid valid invalid

Age
18 50

not no
integer integer not numeric input
input

Slide 22
Example EP 1 (cont.)
Draw table of analysis
Condition Valid partition Invalid partition
Age integer between 18 and 50 <18
>50
not integer
not numeric
no input

Slide 23
Design test case
Write a new test case covering as many of the uncovered
valid equivalence classes as possible, until all valid
equivalence classes have been covered by test cases

Write a test case that covers one, and only one, of the
uncovered invalid equivalence classes, until all invalid
equivalence classes have been covered by test cases

Example (next slide)

Slide 24
 Design test case for EP: Example
Table of analysis
Condition Valid partition Invalid partition
Age integer between 18 and 50 <18
>50
not numeric
not integer
no input
Test case design
Condition Test case name Inputs Expected results
Test on Test valid age Abc;20 Ok…
Age field
Test age<18 Abc;10 Message “Age must be >18”
Test age>50 Abc;60 Message “Age must be <50”
Test invalid characters Abc;ab Message “Age must be a numeric”
Test not integer Abc;21.5 Message “Age must be an integer”
Test null value Abc; Message “Age not allow null”
Slide 25
Example EP 2
The Golden Splash Swimming Center’s ticket price depends on
four variables: day (weekday, weekend), visitor’s status (OT = one
time, M = member), entry hour (6.00–19.00, 19.01–24.00) and
visitor’s age (up to 16, 16.01–60, 60.01–120).

Define valid and invalid equivalence classes and the corresponding

test case values.
Slide 26
 Example EP 2: Solution
Condition Valid Par. Invalid Par.
Day of week {Mon, Tue, Wed, Thurs, Fri } Any alpha-numeric value (not a day)
{Sat, Sun}
Visitor’s OT Other than OT or M
status M
Entry hour 6.00–19.00 < 6.00
19.01–24.00 >24.00
Any alpha-numeric values (not time)
Visitor’s age 0.0–16.00 <0.0
16.01–60.00 > 120.0
60.01–120.00 Any alpha-numeric value (not an age)

Slide 27
Example EP 2: Solution (cont.)

Slide 28
Example EP 3
A program reads three numbers, A, B, and C, with a range [1,
50] and prints the largest number. Design test cases for this
program using equivalence class testing technique.

Slide 29
Boundary value analysis (BVA)

Based on testing at the boundaries between

partitions (the maximum and minimum values
of partitions)
Have both valid boundaries (in the valid
partitions) and invalid boundaries (in the
invalid partitions) valid
invalid invalid
For example, if a program should accept a
sequence of0 numbers
1 100 1011 and 100
between
Boundary values: 0, 1, 100, 101

Slide 30
Example BVA 1

Expected
from 18 to 50

invalid valid invalid

Age
17 18 50 51
Condition Valid Invalid
Boundary Boundary
Age 18 17
50 51
 Example BVA 2
The Golden Splash Swimming Center’s ticket price
Condition Valid Invalid
Boundary Boundary
Entry hour 6.00 5.59
19.00 24.01
19.01
24.00
Visitor’s age 0.0 -0.01
16.00 120.01
16.01
60.00
60.01
120.00

Slide 32
Example EP - BVA
Expected
from 18 to 50

invalid valid invalid

Age
17 18 50 51

not no
integer integer non-numeric input
input
Condition Valid Invalid Valid Invalid
Partition Partition Boundary Boundary
Age 18 - 50 < 18 18 17
> 50 50 51
Số thực
Không là kí tự số
Rỗng Slide 33
Design test case (for Age)
# Test case type Input Expected
Name Age result

1 Valid partition cho Age Nguyen 30 (tìm trong đặc tả)

An
2 Invalid partition cho Nguyen 15 “Lỗi: nhập Age <18”
Age An
3 Nguyen 60 “Lỗi: nhập Age >50”
An
4 Nguyen 20.5 “Lỗi: Age là số thực”
An
5 Nguyen ab “Lỗi: Age không là
An số”
6 Nguyen “Lỗi: Age rỗng”
An
7 Valid boundary cho Nguyen 18 (tìm trong đặc tả)Slide 34
Exercise 1: Loan application
2-64 chars
Customer Name
Account number 6 digits, 1st
non-zero
Loan amount requested
Term of loan £500 to £9000

1 to 30 years
Repayment:
Interest rate:
Total paid back:

Slide 35
 Customer name 2-64 chars

Number
of
invalid 1 2 valid 64 65 invalid
character
s:
Valid characters A-Z, a-z, Invalid
space
Condition Valid Invalid Valid Invalid
Partition Partition Boundary Boundary

Customer 2 to 64 chars < 2 chars 2 chars 1 chars

name > 64 chars 64 chars 65 chars
not a name
null
Slide 36
 Account number 6 digits, 1st
non-zero

Number of 5 6 7
digits: invalid valid invalid

valid: non-zero
First
character: invalid: zero
Non
0-9 numeric
Valid characters:
Condition Valid Invalid Valid Invalid
Partition Partition Boundary Boundary
Account 6 digits and < 6 digits 5
number 1st non-zero digits
> 6 digits
7
6 digits and 1st digits
digit = 0
non-digit
null
 Loan amount £500 to £9000

invalid valid invalid

Loan amount
499 500 9000 9001
Non
Valid characters: 0-9 numeric

not
Type of number: integer integer
Condition Valid Invalid Valid Invalid
Partition Partition Boundary Boundary
Loan 500 – 9000 < 500 500 499
amount >9000 9000 9001
non
numeric
not integer
null Slide 38
 Term of loan 1 to 30 years

invalid valid invalid

Term of loan
0 1 30 31
Non
Valid characters: 0-9 numeric

not
Type of number: integer integer
Condition Valid Invalid Valid Invalid
Partition Partition Boundary Boundary
Term of 1 – 30 <1 1 0
loan >30 30 31
non
numeric
not integer
null Slide 39
Condition template
Conditions Valid Invalid Valid Invalid
Partitions Partitions Boundaries Boundaries
Customer 2 - 64 chars > 64 chars 2 chars 1 char
name not a name 64 chars 65 chars
null
Account 6 digits and
< 6 digits 5 digits
number 1st non-zero
> 6 digits 7 digits
6 digits and 1st
0 digits
digit = 0
non-digit
Loan amount 500 - 9000 < 500 500 499
>9000 9000 9001
non numeric
not integer
null
Term of loan 1-30 <1 1 0
>30 30 31
non numeric
not integer
null Slide 40
Design test case for loan application
# Test case name Input Expected result
1 Test valid partition Customer name= John H Repayment=
Account numer= 123456 Interest rate=
Loan amount= 600 Total paid back=
Term of loan= 2

2 Customer name: … Error message: …

Test invalid partition
number of chars (>
64 chars)

… … … …

Slide 41
Exercise 2: Bank account
Suppose you have a bank account that the rate of interest
depending on the balance in the account: a balance in the
range $0 up to $100.00 has a 3%, a balance over $100.00
and up to $1000.00 has a 5%, and balances of $1000.00 and
over have a 7%. What valid partition, invalid partition, valid
boundary and invalid boundary might you use? What test
cases we design?

Slide 42
 Solution: Bank account
Balance in account
Invalid Valid (for 3%) Valid (for 5%) Valid (for 7%)
-$0.01 $0.00 $100.00 $100.01 $999.99 $1000.00
Test Valid partitions Invalid Valid Invalid
conditions partitions boundaries boundaries

Balance $0.00 - $100.00 < $0.00 $0.00 -$0.01

in $100.01 - $999.99 >$Max $100.00 $Max+0.01
account
non-digit (if $100.01
$1000.00 - $Max balance is an $999.99
input field)
$1000.00
null
$Max

Slide 43
BVA with ‘open boundary’
One of the sides of the partition is not defined
How to test?
Go back to the specification (đặc tả)
Investigate (xem xét) other related areas of the system
Probably need to use an intuitive (trực quan) or experience-
based (dựa trên kinh nghiệm) approach to probe various
large values trying to make it fail

Slide 44
Exercise 3
A mail-order company selling flower seeds charges
£3.95 for postage and packing on all orders up to £20.00
value and
£4.95 for orders above £20.00 value and up to £40.00 value.
For orders above £40.00 value there is no charge for postage
and packing.
If you were using equivalence partitioning to prepare test
cases for the postage and packing charges what valid
partitions would you define?
What about non-valid partitions? What boundary values?
Design test cases.

Slide 45
 Exercise 3: Solution
Orders
invalid valid valid (for £3.95) valid (for £4.95) valid (for £0)

-£0.01 £0.00 £0.01 £20.00 £20.01 £40.00 £40.01

Test Valid partitions Invalid Valid Invalid
conditions partitions boundaries boundaries
Orders £0.01 - £20.00 < £0.00 £0.00 -£0.01
£20.01 - £40.00 > £Max £0.01 £Max+0.01
non-digit £20.00
£40.01- £Max null £20.01
£40.00
£40.01
£Max Slide 46
Exercise 3: Solution - Design test cases
Condition # Inputs Expected results
Orders 1 £10.00 Postage and packing = 3.95
2 £30.00 Postage and packing = 4.95
3 £50.00 Postage and packing = 0
4 -£1.00 Invalid orders…
5 a1 Invalid character…
6 Not allow empty
7 £0.00 Postage and packing = 0
8 £0.01 Postage and packing = 3.95
9 £20.00 Postage and packing = 3.95
10 £20.01 Postage and packing = 4.95
11 £40.00 Postage and packing = 4.95
12 £40.01 Postage and packing = 0
13 -0.01 Invalid orders…
Slide 47
Applicability and Limitations
Equivalence class and boundary value testing are most
suited to systems in which much of the input data takes on
values within ranges or within sets
Applicable at the unit, integration, system, and acceptance
test levels. All it requires are inputs that can be partitioned
and boundaries that can be identified based on the
system's requirements

Slide 48
Decision tables testing
A good way to deal with combination of inputs, which
produce different results
Decision table
Known as a 'cause-effect' table
A table showing combinations of input with their associated
output or action
Business Business Business Business
Rule 1 Rule 2 Rule 3 Rule 4
Condition T T F F
1
Condition T F T T
2
Condition T - F T
3
Action 1 Y N N N Slide 49
Decision tables testing A
B
T
T
T
F
F
T
F
F

Design and using decision table R1 N N Y Y

1. identify conditions (which need to be combined)

2. put them into a table
3. identify all of the combinations of true and false
4. identify the correct outcome for each combination
 rationalise input combinations
 some combinations may be impossible or not of interest
 use a hyphen to denote “don’t care”
5. write test cases for each of the rule in the table
 each column is one test case (at least), the Conditions specify
the inputs and the Actions specify the expected results

Slide 50
Decision tables testing example 1
Car rental example:
The specification says: If Age is over 23 and the person has
a clean driving record, supply rental car, else reject.
Conditions/Input Rule 1 Rule 2 Rule 3 Rule 4
Age > 23 T T F F
Clean driving record T F T F

Action/Output
Supply rental car Y N N N

# Test case description Expected

result
1 Mr. A 30 years old, having clean driving Allow to rent
record car
2 Mr. B 30 years old, not having clean Not allow to
driving record rent car
Slide 51
Decision tables testing example 2
Credit card worked example.
If you are a new customer opening a credit card account,
you will get a 15% discount on all your purchases today.
If you are an existing customer and you hold a loyalty card
(thẻ khách hàng thân thiết), you get a 10% discount.
If you have a coupon (phiếu giảm giá), you can get 20% off
today (but it can't be used with the 'new customer'
discount).
Discount amounts are added, if applicable.

Slide 52
Decision tables testing example 2

Conditions R1 R2 R3 R4 R5 R6 R7 R8

New customer (15%) T T T T F F F F

Loyalty card (10%) T T F F T T F F

Coupon (20%) T F T F T F T F

Action

Discount (%) X X 20 15 30 10 20 0

X: Error message
R3: must review specification
Slide 53
Decision tables testing example 2

Conditions R1 R3 R4 R5 R6 R7 R8

New customer (15%) T T T F F F F

Loyalty card (10%) T F F T T F F

Coupon (20%) - T F T F T F

Action

Discount (%) X 20 15 30 10 20 0

Slide 54
Extending decision tables - 1

Entries can be more than just ‘true’ or ‘false’

completing table needs to be done carefully
rationalising becomes more important
Example
Code = 1, 2, or 3 1 1 1 1 2 2 2 2 3 3 3 3
Exp.date < now T T F F T T F F T T F F
Class A product T F T F T F T F T F T F

Slide 55
Extending decision tables - 2
Decision table with multiple actions
Decision tables may specify more than one action for each
rule
Example
Rule 1 Rule 2 Rule 3 Rule 4
Conditions
Condition-1 Yes Yes No No
Condition-2 Yes No Yes No
Actions
Action-1 Do X Do Y Do X Do Z
Action-2 Do A Do B Do B Do B

Slide 56
Extending decision tables - 3
A decision table with non-binary conditions
Rule 1 Rule 2 Rule 3 Rule 4
Conditions
Condition-1 0–1 1–10 10–100 100–1000
Condition-2 <5 5 6 or 7 >7
Actions
Action-1 Do X Do Y Do X Do Z
Action-2 Do A Do B Do B Do B

Test Case ID Condition-1 Condition-2 Expected Result

TC1 0 3 Do X / Do A
TC2 5 5 Do Y / Do B
TC3 50 7 Do X / Do B
TC4 500 10 Do Z / Do B
Slide 57
Decision tables testing exercise
Scenario:
If you hold an 'over 60s' rail card, you get a 34% discount on
whatever ticket you buy.
If you are traveling with a child (under 16), you can get a 50%
discount on any ticket if you hold a family rail card,
otherwise you get a 10% discount.
You can only hold one type of rail card.
Produce a decision table showing all the combinations of
fare types and resulting discounts and derive test cases from
the decision table.

Slide 58
Solution - decision table
Conditions R1 R2 R3 R4 R5 R6 R7 R8
'over 60s' rail card? T T T T F F F F
with a child? T T F F T T F F
family rail card? T F T F T F T F
Action

discount 50% 34% 34% 34% 50% 10% 0% 0%

Conditions R1 R2 R3 R5 R6 R7
'over 60s' rail card? T T T F F F
with a child? T - F T T F
family rail card? T F T T F -
Action
discount 50% 34% 34% 50% 10% 0%
Slide 59
Solution – test cases
# Input Expected outcome
1 John, with 'over 60s' rail card and 50% discount for both tickets
family rail card, traveling with his
son (age 10)
2 Rogers, with 'over 60s', traveling 34% discount (for Rogers only)
with his wife
3 Tom, with 'over 60s' rail card and 34% discount
family rail card
4 Anna, with family rail card, 50% for both tickets
traveling with her baby
5 Betty, no rail card, traveling with 10% discount for both tickets
his 5-year-old niece
6 Henry, no rail card No discount

Slide 60
Applicability and Limitations
Decision table testing can be used whenever the system
must implement complex business rules when these rules
can be represented as a combination of conditions and
when these conditions have discrete actions associated
with them

Slide 61
State transition testing
This technique is helpful where you need to test differrent
system transitions
system where you get a different output for the same input,
depending on current state and past state
Based on state transition diagram

Slide 62
State transition diagram
Called State Chart or Graph
There are four main components of the graph

1) states software may occupy Start

2) transitions from one state to another

3) events that cause transition PIN not OK

eat
4) actions that result from transition card

Slide 63
Example
Entering a PIN to a bank account

Slide 64
 State transition diagram
Example State diagram for enter PIN

Start eat
card

card inserted enter PIN PIN not OK PIN not OK PIN not OK
Wait
for 1st try 2nd 3rd
PIN try try
PIN OK PIN OK
PIN OK
access
to
account

Slide 65
Creating test cases
Test conditions can be derived from the state graph in
various ways
Four different levels of coverage
state coverage
event coverage
path coverage
transition coverage

Slide 66
 State coverage
All states are visited at least once
Generally this is a weak level of test coverage
1 2
Start eat
card

card inserted enter PIN PIN not OK PIN not OK PIN not OK
Wait
for 1st try 2nd 3rd
PIN try try
PIN OK PIN OK
PIN OK
access
to
account
Slide 67
 Event coverage
All events are triggered at least once
Also is a weak level of coverage
1

Start eat
card

card inserted enter PIN PIN not OK PIN not OK PIN not OK
Wait
for 1st try 2nd 3rd
PIN try try
PIN OK PIN OK
PIN OK
access
to
account
Slide 68
Path coverage
All paths are executed at least once
The strongest level of coverage but may not be feasible
If the state transition diagram has loops, then the number
of possible paths may be infinite
e.g. given a system with two states, A and B, where A
transitions to B and B transitions to A. A few of the possible
paths are:

A→B
A→B→A
A→B→A→B→A→B
A→B→A→B→A→B→A
...
and so on forever.
Slide 69
 Transition coverage
All transitions are exercised at least once
Good level of coverage without generating large
numbers of tests
eat
Generally the one recommended
Start card

card
inserted enter PIN PIN not OK PIN not OK PIN not OK
Wait
for 1st try 2nd 3rd
PIN try try
PIN OK
PIN OK
access
PIN OK to
account Slide 70
Testing for invalid transitions
Using state table as an intermediate step
list all the possible states and all the possible events: states
are listed on the left side of the table, events that cause
them on the top (or vice versa)
each cell represents the state system will move to when the
corresponding event occurs
 thiswill include events that are not expected to happen in
certain states  invalid transitions from that state
Test cases are usually derived from the state table
depending on the system risk, create test cases for some or
all of the invalid state/event pairs to make sure the system
has not implemented invalid paths

Slide 71
State table example
Example of state table for the PIN entering

Events Enter valid Enter invalid

Insert card PIN PIN
States
S1) Start S2 - -
S2) 1st try - S5 S3
S3) 2nd try - S5 S4
S4) 3rd try - S5 S6
S5) Access account - - -
S6) Eat card S1 (for new card) - -

Slide 72
Design test cases
# Test Step/Substep Expected Result
In all cases, the ATM starts in the
waiting for PIN
1 1. Insert card Prompts for PIN
2. Enter valid PIN Access account
2 1. Insert card Prompts for PIN
2. Enter invalid PIN (1st try) Reprompts for PIN
3. Enter valid PIN Access account
3 ... ...

Slide 73
State transition testing exercise
Scenario: A website shopping basket starts out as empty. As
purchases are selected, they are added to the shopping
basket. Items can also be removed from the shopping basket.
When the customer decides to check out, a summary of the
items in the basket and the total cost are shown. If the
contents and price are OK, then you leave the summary
display and go to the payment system. Otherwise you go
back to shopping (so you can remove items if you want).
a. Produce a state diagram showing the different states and
transitions. Define a test, in terms of the sequence of states,
to cover all transitions.
b. Produce a state table. Give an example test for an invalid
transition.
Slide 74
 Solution - State diagram
Design a test cover all transitions?
basket
empty add item
(S1)
add item
remove
last item
Shopping check out
(S2)

remove item
summary OK
not OK & cost (S3)

Payment
(S4) Slide 75
 Solution - State table

Add item Remove Remove Check Not OK OK

item last item out
S1) Empty S2 - - - -
-
S2) Shopping
S2 S2 S1 S3 - -
S3) Summary
S4) Payment - - - - S2 S4
- - - - - -

A test for an invalid transition?

• try to remove an item from the empty shopping basket
• attempt to add an item from the summary and cost state

Slide 76
Applicability and Limitations
State-Transition diagrams are not applicable when the
system has no state or does not need to respond to real-
time events from outside of the system

Slide 77
Use case testing
A technique that helps identify test cases that cover the
whole system, on a transaction by transaction, from start
to finish
Use case is a sequence of steps that describe the
interactions between the actor and the system in order to
achieve a specific task
At least one test case for the main success scenario
At least one test case for each extension
Used widely in developing tests at system or acceptance
level

Slide 78
Use case testing
Use case component Description
Step Description
1 A: Inserts card
Main success scenario 2 S: Validates card and ask for PIN
A: Actor 3 A: Enters PIN
S: System
4 S: Validates PIN
5 S: Allows access to account
2a Card not valid
S: Displays message and rejects card

4a PIN not valid

Extension S: Displays message and ask for re-try
(twice)
4b PIN invalid 3 times
S: Eats card and exit Slide 79
Black-box techniques - Advantages
More effective on larger units of code than glass box
testing
Tester needs no knowledge of implementation, including
specific programming languages
Tester and programmer are independent of each other
Tests are done from a user's point of view
Will help to expose any ambiguities or inconsistencies in
the specifications
Test cases can be designed as soon as the specifications
are complete

Slide 80
Black-box techniques - Disadvantages
Only a small number of possible inputs can actually be
tested
May leave many program paths untested
Without clear and concise specifications, test cases are
hard to design
There may be unnecessary repetition of test inputs if the
tester is not informed of test cases the programmer has
already tried

Slide 81
Learn more
Pairwise testing
Domain analysis testing

Slide 82
 4
3
Manageme 5 Standards
1 2 Life cycle Infrastructu
nt and
Overview components re
component Organizing
components
6 8 Test
7 Dynamic 9s
Static manageme
testing Tools
tesing nt

Dynamic techniques
(cont.)
References
Dorothy Grahamet, Erik van Veenendaal, Isabel Evans, Rex
Black. Foundations of software testing: ISTQB Certification

Lee Copeland (2004). A Practitioner's Guide to Software

Test Design. Artech House. ISBN:158053791x

Slide 90
 1 2 3 4 5

6 7 8 9

Contents
Dynamic techniques
Test condition – Test case – Test
procedure
Black-box techniques
White-box techniques
Experience-based techniques
Choosing test techniques
White-box techniques
Structure-based approach
based on the internal structure of a component or system
also called glass-box techniques

What we may be interested in structures?

component level: program structures
integration level: the way components
interact with others
system level: how user will interact with
the system

Slide 92
White-box techniques
Some techniques
control flow testing
 statement testing
 decision testing

 condition testing

 decision/condition testing

 multiple condition testing

 path testing

data flow testing

Slide 93
Control-flow graph
Flow graphs for control structures

Slide 94
Control-flow graph - Example

Two test cases:

 one between £1,000 and £10,000
 one higher than £10,000

Slide 95
Statement testing (Level 1)
A test design technique in which test cases are
designed to execute statements [ISTQB Glossary]
Statement coverage
the percentage of executable statements exercised by a
test suite ?
=

black-box testing: only 60% to 75% statement coverage

typical ad hoc testing achieves 30%
How to get 100% statement coverage?
Find out the shortest number of paths which all the
nodes will be covered

Slide 96
 Statement coverage example 1
1
1 read(a)
2 IF a > 6 2 a>6
3 THEN T
F
4 b=a 3
5 ENDIF
print b 4
ow many test cases to get 100% statement coverage?
5
# Condition Input Line number excuted Expected result
1 a>6 7 1,2,3,4,5 7 (not from code)

Slide 97
Statement coverage example 2

A program for calculating the mean

and maximum of three integers.
a. How many test cases will you
need to achieve 100% statement
coverage?
b. What will the test cases be?

Slide 98
Statement coverage example 2 - Solution

1-4

A>B
5
F T

B>C A>C
11 6
T F T
F

12 9 7
14

15
Slide 99
Statement coverage example 2 - Solution
Design test case

# Test condition Input Line number Expected result

A B C executed
Max Mean

1 A>B and A>C 5 2 3 1-4,5,6,7,15 5 3.33

2 A>B and A<=C 5 2 7 1-4,5,6,9,15 7 4.66
3 A<=B and B>C 5 7 4 1-4,5,11,12,15 7 5.33
4 A<=B and B<=C 5 6 8 1-4,5,11,14,15 8 6.33

Slide
100
Statement coverage exercise
A program evaluates grades for students:
 If StudentScore<=39, print "Fail".
 If StudentScore between 39 and 60,
print “Pass”
 If StudentScore between 59 and 80,
print “Merit”
 If StudentScore>79, print “Distinction”
a. How many test cases will you need to
achieve 100% statement coverage?
Design test case.
b. Suppose we ran two test cases:
StudentScore = 50 and StudentScore = 30,
which lines of pseudo code will not be
exercised? How much is statement
coverage?

Slide
101
Statement coverage exercise: Solution

Slide
102
Statement coverage problems
Statement coverage can be achieved without branch
coverage
important cases may be missed

Slide
103
Decision testing (Level 2)
A test design technique in which test cases are designed to
execute decision outcomes [ISTQB Glossary]
decision: a logical expression which can be composed of
several logical operators like "or", "and", "xor"
decision outcome: each exit from a decision
 two or more possible decision outcomes False
?
IF A > 1 decision True

IF A > 1 AND X = 2
Known as 'Branch testing', 'Basis path testing'
Slide
104
Decision testing (cont’d)
Decision coverage
percentage of decision outcomes exercised
=
specification-based may achieve only 40% to 60% decision
coverage
typical ad hoc testing achieves 20%
100% decision coverage guarantees 100% statement
coverage, but not vice versa
How to get 100% decision corverage?
Find out the minimum number of paths which will ensure
covering of all the edges

Slide
105
Decision testing example 1
Read A
IF A > 0 THEN Read
IF A = 21 THEN
Print “Key” Yes Yes
ENDIF A>0 A=21
ENDIF No No
Print
Minimum tests to
3
achieve with decision
coverage: ____
# Cases Inputs Expected result
End
1 A>0(F) A=-5 No message
2 A>0(T) and A=21(F) A=10 No message
3 A>0(T) and A=21(T) A=21 Message “Key” Slide
106
Decision testing example 2

Read A Yes
Read A<0 Print
Read B
IF A < 0 THEN No
Print “A negative” Print
ELSE
Print “A positive” Yes
ENDIF Minimum tests to achieve B<0 Print
IF B < 0 THEN 2
with decision coverage:
No
_____
Print “B negative” Print
ELSE
Print “B positive”
ENDIF End
Slide
107
 Decision testing exercise 1

1 Read(CandidateAge) How many test cases for 100%

2 If CandidateAge < 18 decision coverage?
3 Then
4 Print (“Candidate is too young”)
5 Else
6 If CandidateAge > 30
7 Then
8 Print (“Candidate is too old”)
9 Else
10 Print(“Candidate may join Club 18–30”)
11 Endif
12 Endif
Slide
108
 Solution exercise 1

1 Read(CandidateAge)
2 If CandidateAge < 18
3 Then
4 Print (“Candidate is too young”)
5 Else
6 If CandidateAge > 30
7 Then
8 Print (“Candidate is too old”)
9 Else
10 Print(“Candidate may join Club 18–30”)
11 Endif CandidateAge<18
12 Endif CandidateAge>=18 and CandidateAge>30
CandidateAge>=18 and CandidateAge<=30
Slide
109
Decision testing exercise 2

a. How many test cases are

needed to achieve 100%
decision coverage?
b. If the test cases Time = 11 and
Time = 15 were input, what
level of decision coverage would
be achieved?

a. 3 test cases
b. 83%

Slide
110
Solution exercise 2

Slide
111
Decision testing exercise 3

What test case for 100% decision coverage?

Slide
112
Solution exercise 3

Slide
113
Test
Suppose you are developing a software unit that will convert a non-signed 16 bit
binary number (in string format) to a decimal integer. For example,
BinaryToDecimal(“0000000000001111”) = 15. Draw CFG for this function.

Slide
114
Decision testing problems
Some branching decisions in programs are made not
based on a single condition but on multiple conditions
Decision coverage does not ensure that all entry-exit paths
are executed
A compound predicate is treated as a single statement
If n clauses, 2n combinations, but only 2 are tested
Example

if (condition1 && (condition2 || function1()))

statement1;
else
statement2;
Slide
115
Condition testing (Level 3)
Design test cases based on Boolean sub-expression (BsE):
each condition to be evaluated as true and false at least
once
Condition coverage
=

Slide
116
Decision/Condition testing (Level 4)
Full condition coverage does not guarantee full decision
coverage
Example: if (x&&y)
{conditionedStatement;}
Using condition coverage, if we choose two test cases
(x=TRUE, y=FALSE and x=FALSE, y=TRUE), the
conditionedStatement will never be executed

Decision/Condition testing: Test cases are created for

every condition and every decision

Slide
117
Multiple condition testing (Level 5)
Known as ‘condition combination testing'
Requiring 2n test cases to achieve 100% coverage of a
decision containing n boolean operands
Example: A or (B and C)
Case A B C
1 FALSE FALSE FALSE
2 FALSE FALSE TRUE
3 FALSE TRUE FALSE
4 FALSE TRUE TRUE
5 TRUE FALSE FALSE
6 TRUE FALSE TRUE
7 TRUE TRUE FALSE
8 TRUE TRUE TRUE
Slide
118
Path testing (Level 6)
Design test cases based on what paths which should be
exercised
Path coverage
=

Slide
119
Paths through code 12 34

1 12 12 3
2 ?

? ? ? ?

Slide
120
Paths through code with loops

1 2 3 4 5 6 7 8 ….

for as many times as it

is possible to go round
?
the loop (this can be
unlimited, i.e. infinite)

Slide
121
White box techniques - Advantages
It permits direct checking of processing paths and
algorithms
It provides line coverage follow-up that delivers lists of
lines of code that have not yet been executed
It is capable of testing the quality of coding work

Slide
122
White box techniques - Disadvantages
It requires vast resources, much above those required for
black box testing
It cannot test the performance of software in terms of
availability, reliability, stress, etc.
The tester must have sufficient programming skill to
understand the code and its control flow
Control flow testing can be very time consuming because
of all the modules and basis paths that comprise a system

Slide
123
Unit Testing
In software engineering, unit testing is a test (often
automated) that validates that individual units of source
code are working properly.
A unit is the smallest testable part of an application. In
procedural programming a unit may be an individual
program, function, procedure, etc., while in object-
oriented programming, the smallest unit is a method,
which may belong to a base / super class, abstract class or
derived / child class.

Slide
124
Unit Testing

Slide
125
 1 2 3 4 5

6 7 8 9

Contents
Dynamic techniques
Test condition – Test case – Test
procedure
Black-box techniques
White-box techniques
Experience-based techniques
Choosing test techniques
Non-systematic test techniques

Based on a person's knowledge, experience,

imagination and intuition
Some techniques
error guessing
exploratory testing

It is true that testing should be rigorous,

thorough and systematic

This is not all there is to testing

Slide
127
Error guessing

No rules, no script

Think of situations in which the software may
not be able to cope
division by zero
blank (or no) input
empty files
wrong kind of data (e.g. alphabetic characters
where numeric are required)...
After systematic techniques have been used
Supplements
Not goodsystematic
Notaagood approach
approachto techniques
tostart
starttesting
testingwith
with
Slide
128
Exploratory testing
“A style of testing in which you
explore the software while
simultaneously designing and
executing tests, using feedbacks
from the last test to inform the
next.” (Elisabeth Hendrickson)

Exploratory testing as 'an

interactive process of
simultaneous learning, test
This testing helps design, and test execution‘ (James
improving quality Bach)

Slide
129
 1 2 3 4 5

6 7 8 9

Contents
Dynamic techniques
Test condition – Test case – Test
procedure
Black-box techniques
White-box techniques
Experience-based techniques
Choosing test techniques
Choosing test techniques
Each technique is good for certain things, and not as good
for other things
The best testing technique is no single testing technique:
each testing technique is good at finding one specific class
of defect
How can we choose the most appropriate testing
techniques to use? - Depend on internal and external
factors

Slide
131
Choosing test techniques (cont’d)
Internal factors
models used
tester knowledge or experience
test objective
documentation
life cycle model

Slide
132
Choosing test techniques (cont’d)
External factors
risk
customer or contractual requirements
type of system
time and budget
regulatory requirements

Slide
133