Test Design Techniques: Istqb Certified Tester - Foundation Level

Test Design Techniques
ISTQB Certified Tester

- Foundation Level -
Software Quality Lab www.software-quality-lab.com

Content
The Test Development Process

Categories of Test Design
Techniques
Specification-based Techniques
(Black-box Techniques)
Structure-based Techniques
(White-box Techniques)
Experience-based Techniques
Choosing Test Techniques
Software Quality Lab www.software-quality-lab.com -2-

Terms
Traceability Test design techniques

Black-box
Test design specification Use case testing
Equivalence partitioning
Test case specification Decision table testing
Boundary value analysis
Test procedure specification State transition testing
White-box
Test script Statement coverage
Code coverage
Specification-based Decision coverage
Structure-based testing
techniques
Experience-based
Structure-based techniques Exploratory testing
Fault attack


Overview
no standards
The test development process
can be done in different ways, from
very informal to very formal.
informal
The level of formality depends on
the context of the testing
organization
industry
maturity of testing and development processes
structured and regulated
time constraints
people involved
formal

Test Documentation (IEEE 829)
Testbasis
Testbasis Test plan
Test basis
Test design
Test
Testbasis
Testbasis specification
condition
Test case Often replaced with

specification ISO/IEC/IEEE 29119-3
Test execution Test procedure

schedule specification
Test log Incident

report
Test summary
report

Test Basis
The test basis includes all documents from which the

requirements of a component or system can be inferred. The
documentation on which the test cases are based.
If a document can be amended only by way of formal
amendment procedure, then the test basis is called a frozen
test basis
[ISTQB glossary]

Test Condition
A test condition is defined as an item or event of a

component or system that could be verified by one or more
test cases, e.g., a function, transaction, quality attribute or
structural element.
[ISTQB glossary]
The test conditions are identified by analyzing the test basis

Establishing traceability from test cases to test conditions and
further till requirements makes sense
Tracebility enables to identify the interrelated tests
impact analysis due to changed requirements
determining requirements coverage

Test Case Development Process
Test Plan (1)
Testbasis
Testbasis
Test basis Test plan The test plan is the document
describing the scope, approach,
Test design
Test
Testbasis
resources and schedule of intended
condition
test activities.
Test case [after IEEE 829]
specification

Test log Incident

report
Test summary
report

Test Plan (2)
Contents
Testbasis
Testbasis Test plan
Test basis
1. Test Plan Identifier
2. Introduction
Test
Test design 3. Test items
Testbasis
Testbasis specification 4. Test Conditions to be Tested
condition
(performance attributes)
Test case 5. Test Conditions not to be Tested

specification 6. Test Strategy (Test Approach)
7. Item pass/fail Criteria
8. Suspension Criteria and
Test execution Test procedure Resumption Requirements
9. Test Documentation
10. Test Activities
11. Test Environment
Test log Incident
report
12. Responsibilities
13. Staff, Practice, Training
14. Schedule
Test summary 15. Risk Management
report
16. Approval
17. Glossary
Software Quality Lab www.software-quality-lab.com - 10 -
Test Design Specification (1)
Testbasis
Testbasis
Test basis
Test plan
The test design specification is a
document specifying the test
Test
Testbasis
Testbasis
Test design
specification
conditions (coverage items) for a test
condition
item, the detailed test approach and
Test case
specification
identifying the associated high-level
test cases.
[after IEEE 829]
Test log Incident

report
Test summary
report

Test Design Specification (2)
Testbasis Test plan Contents

Testbasis
Test basis
1. Test design specification identifier
2. Test conditions to be tested
Test
Testbasis Test design 3. Approach refinements
Testbasis
condition specification
4. Reference to test case specifications
5. Pass/fail criteria
Test case
specification

Test log Incident

report
Test summary
report

Test Case Specification (1)
Testbasis
Testbasis
Test basis
Test plan
The test case specification is a
document specifying a set of test
Test design
Test
Testbasis
cases (objective, inputs, test actions,
condition
expected results, and execution
Test case preconditions) for a test item.
specification [after IEEE 829]

Test log Incident

report
Test summary
report

Test Case Specification (2)
Testbasis
Test basis
1. Test case specification identifier
2. Test items
Test design
Test
Testbasis
Testbasis 3. Input values
specification
condition 4. Expected results
5. Environment
Test case
6. Special procedural requirements*)
specification
7. Intercase dependencies

Test log Incident

report
Test summary
report
*) e.g. special performance specifications

