Test Design Techniques

1. Test Design Techniques

•September 2014

2.

Agenda
• Static techniques
• Dynamic Techniques
Structure-Based
Experience-Based
Specification-Based
• Choosing a Test Design Technique
• Homework
2

3.

Trainings’ Content
Test Analysis
Test Design Techniques
Selection
Test Items Designing
3

4.

Test Design Techniques
Categories
Static: Static techniques
test software without
executing it
Dynamic: Testing that
involves the execution of
the
software
of
a
component or system.
4

5.

Static Techniques
Static Techniques
Informal Reviews
Static Analysis
Walkthroughs
Inspections
Technical Reviews
Control Flow
Structure
Data Flow
Structure
5

6.

Specification-Based Techniques
These are also called whitebox or structural techniques.
Structure – Based
Statement
Dynamic
Techniques
Experience – Based
Error Guessing
Decision
Exploratory
Testing
Condition
Multiple
Condition
Testing, either functional or
non-functional, without
reference to the internal
structure of the component or
system. These are also called
black-box techniques.
Specification-Based
Equivalence
Partitioning
Boundary
Values
Analysis
Decision
Tables
State
Transition
Use Case
Testing
6

7.

Structure-Based Techniques
Procedure to derive and/or
select test cases based on an
analysis of the internal structure
of a component or system. These
are also called while-box
techniques.
Structure – Based
Statement
Dynamic
Techniques
Experience – Based
Error Guessing
Decision
Exploratory
Testing
Condition
Multiple
Condition
SpecificationBased
Equivalence
Partitioning
Boundary
Values
Analysis
Decision
Tables
Use Case
Testing
State
Transition
7

8.

Experience-Based Techniques
.
Dynamic
Techniques
Structure – Based
Statement
Experience – Based
Equivalence
Partitioning
Error Guessing
Exploratory
Testing
Decision
Condition
Multiple
Condition
Specification-Based
Procedure to derive and/or
select test cases based
on the tester’s experience,
knowledge and intuition.
Boundary
Values
Analysis
Decision
Tables
Use Case
Testing
State
Transition
8

9. Specification-Based Techniques

10.

Equivalence Partitioning
Equivalence partitioning (EP) – A black box test design technique in which test cases
are designed to execute representatives from equivalence partitions.
Idea: Divide (i.e. to partition) a set of test conditions into groups or sets that can be
considered the same (i.e. the system should handle them equivalently), hence
equivalence partitioning. In principle test cases are designed to cover each partition at
least once.
Example: Bank represents new deposit program for corporate clients. According to
the program client has ability to get different %, based on amount of deposited
money. Minimum which can be deposited in $1, maximum is – $999. If client deposits
less than $500 it will have 5% of interests. In case the amount of deposited money is
$500 and higher, then client gets on 10% of interests more.
10

11.

Boundary Values Analysis
Boundary value analysis (BVA): A black box test design technique in which test
cases are designed based on boundary values.
Boundary value is an input value or output value which is on the edge of an
equivalence partition or at the smallest incremental distance on either side of an edge,
for example the minimum or maximum value of a range.
Idea: Divide test conditions into sets and test the boundaries between these sets.
Tests should be written to cover each boundary value.
Example: Bank represents new deposit program for corporate clients. According to
the program client has ability to get different %, based on amount of deposited
money. Minimum which can be deposited in $1, maximum is – $999. If client deposits
less than $500 it will have 5% of interests. In case the amount of deposited money is
$500 and higher, then client gets on 10% of interests more.
11

12.

Decision Tables
Decision table – A table showing combinations of inputs and/or stimuli (causes) with
their associated outputs and/or actions (effects), which can be used to design test
cases.
Idea: Divide test conditions into constraints, which could get positive or negative
meanings, and rules which identify output based on values of conditions. While
analyzing each possible variant of positive and negative meanings identify output or
set of outputs for each variant based on the rules. Only combinations of these positive
and negative meanings, which uniquely identify decisions that are made, should be
covered by tests.
Example: If you hold an 'over 60s' rail card, you get a 34% discount on whatever ticket you buy.
If you hold family rail card and you are traveling with a child (under 16), you can get a 50%
discount on any ticket. If you are traveling with a child (under 16), but do not have family rail card,
you can get a 10% discount. You can use only one type of rail card.
12