Test Procedure Specification (1)
Testbasis
Testbasis
Test basis
Test plan
The test procedure specification is
a document specifying a sequence of
Test design
Test
Testbasis
actions for the execution of a test.
condition
Test case Also known as test script or manual

specification test script
[after IEEE 829]
Test execution Test

schedule procedure
specification
Test log Incident

report
Test summary
report

Testbasis
Testbasis
Test basis
Test plan
The manual test script describes a
manually executable series of test
Test design
Test
Testbasis
actions.
condition
Test case The test script describes the

specification automatically (with the help of a
Test
testing tool) executable series of a
Test execution
schedule procedure test.
specification [ISTQB]
Test log Incident

report
Test summary
report

Testbasis
Testbasis
Test basis
Test plan The test procedure specification
describes how test cases are to be
Test design
Test
Testbasis
Testbasis specification executed
condition
preconditions before starting the test case
Test case
specification technical and logical dependencies
prioritization and risk in the sequence
Test execution Test
procedure
how the test case has to be executed by the
schedule
specification tester manually
should also be usable without much
Test log Incident background knowledge
report
Test summary
report

Testbasis
Test basis
1. Test procedure specification identifier
2. Test objective
Test design
Test
Testbasis
Testbasis 3. Special requirements
specification
condition (e.g. preconditions, knowledge or special
requirements on the test environment)
Test case 4. Procedures steps
specification Log
Set up
Test execution Test Start
schedule procedure Proceed
specification Measure
Shut down
Test log Incident Restart
report Stop
Wrap up
Test summary Contingencies
report

Test Execution Schedule (1)
Testbasis
Testbasis
Test basis
Test plan
The test execution schedule is a
scheme for the execution of test
Test design
Test
Testbasis
procedures.
condition
Test case The test procedures are included in

specification the test execution schedule in their
Test context and in the order in which they
Test execution
schedule
procedure need to be executed
specification [ISTQB glossary]
Test log Incident

report
Test summary
report

Test Execution Schedule (2)
Testbasis
Testbasis
Test basis
Test plan The test execution schedule defines
when and by whom they will be executed.
Test design
Test
Testbasis
Testbasis
condition
specification Takes factors into account such a:
regression testing
Test case
specification prioritization
logical dependencies
Test
Test execution procedure
Test log Incident

report
Test summary
report

Characteristics of a Good Test Case
What characterizes a well-specified test?

repeatability
delivers reproducible results
expected test result is already known before test execution (test oracle)
clear transparent traceability back to the requirements
pursues a clear test objective
tests a clearly defined delimitable system/subsystem/component
important for limitation in defect fixing
Tests exactly ONE test condition if possible

Exercise IV.1
Specify enough test cases to cover

all the possibilities of an expense
calculation that are defined in the
table listed in the practice materials.

Exercise IV.2 (opt.)
Create a test case Sell pet for the

Java Pet Store.

Categories of Test Design Techniques

Dynamic Testing
Testing
Static Dynamic
Review Analysis
Informal Data flow Specification-based test

review analysis (black-box testing)
Walkthrough
Control flow Structure-based test
analysis (white-box testing)
Technical
review
Metrics Experience-based testing
Inspection

The purpose is to identify test conditions,

test cases and test data.
A classic distinction is made between two
approaches
black-box test design techniques
(specification-based techniques)
PoC: Point of Control
PoO: Point of Observation white-box test design techniques
(structure-based techniques)
Both can also be combined with or

supplemented by experience-based test
design techniques.

Black-box Test Design Techniques
The black-box test design technique

is a procedure to derive and/or select
test cases.
It is based on an analysis of the
functional or non-functional
PoO: Point of Observation requirements (specifications) of a
component or system.
Boundary value analysis The internal structure is not taken into
Decision table testing account.
State transition testing [ISTQB glossary]
Use case testing


White-box Test Design Techniques
The white-box test design technique

is a procedure to derive and/or select
test cases.
It is based on the internal structure of a
component or system.
[ISTQB glossary]
PoO: Point of Observation
Statement coverage
Decision coverage
Single condition coverage
Multiple condition coverage
Path coverage


Specification-based Techniques
(Black-box Techniques)

Black-box Technique
Exercise IV.3
Inputs
3 integer values that are interpreted as the length of
the sides of a triangle (a, b, c)
Output a b
scalene c a b
isosceles abc
a b scalene
equilateral c
c a=bc
a=b=c isosceles
equilateral
Which test cases would you use to test

this program in order to find as many
failures as possible?

Black-box Technique
Testing of all possible Inputs
This could be the procedure call:

string triangleType(int a, int b, int c)
4.294.967.296 x 4.294.967.296 x 4.294.967.296 = 7,9228162511028
All possible combinations of input

values can not be tested.
So find few good test values.
3 integer (int) values representing the 3 sides of a triangle are passed. A text (string) is returned, telling
if this is a special type of triangle or if the values are invalid.

Black-box Technique
Equivalence Class
An equivalence class (equivalence partition) is a portion of an

input or output domain for which the behavior of a component
or system
is assumed to be the same,
based on the given specification.
[ISTQB glossary]
Equivalence classes can be derived for valid or invalid data/results

More classes can be derived for
Output data
Internal values
Time-related values (e.g. prior to and after an event)
Interface parameters

Black-box Technique
Equivalence Partitioning (1)

Black-box Technique
1 Factor: Consisting of
3 parameters, only seen in
connection they determine
the output.
Base class:
equivalence class derived from
input/output data
Represen-
tatives

Black-box Technique
Example with 2 parameters

= 2 sets of equivalence classes
Sorting a list
Any list of integral values shall be sorted ascending or descending.
{list}
{sorted list}
Black-Box
true/false
ascending/
descending
1st parameter: any list of integral values

2nd parameter: trigger for ascending/descending sort

Black-box Technique
2 3
determine equivalence classes find representatives
1 4 Compose high-level
find parameters tests: take one
equivalence class from
each factor.
Pay attention:
Combine valid classes
only with other valid
classes
Combine one invalid
class only with other
valid classes
(prevents defect-masking)
Sort(one element, ascending)

5 Sort({0}, ascending)
Compose tests: take one
representative from each class. Sort(one element, descending)
Sort({231-1}, descending)

Equivalence Partitioning
Approach In 5 Steps
1) Find the parameters, but also output-values, internal or time-

related values and interfaces
2) Compose equivalence classes (i.e. groups that let expect similar
predicted results; valid/invalid results)
3) Find representatives
4) Compose high-level tests: Take one equivalence class from
each parameter. Pay attention when combining:
Combine valid classes with other valid class
Combine one invalid class only with other valid classes (prevents defect-masking)
5) Compose tests: Take one representative for each class

Black-box Technique
Equivalence partitioning achieves a high probability of defect

discovery with a minimum number of test cases
Equivalence partitioning is applicable at all levels of testing.
Coverage can be defined by input and output values, both by the
users and by interfaces.

Black-box Technique
Exercise IV.4
Use the equivalence partitioning

technique for the example given in
the practice materials.

Black-box Technique
Boundary Value Analysis (1)
Programming errors are more common at the edges of the

defined areas (equivalence partitions).
lower boundary upper boundary
lb - 1 lb + 1 ub - 1 ub + 1
below the defined defined range above the defined

range range
Thereby the meaning of -1 and +1 depends on the data type

The predecessor/successor (e.g. in a list)
The next lower/higher value (e.g. numerical variables)
If the boundary value is inside the defined range only two values are needed

Black-box Technique
Boundary Value Analysis (2)
Definition of
requirements
Acceptance
testing Boundary value analysis can be applied
Functional
system design
System testing at all test levels
Technical Integration
It is easy to use
system design testing
It has a high defect-finding capability

Component Component
specification testing
Detailed specifications are helpful
Implementation
The technique is often considered an extension of
equivalence partitioning
Boundary value analysis can also be used as an
independent test design technique without prior

Black-box Technique
Exercise IV.5
Find the boundaries and perform a

boundary value analysis.

Black-box Technique
Cause-Effect Analysis
Causes, effects and their logical

Cause Effect
associations are identified by analyzing
the specification
Cause Effect
Elements of a cause-effect graph
Identity
If cause present - then effect
Cause
v Effect Negation
Cause
If cause not present - then effect
Or association
If cause A or cause B then effect
AND association
Cause
If cause A and cause B then effect
Effect
Cause

Black-box Technique
Example: ATM
ATM card Card

valid rejected

PIN
requested
PIN again
entry
correct

Card
retained
3rd PIN
entry
Cash
incorrect amount
requested
again

Cash Dispense
amount cash
available amount

Black-box Technique
Decision Table Testing (1)
Decision table testing is a good way to

Conditions Rules (Y/N) capture system requirements that contain
DTT logical conditions and complex rules for
Actions Action indicator
actions.
(X)
Based on the specification, the
conditions and actions of the system are
identified by text analysis or - even better
- by cause-effect analysis.