13.

Decision Tables
- 'over 60s' rail card – 34%
- family rail card and traveling with a child – 50%
- traveling with a child, but do not have family rail card – 10%
- only one type of rail card can be used
13

14.

State Transition
State transition testing – A black box test design technique in which test cases are
designed to execute valid and invalid state transitions.
State transition – A transition between two states of a component or system.
Idea: Design diagram that shows the events that cause a change from one state to
another. Tests should cover each path starting from the longest state combination.
Example: Client of the bank would like to take money from bank account using cash
machine. To get money he should enter valid Personal Identity Number (PIN). In case
of 3 invalid tries, cash machine eats the card.
Card inserted
Start
Wait for
Pin
Eat card
Enter
Pin
NOT Ok
1st try
Pin
NOT Ok
Pin
NOT Ok
2nd try
Access
to
account
3rd try
Pin Ok
Pin Ok
Pin Ok
14

15.

Use Case Testing
Use Case testing - is a technique that helps us identify test cases that exercise the whole
system on a transaction by transaction basis from start to finish.
Use cases describe the process flows through a system based on its most likely use
This makes the test cases derived from use cases particularly good for finding
defects in the real-world use of the system
Each use case usually has a mainstream (or most likely) scenario and sometimes
additional alternative branches (covering, for example, special cases or exceptional
conditions).
Each use case must specify any preconditions that need to be met for the use case
to work.
Use cases must also specify post conditions that are observable results and a
description of the final state of the system after the use case has been executed
successfully.
15

16.

Choosing A Test Design Technique
Which technique is best? This is the wrong question!
Each technique is good for certain things, and not as good for other things. Some techniques are
more applicable to certain situations and test levels, others are applicable to all test levels.
The internal factors that influence the decision about which technique to use are:
Tester knowledge and experience
Expected defects
Test objectives
Documentation
Life cycle model
The external factors that influence the decision about which technique to use are:
Risks
Customer and contractual requirements
System type
Regulatory requirements
Time and budget
16

17.

Homework
1. Practice in using Dynamic Test Design Techniques.
Test_Design_Tech
niques_V1.doc
Test_Design_Tech
niques_V2.doc
Test_Design_Tech
niques_V3.doc
Test_Design_Tech
niques_V4.doc
17

18. Example

19.

Requirements: User Registration Page
Business Value: I, as an Administrator user, should be able to create a simple user account to log in application.
Functional Requirements: ‘User Registration’ page should contain three fields ‘User Name’, ‘Password’, ‘Confirm Password’ and
two buttons – ‘Save’ and ‘Cancel’.
Mock up:
‘User Name’ field is limited by 10 symbols and should contain letters of
Latin alphabet only. ‘User Name’ field is empty by default. User Name
should be unique in the system.
‘Password’ field should be no less than 4 symbols long and should include
only numbers and letters of Latin alphabet only. ‘Password’ field is empty
by default.
‘Confirm Password’ field should be equal to ‘Password’. ‘Confirm
Password’ field is empty by default.
‘Cancel’ button cancels account creation and closes ‘User Registration’
page.
‘Save’ button validates data entered into fields on ‘User Registration’
page and creates user account if entered data are correct; or shows error
dialogs if validation fails. Validation should be provided in following order:
User Name, Password, and Confirm Password.
19

20.

Requirements: Error Messages
20

21.

Applying State Transition Technique
‘User Name’ field is empty by default. ‘Password’ field is empty by default. ‘Confirm Password’ field is empty
by default.
‘Cancel’ button cancels account creation and closes ‘User Registration’ page.
‘Save’ button creates user account if entered data are correct.
Default
state
Click ‘Cancel’ button
State on
Cancel
action
Click ‘Save’ button
State on
Save
action
21