Black-box Technique
Conditions and actions are stated in

Conditions Rules (Y/N) such a way that they must be true or
DTT false (logical values).
(X)
Each column of the table corresponds to
a business rule.
The business rules defines a unique
combination of conditions which result in
the execution of the actions associated
with that rule.
The standard coverage is to have at least
one test case per column.

Black-box Technique
The strength of decision table testing is

Conditions Rules (Y/N) that it creates combinations of conditions
DTT that otherwise might not have been
exercised during testing.
(X)

Black-box Technique
Cause
How do I get from the cause-effect
Effect
graph to the decision table?
Starting from the effect (action), walk the
Cause
graph in the direction of the causes

(condition)
Each combination (rules) of causes
corresponds with one column in the decision
table
Conditions Rules (Y/N)
DTT

(X)

Black-box Technique
Depending on the specification,

the conditions can also be
nested constructs with AND, OR, XOR
and even negations
Rules
Conditions
# rules = 2 # conditions = 2 3 = 8
R1 R2 R3 R4 R5 R6 R7 R8
Condition 1 Y Y Y Y N N N N
Condition 2 Y Y N N Y Y N N
Condition 3 Y N Y N Y N Y N
Action 1 X X
Action 2 X X X
Action 3 X X
Action 4 X X X

Black-box Technique
Example: ATM
Test case 1 Test case 2 Test case 3 Test case 4 Test case 5
Decision table
(TC1) (TC2) (TC3) (TC4) (TC5)
ATM card valid No Yes Yes Yes Yes

Condition
PIN correct - No No Yes Yes
3 PIN entries - No Yes - -
Cash available - - - No Yes
Card rejected Yes - - - -
PIN requested again - Yes - - -

Action
Card retained - - Yes - -
Cash amount requested again - - - Yes -
Dispense case - - - - Yes

Black-box Technique
Example: Tringle (1)
Every column counts as 1 and is multiplied by 2 for each Dont

Care -
Counter = 2 # Dont Cares = 2 5 = 32 # rules = 2 # conditions = 2 6 = 64
R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11
a >= b + c Y N N N N N N N N N N
b >= a + c - Y N N N N N N N N N
c >= a + b - - Y N N N N N N N N
a=b - - - Y Y Y N Y N N N
b=c - - - Y Y N Y N Y N N
a=c - - - Y N Y Y N N Y N
Counter 32 16 8 1 1 1 1 1 1 1 1 counter = 64
no triangle X X X
equilateral X
isosceles X X X
scalene X
math. illogical X X X
simplification 1 simplification 2

Black-box Technique
Example: Triangle (2)
Simplifications
Deletion of mathematically illogical cases (e.g., a=b and b=c and a !=c)
Introduction of an ELSE branch for isosceles triangles
R8-
R1 R2 R3 R4 R5 R6 R7 R11
10
a >= b + c Y N N N N N N N E
b >= a + c - Y N N N N N N L
c >= a + b - - Y N N N N N S
a=b - - - Y Y Y N N E
b=c - - - Y Y N Y N
a=c - - - Y N Y Y N
no triangle X X X
equilateral X
isosceles X
scalene X
math. illogical X X X
simplification 1 simplification 2
Black-box Technique
Total counter greater than 2#conditions

Conditions Rules (Y/N) The system is overdefined
The combination of conditions and actions is described
DTT
identically more than once
Actions Action indicator The system is inconsistent
(X)
The combination of conditions and actions is described
in different ways more than once
Total counter lesser than 2#conditions

The system is not described completely
The two effects can even overlap!

Black-box Technique
Exercise IV.6 Pet Store
Extract all the conditions and actions

to create a decision table from the
continuous text provided in the
exercises.

Black-box Technique
State Transition Testing (1)
State transition testing is used when a

system exhibits different responses
depending on current conditions or
previous history (state).
Applications
embedded software (e.g. mobile phone, navigation
systems)
technical automation
modeling business processes having specific states
dialog-based processes

Black-box Technique
Event/
Action
Event/
Action
State transition testing is a black box
State State
test design technique in which test
cases are designed to execute valid
and invalid state transitions.
[ISTQB glossary]

Black-box Technique
State Transition Diagrams
Event/ Event/
State transition diagrams can be used
Action Action with reference to a system to show
State State
states
state changes (transitions) between states
Transition
events that trigger state changes
actions which may result from the transitions
The states of a system or test object are

separate, identifiable and finite in number

Black-box Technique
Example: State Transition Diagram
show show
add [height < max-1]
remove [height > 1]
initialize add
add [height = max-1]
Empty Filled Full

remove remove
delete [height = 1]
State transition
State State change Start state
Action
[condition]
Finish state

Black-box Technique
State Table
Event/
Action
Event/ A state table is a table that shows the
Action
State State
resulting state changes for each state
in combination with each possible event.
These may be both valid and invalid
transitions.
[ISTQB glossary]

Black-box Technique
Example: State Table
Show Show
Add [height < max-1]
Remove [height > 1]
Initialize Add
Add [height = max-1]
S1: empty S2: filled S3: full
Remove Remove
Delete [height = 1]
State table State transitions

(example stack of paper) 0 1 2 3 4 5 6 7 8 9
SS start state S1 - - - - - - - - -
S1 empty - S2 - - - - - - - SF
States
S2 filled - - S2 S2 S2 - S3 - S1 -
S3 full - - - - - S3 - S2 - -
SF finish state - - - - - - - - - -

Black-box Technique
State Transition Tree
Cyclical state transition

diagram with potentially
A state transition tree identifies the
infinite sequences necessary test cases by transforming
the state transition diagram into a
transition tree.
[after Sneed]
Transition tree with

representative set of
states without cycles

Black-box Technique
Example: State Transition Tree (1)
Procedure (according to Sneed)

1. The start state is the root of the tree
2. For each possible transition from the starting state to a
new state: branching from the root to a node
representing the successor state.
3. Repeat step 2 until one of the end conditions is
fulfilled:
Initialize
The state corresponding to the leaf is already
contained in the tree once on the way from the root
Empty
to the leaf.
(Corresponds with a run of one cycle in the state transition
diagram) Add Delete
The state corresponding to the leaf is a finish state
Filled
and therefore has no further transitions. Remove
Remove Add Add Show
Empty Filled Full Filled Filled
Remove Show
Filled Full

Black-box Technique
Example: State Transition Tree (2)
Initialize
Empty
Add Delete
Filled
7
Delete
Delete Add Add Show
Empty Filled Full Filled Filled
1 2 6
Delete Show 5
Filled Full
3 4

Black-box Technique
Example: Expanded State Transition Tree
Initialize
Empty
Delete
Remove Show Add
Error Error Filled
Remove Remove Add Add Show Delete
Empty Filled Full Filled Filled Error
Remove Show Delete Add
Filled Full Error Error

Black-box Technique
Test execution/case
Chain of several state transitions
All leaves in the state transition tree
each combination of state transitions tested
Negative tests are determined with the
expanded state transition tree.

Black-box Technique
Different coverage levels possible

typical sequences of states
all states
all valid state transitions
all invalid state transitions
certain sequences of state transitions

Black-box Technique
Exercise IV.7 Pet Store
How many test cases do you need

to run through every state at least
once?
Draw the state transition tree
(without invalid transitions).
How many test cases do you need
to cover every allowed action for
every state?

Black-box Technique
Use Case Testing (1)
A use case describes interactions between actors (users or

systems), which produce a result of value to a system user.
Use cases may be described at
the abstract level (business use case, technology-free, business process level) or
at the system level (system use case on the system functionality level).
Each use case has

preconditions (need to be met for the use case to work successfully)
a mainstream scenario (most likely) and alternative scenarios (optional)
postconditions (observable results, final state of the system)

Black-box Technique
Use Case Testing (2)
A use case describes the process

flow through a system based on its
actual likely use.
Test cases derived from use cases
are very useful for uncovering
defects in the process flows during
real-world use of the system
Useful for designing acceptance
tests with customer/user
participation

White-box Techniques

White-box technique
Procedure to derive and/or select test cases based on an
analysis of the internal structure of a component or system.
[ISTQB glossary]
Internal structure can be

Component level: statements, decisions, branches or even distinct paths (of a software
component)
Integration level: call tree (a diagram in which modules call other modules)
System level: menu structure, business process or web page structure
Focus on code-related structural test design techniques for code

coverage
Based on statements, branches and decisions
For decision testing, a control flow diagram may be used to visualize the alternatives for each
decision

Example Fibonacci
What means Fibonacci sequence?

Infinite sequence of numbers
The next number is the result of adding the two numbers preceding it
Named after Leonardo Fibonacci (growth of a bunny population)
Rules for the computation example