22.

Applying State Transition Technique
Requirement Test Name
Description
Default values
Default values on the ‘User
Registration’ page
This test verifies that all fields on ‘User Registration’
page are blank by default
‘Save’ button
functionality
Creating new user account
and save
This test verifies that user account could be created if
all fields on ‘User Registration’ page are filled with
correct data; and ‘User Registration’ page is closed on
save action
‘Cancel’ button
functionality
Creating new user account
and cancel
This test verifies that user account is not created after
filling in fields on ‘User Registration’ page and
canceling; and ‘User Registration’ page is closed on
cancel action
22

23.

Applying State Transition Technique
‘Save’ button validates data entered into fields on ‘User Registration’ page and creates user account if entered
data are correct; or shows error dialogs if validation fails. Validation should be provided in following order: User
Name, Password, and Confirm Password.
Confirm Password is not OK
Password is not OK
Click ‘Save’
button
Validate
Default
User
state
Name
User name
is OK
Click ‘Save’
button
Validate
Password
Password
is OK State onValidate
Confirm
Password is OK
Save Confirm
actionPassword
User name is not OK
23

24.

Applying BVA and EP Techniques
‘User Name’ field is limited by 10 symbols.
BVA:
EP:
00
1
10
11
Invalid Class
Valid Class
Invalid Class
only 0
1-10
11 and bigger
‘User Name’ field should contain letters of Latin alphabet only.
Letters of Latin Alphabet
Numbers
Special Characters
Valid class
Invalid class
Invalid class
A-Z and a-z
0-9
@, !, #, $, %, ^, &, *, (, ), >, <, /, \,
|, }, {, ], [, ~,`, ‘, “, :, ;, etc.
User Name should be unique in the system.
24

25.

Test Item “User Registration”
Requirement Test Name
Description
‘User Name’
field validation
This test verifies that error dialog appears while save
action if user name length is too long:
Error dialog on saving user
account with too long user
name
1)boundary length – 11 characters
2)restricted length – more than 11 characters
Error dialog on saving user
account with blank ‘User
Name’ field
This test verifies that error dialog appears while save
action if ‘User Name’ field is blank
Verify boundary length for
user name
This test verifies that user account having user name
with boundary length 1 or 10 could be created
Error dialog on saving user
account with wrong user
name
This test verifies that error dialog appears while save
action if ‘User Name’ field include: 1)special symbols;
2)numbers; 3)both
Error dialog on saving already This test verifies that error dialog appears while save
existing user account
action if user already exists in the system
25

26.

Test Item “User Registration”
Requirement Test Name
Description
‘Password’ field Error dialog on saving user
validation
account with too short
password
This test verifies that error dialog appears while save
action if password length is too short: 1)boundary
length – 3 characters
2)restricted length – less than 3 characters
‘Confirm
Password’ field
validation
Error dialog on saving user
account with blank
‘Password’ field
This test verifies that error dialog appears while save
action if password is blank
Verify boundary length for
password
This test verifies that user account having password
with boundary length 4 could be created
Error dialog on saving user
account with incorrect
password
This test verifies that error dialog appears while save
action if ‘Password’ field includes special symbols
Error dialog on saving user
account with unequal
password and confirm
password
This test verifies that error dialog appears while save
action if: 1)’Confirm Password’ field is blank
2)password and confirm password do not match
26

27.

Homework
Create Test-items for presented requirements.
Use Test-design techniques.
AddPatient.docx

28. Thank you

US OFFICES
Austin, TX
Fort Myers, FL
Boston, MA
Newport Beach, CA
Salt Lake City, UT
EUROPE OFFICES
United Kingdom
Germany
The Netherlands
Ukraine
Bulgaria
EMAIL
[email protected]
 
WEBSITE:
www.softserveinc.com
USA TELEPHONE
Toll-Free: 866.687.3588
Office: 239.690.3111
UK TELEPHONE
Tel: 0207.544.8414
GERMAN TELEPHONE
Tel: 0692.602.5857