1. Define start values fib1 and fib2
2. Define number of iterations
3. Value of fib1 must be greater than or equal to 0
4. Value of fib2 must be greater than fib1
5. Process a maximum of 100 iterations
A tiling with squares whose sides are successive
6. Print the last Fibonacci number Fibonacci numbers in length
[http://en.wikipedia.org/wiki/Fibonacci-number]

Control Flow Graph
fib1 = read()
fib2 = read()
read fib1, fib2
read iterations
iterations = read()
result = 0
result = 0
fib1 >= 0 AND fib1 < fib2 AND iterations <= 100 if (fib1 >= 0 AND fib1 < fib2 AND iterations <= 100) {
T F
do {
result = fib1 + fib2
result = fib1 + fib2
fib1 = fib2 fib1 = fib2
fib2 = result
iterations = iterations - 1 fib2 = result
iterations = iterations - 1
T iterations > 0
} while (iterations > 0)

F
output (result)
output result
}

Code Coverage
Code coverage: An analysis method that determines which

parts of the software have been executed (covered) by the test
suite and which parts have not been executed, e.g. statement
coverage, decision coverage or condition coverage.
[ISTQB glossary]
High code coverage in white-box testing

Important because untested code is potentially more failure-prone than tested
code
Exceptionally high code coverage (e.g., 100% statement coverage) typically
cannot be achieved with black-box testing alone

C0 Statement Coverage (1)
100% C0 At least one execution of

every statement by a test case suite
fib1 >= 0 AND fib1 < fib2 AND iterations <= 100
The statement testing techniques derives
T F test cases
to execute specific statements
to increase statement coverage
Coverage
T
Number of statements covered by tests
iterations > 0
F Number of all executable statements
Note: Start and finish nodes are not

counted

Exercise IV.8
How many
test cases T F
are required for
100% statement
coverage?
T

iterations > 0

Solution To Exercise IV. 8

How many fib1 >= 0 AND fib1 < fib2 AND iterations > 0 Test case
iterations <= 100
test cases
fib1 = 0
are required for T F fib2 = 1
100% statement iterations = -5
coverage?

C0 Statement Coverage (2)
Advantages Disadvantages
Criterion is easy to Subconditions not
measure considered
Finding dead code Empty ELSE branches
ignored

C1 Decision Coverage (1)
100% C1 At least one execution of

every decision outcome (e.g. true and
false of an IF statement).
T F Coverage
Number of decision outcomes covered by tests
Number of all possible decision outcomes
Decision testing is a form of control flow

T iterations > 0
testing as it follows a specific flow of

F
control through the decision points
100% decision coverage

Implies 100% statement coverage
But not vice versa
Exercise IV.9
How many

test cases are
T F
required for 100%
decision
coverage?
T


How many fib1 >= 0 AND fib1 < fib2 AND iterations > 0 Test cases
iterations <= 100
test cases are
fib1 = 0
required for 100% T T/F fib2 = 1
decision iterations = 5
fib1 = -1
coverage? F -- fib2 = 1
iterations = 5

C1 Decision Coverage (2)
Benefits Disadvantages
Better than C0 Subconditions not
(but not much) considered
Good minimum Paths not considered
standard

C2 Condition Coverage (1)
100% C2 All atomic conditions in loops and

selective statements are executed at least once
each as true and as false
T F
Is also called
branch condition coverage
C3a, BCC, BC-Coverage
T iterations > 0 Atomic conditions in the example are
F fib1 >= 0
fib1 < fib2
iterations <= 100
iterations > 0

Exercise IV.10
How many
test cases

are required fib1 >= 0 AND fib1 < fib2 AND iterations <= 100
T F
at least for 100%
condition
coverage?
T
iterations > 0

How many
test cases fib1 >= 0 fib1 < fib2 iterations <= 100 iterations > 0 Test cases
are required
fib1 = 3
at least for 100% T T T T/F fib2 = 5
iterations = 10
condition fib1 = -1
coverage? F F F -- fib2 = -3
iterations = 150

C2 Condition Coverage (2)
Benefits Disadvantages
Takes subconditions C2 may possibly be less
into consideration comprehensive than C0
and C1

C3 Multiple Condition Coverage (1)
100% C3 - All atomic conditions as

well as all combinations in each
condition are executed once each
as true and as false.
T F
Is also called
branch condition combination coverage
multiple condition coverage, C3b, BCC coverage
T iterations > 0

Exercise IV.11
How many
test cases
are required at least T F
for 100%
multiple condition
coverage?
T

Test cases
fib1 >= 0 fib1 < fib2 iterations <= 100 iterations > 0
fib1 = -5
How many F T T -- fib2 = 5
iterations = 10
test cases fib1 = 1
T F T -- fib2 = -2
are required at least iterations = 5
for 100% T T F --
fib1 = 0
fib2 = 1
multiple condition Iterations = 150
fib1 = -1
coverage? F F T -- fib2 = -2
iterations = 150
fib1 = -5
F T F -- fib2 = 0
iterations = 150
fib1 = 1
T F F -- fib2 = -2
iterations = 150
fib1 = 0
T T T T/F fib2 = 1
iterations = 5
fib1 = -1
F F F -- fib2 = -2
iterations = 150

C3 Multiple Condition Coverage (2)
Takes subconditions Paths not considered
into consideration
Exponential increase in
More comprehensive test cases
than C0, C1 and C2

C4 Complete Path Coverage (1)
100% C4 Execution of all paths (= branch

combinations)
Every possible number of loop reiterations counts

as a path
T F
T iterations > 0

Exercise IV.12
How many test cases

are required to
T F
guarantee 100%
path coverage?
T

F

Solution To Excercise IV. 12

fib1 >= 0 AND fib1 < fib2 AND iterations > 0 Test cases
iterations <= 100
fib1 = 50
How many test cases F -- fib2 = 0
are required to iterations = 1
fib1 = 0
guarantee 100% T T/F fib2 = 1
path coverage? iterations = 0
fib1 = 0
T T/F fib2 = 1
iterations = 1
fib1 = 0
T T/F fib2 = 1
iterations = 2
[] [] []
fib1 = 0
T T/F fib2 = 1
iterations = 100

C4 Complete Path Coverage (2)
Comprehensive criterion Potentially infinite paths
(loops)!
impractical
Subconditions not
considered

Exercise IV.13: Pet Store
Draw a control flow diagram that

uses a symbol for every branch and
for every statement.
Diamond for branch
Rectangle for statement
How many test cases are required

for 100% coverage for C0, C1?
What coverage does the test case
shown in the practice materials have
for coverage type C0?


Characteristics
Experience-based testing uses

the testers skill and intuition and
their experience with similar applications and
technologies
Experience-based testing is useful to

augment systematic techniques in order
to identify test cases not easily captured
by formal techniques
The effectiveness of the techniques may
vary widely depending on the testers
experience

Error Guessing
Error guessing: A test design technique where the

experience of the tester is used to anticipate what
defects might be present in the component or
system under test as a result of errors made, and to
design tests specifically to expose them.
[ISTQB glossary]
Structured approach (fault attack)

Enumerate a list of possible defects
Design tests that attack these defects
Such a list is based on

experience
available defect and failure data
common knowledge about why software fails

Exploratory Testing (1)
Exploratory testing is concurrent

test design
test execution
test logging
learning
The test objectives to be tested (usability,

etc.) are defined
with the help of a test charter and
carried out in the form of test missions with strict
time-boxes.

Compared to black-box testing

Test design and test execution are separated in
black-box testing
Black-box tests only have the specification as a
basis
Exploratory testing also allows a peek into the test
object (white-box testing)

This technique is particularly suitable

if there are only few or inadequate specifications
under severe time pressure
to augment and complement other, more formal
testing techniques
to check on the test process to help ensure that the
most serious defects are found


The choice of which test techniques to use depends on a number

of factors
type of system
regulatory standards, customer or contractual requirements
level of risk and type of risk
test objective
available documentation
knowledge of the testers
time and budget
development life cycle
use case models
previous experience with types of defects found
test level

Component Testing
Definition of
requirements
Acceptance
testing Black-box techniques to create an initial
Functional
system design
System testing collection of test cases
boundary value analysis

Component Component
state transition testing
Implementation
decision table testing
test harness
White-box techniques additionally used
driver mainly as exit criteria and
specific supplementation of the test cases to achieve
defined coverage criteria
test object
stub

Integration Testing
Definition of
requirements
Acceptance
testing Black-box techniques and white-box
Functional
system design
System testing techniques
equivalence partitioning,

Component Component
Implementation
Coverage criteria for

parameters
interface methods

System Testing
Definition of
requirements
Acceptance
testing Mainly black-box techniques
Functional
system design
System testing equivalence partitioning
Component Component
use case testing
Implementation
requirements-based testing
White-box techniques in the sense, e.g.,

of coverage of all interface dialogs
Non-functional test types (stress, load,
performance tests)
Experience-based testing as an important
complement
Acceptance Testing
Definition of
requirements
Acceptance
testing Mainly black-box techniques, usually
Functional
system design
System testing repetition of certain test cases for system
testing in coordination with the customer
Component Component

Implementation
use case testing
Non-functional test types (e.g. usability

aspects)
Serves to ensure the customers faith in
the product rather than to find defects

Summary (1)
Test condition
An item or result that can be verified by one or more test cases (e.g., a function,
transaction, quality characteristic, ).
Test design
During the analysis and design phase the test criteria are derived from the test
objectives defined in the test plan and the test conditions are refined.
Test case
A test case consists at least of
unique ID
test object
input values and predicted result
constraints

Summary (2)
Black-box techniques
Test cases are defined and chosen based on specifications and without
consideration for the internal structure of the system
partitioning of the test range of the input values into areas of identical effect
Boundary value analysis
Analysis of the boundaries of ranges with identical effect
Decision table testing
Analysis of complex decision specifications
State transition technique
Test cases derived on the basis of state transition trees
Use case technique
Test cases derived on the basis of specified use cases

Summary (3)
White-box techniques
Procedures that require information about the inner structure of the test object to
derive and/or select test cases.
C0 statement coverage: Every statement is executed
C1 branch/decision coverage: Every branch is executed
(C2) condition coverage
(C3) multiple condition coverage
(C4) path coverage

Summary (4)
Experience-based techniques
Experience-based techniques use the knowledge and experience of
programmers, testers and users
Error guessing
Test cases are derived from experience-based defect lists
Exploratory testing
Testers explore a largely unknown/unspecified system within the scope of test missions
with the help of a test charter

Software Quality Lab
INNOVATION MEETS QUALITY
Academy | Consulting | Operational Services | Tool Expertise

Test Design Techniques: Istqb Certified Tester - Foundation Level

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Test Design Techniques: Istqb Certified Tester - Foundation Level

Uploaded by

Copyright:

Available Formats

Test Design Techniques

ISTQB Certified Tester

Software Quality Lab www.software-quality-lab.com

The Test Development Process

Software Quality Lab www.software-quality-lab.com -2-

Traceability Test design techniques

Software Quality Lab www.software-quality-lab.com -3-

Software Quality Lab www.software-quality-lab.com -4-

Software Quality Lab www.software-quality-lab.com -5-

Test case Often replaced with

Test execution Test procedure

Test log Incident

Software Quality Lab www.software-quality-lab.com -6-

The test basis includes all documents from which the

Software Quality Lab www.software-quality-lab.com -7-

A test condition is defined as an item or event of a

The test conditions are identified by analyzing the test basis

Software Quality Lab www.software-quality-lab.com -8-

Test execution Test procedure

Test log Incident

Software Quality Lab www.software-quality-lab.com -9-

Test case 5. Test Conditions not to be Tested

Test log Incident

Software Quality Lab www.software-quality-lab.com - 11 -

Testbasis Test plan Contents

Test execution Test procedure

Test log Incident

Software Quality Lab www.software-quality-lab.com - 12 -

Test execution Test procedure

Test log Incident

Software Quality Lab www.software-quality-lab.com - 13 -

Test execution Test procedure

Test log Incident

Software Quality Lab www.software-quality-lab.com - 14 -

Test case Also known as test script or manual

Test execution Test

Test log Incident

Software Quality Lab www.software-quality-lab.com - 15 -

Test case The test script describes the

Test log Incident

Software Quality Lab www.software-quality-lab.com - 16 -

Software Quality Lab www.software-quality-lab.com - 17 -

Software Quality Lab www.software-quality-lab.com - 18 -

Test case The test procedures are included in

Test log Incident

Software Quality Lab www.software-quality-lab.com - 19 -

Test log Incident

Software Quality Lab www.software-quality-lab.com - 20 -

What characterizes a well-specified test?

Software Quality Lab www.software-quality-lab.com - 21 -

Specify enough test cases to cover

Software Quality Lab www.software-quality-lab.com - 22 -

Create a test case Sell pet for the

Software Quality Lab www.software-quality-lab.com - 23 -

Software Quality Lab www.software-quality-lab.com - 24 -

Informal Data flow Specification-based test

Software Quality Lab www.software-quality-lab.com - 25 -

The purpose is to identify test conditions,

Both can also be combined with or

Software Quality Lab www.software-quality-lab.com - 26 -

The black-box test design technique

Use case testing

Software Quality Lab www.software-quality-lab.com - 27 -