3 Foundation Level Syllabus 2011

C
Certifi
ied Testerr
Found
dation
n Lev
vel Sy
yllabu
us
Released
R
Verrsion 201
11
Intternatio
onal Software Testing
g Qualiffication
ns Boarrd
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
ation Level Syyllabus
Copyrigh
ht Notice
This doccument may be copied in its entirety, or extracts made,
m
if the source
s
is ackknowledged.
Copyrigh
ht Notice In
nternational Software Te
esting Qualific
cations Boarrd (hereinafte
er called ISTQB)
ISTQB iss a registered
d trademark of the Intern
national Softw
ware Testing
g Qualifications Board,
Copyrigh
ht 2011 the
e authors forr the update 2011 (Thomas Mller (ch
hair), Debra Friedenberg, and
the ISTQ
QB WG Foun
ndation Level)
Copyrigh
ht 2010 the
hair), Armin B
Beer, Martin
Klonk, Rahul
R
Verma))
Copyrigh
ht 2007 the
hair), Dorothyy Graham, Debra
D
Friedenb
berg and Erikk van Veenendaal)
Copyrigh
ht 2005, th
he authors (T
Thomas Mlle
er (chair), Re
ex Black, Sig
grid Eldh, Dorothy Graham,
Klaus Ollsen, Maaret Pyhjrvi, Geoff
G
Thompson and Erik
k van Veenen
ndaal).
All rightss reserved.
The auth
hors hereby transfer
t
the copyright
c
to the
t Internatio
onal Softwarre Testing Qu
ualifications Board
(ISTQB). The authorrs (as currentt copyright holders) and ISTQB
I
(as th
he future cop
pyright holder)
have agrreed to the fo
ollowing cond
ditions of use
e:
1) Any individual orr training com
mpany may use
u this sylla
abus as the basis
b
for a tra
aining course
e if the
ed as the so
ource and co
opyright owners of the sy
yllabus
authors and the ISTQB are acknowledge
at any adverrtisement of such a train
ning course may
m mention
n the syllabu
us only
and provided tha
n for official accreditatio
on of the tra
aining materrials to an IISTQB recognized
afterr submission
Natio
onal Board.
2) Any individual orr group of in
ndividuals ma
ay use this syllabus
s
as the
t basis for articles, boo
oks, or
othe
er derivative writings if th
he authors and
a
the ISTQB are acknowledged a
as the sourc
ce and
copyyright ownerss of the syllabus.
3) Any ISTQB-reco
ognized Natio
onal Board may
m translate
e this syllabu
us and licensse the syllab
bus (or
o other parties.
its trranslation) to
Version 2011
2
Internationa
al Software Testing Qualifications
Q
Board
Page 2 of 78
7
31-Marr-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
Revision Histo
ory
Version
D
Date
Remarks
s
ISTQB 2011
2
E
Effective
1-Ap
pr-2011
ISTQB 2010
2
E
Effective
30-M
Mar-2010
ISTQB 2007
2
0
01-May-2007
7
ISTQB 2005
2
ASQF V2.2
01-July-2005
0
J
July-2003
ISEB V2
2.0
2
25-Feb-1999
Certified Tester Foundation Levell Syllabus

Maintena
ance Release
e see Appe
endix E Re
elease
Notes
Maintena
ance Release
e see Appe
endix E Re
elease
Notes
Maintena
ance Release
e
ASQF Sy
yllabus Foundation Level Version 2.2
Lehrplan
n Grundlagen
n des Softwa
are-testens
ISEB Sofftware Testin
ng Foundatio
on Syllabus V2.0
V
25 February 1999
Version 2011
2
Internationa
Q
Board
Page 3 of 78
7
31-Marr-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
Table of Conte
ents
Acknowledgements..................................................................................................................................... 7
Introducttion to this Syllabus
S
....................................................................................................................... 8
Purpo
ose of this Do
ocument ..................................................................................................................... 8
The Certified
C
Testter Foundatio
on Level in Software
S
Testing ................................................................. 8
Learn
ning Objective
es/Cognitive Level of Kno
owledge ............................................................................. 8
The Examination
E
.
....................
............................................................................................................... 8
Accre
editation ........................................................................................................................................... 8
Level of Detail......................................................................................................................................... 9
How this
t
Syllabus is Organized ............................................................................................................. 9
1. Fun
ndamentals of
o Testing (K
K2)......................................................................................................... 10
1.1
Why is Te
esting Necessary (K2) .............................................................................................. 11
1.1.1 Software Systems Context
C
(K1)) ........................................................................................ 11
1.1.2 Causess of Software
e Defects (K2
2) ..................................................................................... 11
1.1.3 Role off Testing in Software
and Operations (K2) ............... 11
S
Devvelopment, Maintenance
M
1.1.4 Testing
g and Qualityy (K2) .................................................................................................... 11
1.1.5 How Much Testing is Enough? (K2) ................................................................................. 12
1.2
What is Testing? (K2) ............................................................................................................. 13
Seven Testing Princip
1.3
ples (K2) ................................................................................................ 14
Fundamental Test Pro
1.4
ocess (K1) ............................................................................................ 15
1.4
4.1 Test Planning and Control
C
(K1) ........................................................................................ 15
1.4
4.2 Test An
nalysis and Design
D
(K1) ....................
.
..................................................................... 15
1.4
4.3 Test Im
mplementatio
on and Execu
ution (K1).......................................................................... 16
1.4
4.4 Evaluating Exit Critteria and Rep
porting (K1) ...................................................................... 16
1.4
4.5 Test Cllosure Activitties (K1) ............................................................................................... 16
1.5
The Psych
hology of Testing (K2) ............................................................................................. 18
1.6
Code of Ethics
E
........................................................................................................................ 20
2. Tessting Throug
ghout the Sofftware Life Cycle
C
(K2) .......................................................................... 21
2.1
Software Developmen
nt Models (K2
2) ..................................................................................... 22
2.1.1 V-mode
el (Sequentia
al Development Model) (K2) ............................................................... 22
2.1.2 Iterative
e-incrementa
al Development Models (K2)
(
.............................................................. 22
2.1.3 Testing
g within a Life
e Cycle Model (K2) ............................................................................. 22
2.2
Test Leve
els (K2) ..................................................................................................................... 24
2.2
2.1 Compo
onent Testing
g (K2) .................................................................................................... 24
2.2
2.2 Integra
ation Testing (K2) ..................................................................................................... 25
2.2
2.3 System
m Testing (K2
2) .......................................................................................................... 26
2.2
2.4 Acceptance Testing
g (K2).................................................................................................... 26
Test Type
2.3
es (K2) ...................................................................................................................... 28
2.3
3.1 Testing
g of Function
n (Functional Testing) (K2
2) .................................................................. 28
2.3
3.2 Testing
g of Non-funcctional Softw
ware Characte
eristics (Non
n-functional T
Testing) (K2) ......... 28
2.3
3.3 Testing
g of Software
e Structure/A
Architecture (Structural Te
esting) (K2) .............................. 29
2.3
3.4 Testing
g Related to Changes: Re
e-testing and
d Regression
n Testing (K2
2)........................... 29
2.4
Maintenan
nce Testing (K2)
(
...................................................................................................... 30
3. Sta
atic Techniqu
ues (K2).................................................................................................................... 31
3.1
Static Tecchniques and
d the Test Prrocess (K2) ....................................................................... 32
3.2
Review Process (K2) .............................................................................................................. 33
3.2
2.1 Activitie
es of a Form
mal Review (K
K1) .................................................................................... 33
3.2
2.2 Roles and
a Responssibilities (K1)) ........................................................................................ 33
3.2
2.3 Types of
o Reviews (K2)
(
....................................................................................................... 34
3.2
2.4 Successs Factors fo
or Reviews (K
K2).................................................................................... 35
3.3
Static Ana
alysis by Too
ols (K2) ................................................................................................. 36
4. Tesst Design Te
echniques (K
K4) ......................................................................................................... 37
4.1
The Test Developmen
nt Process (K
K3) .................................................................................... 38
4.2
es of Test De
esign Techniq
ques (K2) ......................................................................... 39
Categorie
Version 2011
2
Internationa
Q
Board
Page 4 of 78
7
31-Marr-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
4.3
Specificattion-based orr Black-box Techniques
T
(K3)
(
.............................................................. 40
4.3
3.1 Equivalence Partitio
oning (K3) ............................................................................................ 40
4.3
3.2 Bounda
ary Value An
nalysis (K3) ........................................................................................... 40
4.3
3.3 Decisio
on Table Tessting (K3) .............................................................................................. 40
4.3
3.4 State Transition
T
Testing (K3) ............................................................................................. 41
4.3
3.5 Use Ca
ase Testing (K2)
(
....................................................................................................... 41
4.4
Structure--based or Wh
hite-box Techniques (K4
4)................................................................... 42
4.4
4.1 Statem
ment Testing and
a Coverag
ge (K4) ............................................................................. 42
4.4
4.2 Decisio
on Testing an
nd Coverage
e (K4) ................................................................................ 42
4.4
4.3 Other Structure-bas
S
sed Techniqu
ues (K1) ........................................................................... 42
4.5
Experiencce-based Tecchniques (K2
2) ...................................................................................... 43
4.6
Choosing Test Techniiques (K2)............................................................................................. 44
5. Tesst Management (K3) ................................................................................................................... 45
Test Orga
5.1
anization (K2
2) ........................................................................................................... 47
5.1.1 Test Organization and
a Independ
dence (K2) ....................................................................... 47
5.1.2 Tasks of
o the Test Leader
L
and Tester
T
(K1) ........................................................................ 47
5.2
Test Planning and Esttimation (K3))........................................................................................ 49
5.2
2.1 Test Planning (K2) ............................................................................................................. 49
5.2
2.2 Test Planning Activvities (K3) .............................................................................................. 49
5.2
2.3 Entry Criteria
C
(K2) .............................................................................................................. 49
5.2
2.4 Exit Criteria (K2)................................................................................................................. 49
5.2
2.5 Test Esstimation (K2
2) .......................................................................................................... 50
5.2
2.6 Test Sttrategy, Testt Approach (K
K2) ................................................................................... 50
5.3
Test Prog
gress Monitorring and Con
ntrol (K2) .......................................................................... 51
5.3
3.1 Test Prrogress Monitoring (K1) ........................................................................................... 51
5.3
3.2 Test Re
eporting (K2)............................................................................................................ 51
5.3
3.3 Test Co
ontrol (K2)................................................................................................................ 51
5.4
Configura
ation Manage
ement (K2) ............................................................................................ 52
5.5
Risk and Testing
T
(K2) ............................................................................................................. 53
5.5
5.1 Projectt Risks (K2) .............................................................................................................. 53
5.5
5.2 Producct Risks (K2) ............................................................................................................. 53
5.6
Incident Management
M
(K3) ..................................................................................................... 55
6. Too
ol Support fo
or Testing (K2
2).......................................................................................................... 57
6.1
Types of Test
T
Tools (K
K2) ........................................................................................................ 58
6.1.1 Tool Su
upport for Te
esting (K2) ............................................................................................ 58
6.1.2 Test To
ool Classifica
ation (K2) .............................................................................................. 58
6.1.3 Tool Su
upport for Ma
anagement of
o Testing an
nd Tests (K1)) ............................................... 59
6.1.4 Tool Su
upport for Sta
atic Testing (K1) ................................................................................. 59
6.1.5 Tool Su
upport for Te
est Specificattion (K1) ........................................................................... 59
6.1.6 Tool Su
upport for Te
est Execution
n and Loggin
ng (K1) .......................................................... 60
6.1.7 Tool Su
upport for Pe
erformance and
a Monitorin
ng (K1).......................................................... 60
6.1.8 Tool Su
upport for Sp
pecific Testin
ng Needs (K1
1) .................................................................. 60
6.2
Effective Use
U of Toolss: Potential Benefits
B
and Risks (K2) ................................................... 62
6.2
2.1 Potential Benefits and
a Risks of Tool Supporrt for Testing (for all toolss) (K2) ................... 62
6.2
2.2 Special Considerations for Som
me Types of Tools
T
(K1) ..................................................... 62
Introducin
6.3
ng a Tool into
o an Organizzation (K1) ........................................................................ 64
7. References ....................................................................................................................................... 65
Stand
dards ............................................................................................................................................. 65
Bookss.................................................................................................................................................... 65
8. Appendix A Syllabus
S
Background ................................................................................................ 67
Historry of this Doccument ..................................................................................................................... 67
Objecctives of the Foundation
F
C
Certificate
Qualification ....................................................................... 67
Qualification
Objecctives of the International
I
n (adapted frrom ISTQB meeting
m
at So
ollentuna,
Novem
mber 2001)................................................................................................................................... 67
Entry Requiremen
nts for this Qu
ualification ............................................................................................ 67
Version 2011
2
Internationa
Q
Board
Page 5 of 78
7
31-Marr-2011
International
esting
Software Te
Q
Qualifications
s Board
Certiffied Teste
er
Founda
Backg
ground and History
H
of the
e Foundation
n Certificate in Software Testing
T
..................................... 68
Appendix B Learning
L
Obje
ectives/Cogn
nitive Level of
o Knowledge
e ............................................... 69
Level 1: Remember (K1) ..................................................................................................................... 69
Level 2: Understand (K2) .................................................................................................................... 69
Level 3: Apply (K3
3) .............................................................................................................................. 69
Level 4: Analyze (K4)
(
.......................................................................................................................... 69
10.
A
Appendix
C Rules App
plied to the IS
STQB ................................................................................ 71
Found
dation Syllab
bus ............................................................................................................................ 71
10..1.1 Genera
al Rules .................................................................................................................... 71
10..1.2 Current Content ................................................................................................................. 71
10..1.3 Learnin
ng Objectivess ........................................................................................................... 71
10..1.4 Overalll Structure ................................................................................................................ 71
11.
A
Appendix
D Notice to Training
T
Provviders ............................................................................... 73
12.
A
Appendix
E Release Notes...................................................................................................... 74
Relea
ase 2010 ....................................................................................................................................... 74
Relea
ase 2011 ....................................................................................................................................... 74
13.
Index ............................................................................................................................................ 76
9.
Version 2011
2
Internationa
Q
Board
Page 6 of 78
7
31-Marr-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
Ackno
owledgements
Internatio
ualifications Board Working Group Fo
oundation Le
evel (Edition 2011):
Thomas Mller (chair), Debra Friedenberg. The
T core team
m thanks the review team
m (Dan Almog
g,
Armin Be
eer, Rex Black, Julie Garrdiner, Judy McKay, Tuulla Pkkne
en, Eric Riou du Cosquierr Hans
Schaefer, Stephanie Ulrich, Erik van Veenendaal) and all National Bo
oards for the suggestions for
the curre
ent version of
o the syllabus.
Internatio
oundation Le
Thomas Mller (chair), Rahul Verma, Martin Klonk
K
and Arrmin Beer. The
T core team
m thanks the
review te
eam (Rex Bla
ack, Mette Bruhn-Peders
B
son, Debra Friedenberg,
F
Klaus Olsen
n, Judy McKa
ay,
Tuula P
kknen, Meile
M
Posthum
ma, Hans Scchaefer, Step
phanie Ulrich, Pete William
ms, Erik van
Veenend
daal) and all National Boa
ards for theirr suggestions
s.
Internatio
oundation Le
Thomas Mller (chair), Dorothy Graham,
G
Deb
bra Friedenberg, and Erikk van Veenendaal. The core
c
team tha
anks the revie
ew team (Ha
ans Schaeferr, Stephanie Ulrich, Meile
e Posthuma, Anders
Pettersson, and Won
nil Kwon) and
d all the National Boards for their sug
ggestions.
Internatio
oundation Le
Thomas Mller (chair), Rex Blackk, Sigrid Eldh
h, Dorothy Graham,
G
Klau
us Olsen, Ma
aaret Pyhjrrvi,
hompson and
d Erik van Ve
eenendaal an
nd the review
w team and all
a National B
Boards for their
Geoff Th
suggestions.
Version 2011
2
Internationa
Q
Board
Page 7 of 78
7
31-Marr-2011
International
esting
Software Te
Q
Qualifications
s Board
Certiffied Teste
er
Founda
Introd
duction
n to this
s Syllabus
Purpo
ose of thiss Docume
ent
This sylla
abus forms the
t basis for the International Softwarre Testing Qualification a
at the Founda
ation
Level. Th
he Internatio
onal Software
e Testing Qualifications Board
B
(ISTQB
B) provides it to the Natio
onal
Boards for
f them to accredit the trraining provid
ders and to derive
d
examination questtions in their local
language
e. Training providers
p
will determine appropriate
a
te
eaching meth
hods and pro
oduce course
eware
for accre
editation. The syllabus will
w help candidates in their preparation for the exa
amination.
Information on the history and ba
ackground off the syllabus
s can be foun
nd in Append
dix A.
The Certified
C
T
Tester
Foundation Level in Software
e Testing
The Foundation Leve
el qualificatio
on is aimed at
a anyone inv
volved in softtware testing
g. This includ
des
people in
n roles such as testers, te
est analysts,, test enginee
ers, test conssultants, testt managers, user
acceptan
nce testers and
a software developers. This Founda
ation Level qualification
q
iis also appro
opriate
for anyone who wantts a basic un
nderstanding of software testing, such
h as project m
managers, quality
managerrs, software developmen
nt managers, business an
nalysts, IT dirrectors and m
management
consulta
ants. Holders of the Foundation Certifficate will be able to go on
n to a higherr-level softwa
are
testing qualification.
q
Learniing Objecctives/Co
ognitive Level of Knowledge
K
e
Learning
g objectives are
a indicated
d for each section in this syllabus
s
and
d classified ass follows:
o K1: remember
r
o K2: understand
u
o K3: apply
a
o K4: analyze
a
Further details
d
and examples
e
of learning
l
obje
ectives are given in Appe
endix B.
All termss listed under Terms jusst below chap
pter heading
gs shall be re
emembered ((K1), even if not
explicitlyy mentioned in the learnin
ng objectivess.
The Examinatio
E
on
The Foundation Leve
el Certificate examination
n will be base
ed on this syyllabus. Answ
wers to
ation question
ns may require the use of
o material ba
ased on more
e than one section of this
s
examina
syllabus. All sectionss of the syllab
bus are exam
minable.
The form
mat of the exa
amination is multiple cho
oice.
Exams may
m be taken
n as part of an
a accredited
d training cou
urse or taken
n independen
ntly (e.g., at an
a
examina
ation center or
o in a public exam). Com
mpletion of an
a accredited
d training cou
urse is not a prerequisite
e for the exam
m.
Accred
ditation
An ISTQ
QB National Board
B
may accredit training providers
s whose courrse material ffollows this
syllabus. Training pro
oviders shou
uld obtain acccreditation guidelines from the board or body thatt
performss the accreditation. An acccredited cou
urse is recog
gnized as con
nforming to this syllabus, and
is allowe
ed to have an
n ISTQB exa
amination as part of the course.
g
for training provviders is give
en in Append
dix D.
Further guidance
Version 2011
2
Internationa
Q
Board
Page 8 of 78
7
31-Marr-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
Level of Detail
The leve
el of detail in this syllabuss allows interrnationally co
onsistent teaching and exxamination. In
order to achieve this goal, the syllabus consissts of:
o General instructional objectivves describin
ng the intentio
on of the Fou
undation Levvel
o A list of informatiion to teach, including a description,
d
and
a referencces to additio
onal sources if
requ
uired
o Learrning objectivves for each knowledge area,
a
describ
bing the cogn
nitive learning outcome and
a
mind
dset to be acchieved
o A list of terms tha
at students must
m
be able
e to recall and
d understand
d
o A de
escription of the
t key conccepts to teach, including sources
s
such
h as accepte
ed literature or
o
standards
The sylla
abus contentt is not a desscription of th
he entire kno
owledge area
a of software testing; it refflects
the level of detail to be
b covered in
n Foundation
n Level trainiing courses.
How th
his Syllab
bus is Orrganized
There arre six major chapters.
c
The top-level heading
h
for each chapter shows the h
highest level of
learning objectives th
hat is covere
ed within the chapter and specifies the
e time for the
e chapter. Fo
or
example
e:
2. Tes
sting Thrroughoutt the Sofftware Life Cycle (K2)
115 min
nutes
This hea
ading shows that Chapterr 2 has learning objective
es of K1 (asssumed when a higher level is
shown) and
a K2 (but not
n K3), and it is intended
d to take 115
5 minutes to teach the material in the
e
chapter. Within each chapter there are a num
mber of sectio
ons. Each se
ection also ha
as the learning
objective
es and the am
mount of time
e required. Subsections
S
that do not have
h
a time g
given are included
within the time for the
e section.
Version 2011
2
Internationa
Q
Board
Page 9 of 78
7
31-Marr-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
1.
Fundam
mentals of Testting (K2
2)
15
55 minu
utes
Learniing Objecctives forr Fundam

mentals off Testing
The obje
ectives identify what you will be able to
t do followin
ng the complletion of each
h module.
1.1 Wh
hy is Testing Necess
sary? (K2)
LO-1.1.1
1
LO-1.1.2
2
LO-1.1.3
3
LO-1.1.4
4
LO-1.1.5
5
Describe
e, with examples, the wayy in which a defect in sofftware can ca
ause harm to
oa
person, to
t the enviro
onment or to a company (K2)
(
Distinguish between the root cau
use of a defec
ct and its effe
ects (K2)
Give rea
asons why testing is nece
essary by giv
ving example
es (K2)
Describe
e why testing
g is part of qu
uality assurance and give
e examples o
of how testing
contributtes to higherr quality (K2)
Explain and
a compare
e the terms error,
e
defect, fault, failure
e, and the corrresponding terms
mistake and bug, usiing exampless (K2)
1.2 Wh
hat is Testing? (K2)
LO-1.2.1
1
LO-1.2.2
2
LO-1.2.3
3
Recall th
he common objectives
o
off testing (K1)
Provide examples for the objectivves of testing
g in different phases of th
he software life
cycle (K2
2)
Differenttiate testing from
f
debugg
ging (K2)
1.3 Sev
ven Testin
ng Princip
ples (K2)
LO-1.3.1
1
Explain the
t seven prrinciples in te
esting (K2)
1.4 Fun
ndamenta
al Test Pro
ocess (K1))
LO-1.4.1
1
Recall th
he five fundamental test activities
a
and
d respective tasks
t
from planning to closure
(K1)
1.5 The
e Psychology of Tes
sting (K2))
LO-1.5.1
1
LO-1.5.2
2
Recall th
he psycholog
gical factors that
t
influence
e the successs of testing ((K1)
Contrastt the mindsett of a tester and
a of a deve
eloper (K2)
Version 2011
2
Internationa
Q
Board
Page 10 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
1.1
Why is Testing
g Necesssary (K2
2)
20 minuttes
Terms
Bug, deffect, error, fa
ailure, fault, mistake,
m
quallity, risk
1.1.1
Software
e Systems
s Context (K1)
(
Software
e systems arre an integrall part of life, from
f
busines
ss applications (e.g., ban
nking) to cons
sumer
productss (e.g., cars).. Most people
e have had an
a experienc
ce with softwa
are that did n
not work as
expected
d. Software that
t
does nott work correcctly can lead to many pro
oblems, including loss of
money, time
t
or busin
ness reputation, and coulld even caus
se injury or de
eath.
1.1.2
Causes of
o Softwarre Defects
s (K2)
A human
n being can make
m
an erro
or (mistake), which produ
uces a defect (fault, bug) in the progra
am
code, or in a docume
ent. If a defecct in code is executed, th
he system ma
ay fail to do w
what it shoulld do
(or do so
omething it shouldnt), ca
ausing a failure. Defects in software, systems
s
or d
documents may
m
result in failures, but not all defeccts do so.
Defects occur because human be
eings are fallible and bec
cause there is time presssure, complex
x
code, co
, and/or man
omplexity of infrastructure
e, changing technologies
t
ny system intteractions.
Failures can be caussed by enviro
onmental con
nditions as well.
w
For example, radiatiion, magnetis
sm,
electroniic fields, and pollution can cause faults in firmwarre or influencce the executtion of softwa
are by
changing
g the hardwa
are conditions.
1.1.3 Role of Testing

T
in Software Developm
ment, Main
ntenance a
and
Operattions (K2)
Rigorouss testing of systems
s
and documentatiion can help to reduce th
he risk of problems occurring
during operation and
d contribute to
o the quality of the software system, if the defectss found are
corrected
d before the system is re
eleased for operational us
se.
Software
e testing mayy also be req
quired to mee
et contractua
al or legal req
quirements, o
or industry-specific
standard
ds.
1.1.4
Testing and
a
Qualitty (K2)
With the help of testing, it is posssible to meassure the quallity of software in terms o
of defects fou
und,
for both functional
f
an
nd non-functiional softwarre requireme
ents and charracteristics (e
e.g., reliabilitty,
usability, efficiency, maintainabili
m
ty and portab
bility). For more information on non-fu
unctional tes
sting
see Cha
apter 2; for more informattion on software characte
eristics see S
Software Eng
gineering
Software
e Product Qu
uality (ISO 9126).
Testing can
c give con
nfidence in th
he quality of the
t software if it finds few
w or no defeccts. A properrly
designed
d test that pa
asses reduce
es the overall level of risk
k in a system
m. When testing does find
d
defects, the quality of
o the softwarre system inccreases whe
en those defe
ects are fixed
d.
Lessonss should be le
earned from previous pro
ojects. By understanding the root causes of defec
cts
found in other projeccts, processe
es can be imp
proved, whic
ch in turn sho
ould prevent those defectts from
reoccurring and, as a consequen
nce, improve the quality of
o future systtems. This is an aspect of
o
quality assurance.
Testing should
s
be inttegrated as one
o of the qu
uality assurance activitiess (i.e., alongsside develop
pment
standard
ds, training and defect an
nalysis).
Version 2011
2
Internationa
Q
Board
Page 11 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
1.1.5
How Muc
ch Testing
g is Enoug
gh? (K2)
Deciding
g how much testing
t
is eno
ough should take accoun
nt of the leve
el of risk, inclu
uding technic
cal,
safety, and
a businesss risks, and project
p
constrraints such as
a time and budget.
b
Riskk is discussed
d
further in
n Chapter 5.
Testing should
s
provid
de sufficient information to
t stakeholders to make informed decisions abou
ut the
release of
o the softwa
are or system
m being teste
ed, for the next development step or h
handover to
custome
ers.
Version 2011
2
Internationa
Q
Board
Page 12 of 78
31-Ma
ar-2011
International
esting
Software Te
Q
Qualifications
s Board
Certiffied Teste
er
Founda
1.2
30 minuttes
What iss Testing? (K2)
Terms
Debugging, requirem
ment, review, test case, te
esting, test objective
o
Backgrround
A common perceptio
on of testing is
i that it onlyy consists of running testss, i.e., execu
uting the softw
ware.
This is part
p of testing
g, but not all of
o the testing
g activities.
Test actiivities exist before
b
and affter test execcution. Thes
se activities in
nclude plann
ning and conttrol,
choosing
g test conditions, designing and execcuting test cases, checkin
ng results, evvaluating exitt
criteria, reporting
r
on the testing process
p
and system unde
er test, and fiinalizing or ccompleting closure
activitiess after a test phase has been
b
completted. Testing also includess reviewing d
documents
(including source cod
de) and cond
ducting staticc analysis.
Both dyn
namic testing
g and static te
esting can be used as a means for acchieving sim
milar objective
es,
and will provide inforrmation that can
c be used to improve both
b
the systtem being tessted and the
e
developm
ment and tessting processses.
Testing can
c have the
e following ob
bjectives:
o Finding defects
o Gain
ning confiden
nce about the
e level of qua
ality
o Provviding information for deccision-making
g
o Prevventing defeccts
The thou
ught processs and activitie
es involved in
n designing tests
t
early in the life cycle
e (verifying the
test basis via test design) can he
elp to preventt defects from
m being intro
oduced into ccode. Review
ws of
documen
nts (e.g., req
quirements) and
a the identtification and
d resolution of
o issues also
o help to prev
vent
defects appearing
a
in the code.
Differentt viewpoints in testing takke different objectives
o
into
o account. For
F example, in developm
ment
testing (e
e.g., compon
nent, integrattion and systtem testing), the main ob
bjective may be to cause as
many faiilures as posssible so thatt defects in th
he software are
a identified
d and can be
e fixed. In
acceptan
nce testing, the
t main obje
ective may be
b to confirm that the system works as expected, to
gain con
nfidence that it has met th
he requireme
ents. In some
e cases the main
m
objectivve of testing may
be to asssess the qua
ality of the so
oftware (with no intention of fixing defe
ects), to give
e information
n to
stakeholders of the risk
r of releasing the syste
em at a given
n time. Mainttenance testiing often inclludes
testing th
t of the chan
hat no new defects
d
have been introdu
uced during developmen
d
nges. During
operational testing, the main obje
ective may be to assess system
s
chara
acteristics su
uch as reliab
bility or
availability.
Debugging and testin
ng are differe
ent. Dynamicc testing can show failure
es that are ca
aused by deffects.
Debugging is the devvelopment acctivity that fin
nds, analyzes and removves the cause
e of the failurre.
Subsequ
uent re-testin
ng by a tester ensures tha
at the fix doe
es indeed ressolve the failure. The
responsiibility for thesse activities is
i usually tessters test and
d developerss debug.
The proccess of testin
ng and the te
esting activitie
es are explained in Section 1.4.
Version 2011
2
Internationa
Q
Board
Page 13 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
1.3
Seven Testing Principles (K2))
35 minuttes
Terms
Exhaustive testing
Princip
ples
A numbe
er of testing principles
p
ha
ave been sug
ggested overr the past 40 years and offer general
guideline
es common for
f all testing
g.
esence of defects
d
Principle 1 Testing shows pre
Testing can
c show tha
at defects are present, bu
ut cannot pro
ove that there
e are no defe
ects. Testing
g
reduces the probability of undisco
overed defeccts remaining
g in the softw
ware but, eve
en if no defec
cts are
found, it is not a proo
of of correctn
ness.
Principle 2 Exhau
ustive testing is imposs
sible
Testing everything
e
(a
all combinatio
ons of inputss and precon
nditions) is no
ot feasible exxcept for triviial
cases. In
nstead of exh
haustive testting, risk ana
alysis and priorities should
d be used to
o focus testing
efforts.
Principle 3 Early testing
t
To find defects
d
early, testing activvities shall be started as early as posssible in the ssoftware or system
s
developm
ment life cycle, and shall be focused on defined objectives.
o
Principle 4 Defectt clustering
Testing effort
e
shall be
e focused prroportionally to the expec
cted and later observed d
defect density
y of
moduless. A small number of mod
dules usuallyy contains mo
ost of the deffects discove
ered during prep
release testing,
t
or is responsible for most of the
t operation
nal failures.
Principle 5 Pestic
cide paradox
x
If the sam
me tests are repeated ovver and over again, eventtually the sam
me set of tesst cases will no
longer fin
nd any new defects.
d
To overcome
o
thiis pesticide paradox, test cases nee
ed to be regu
ularly
reviewed
d and revised
d, and new and
a different tests need to
o be written to
t exercise d
different parts
s of
the softw
ware or syste
em to find potentially morre defects.
Principle 6 Testing is contextt dependentt
Testing is
i done differrently in diffe
erent contextts. For example, safety-critical softwa
are is tested
differentlly from an e--commerce site.
s
nce-of-errors
s fallacy
Principle 7 Absen
Finding and
a fixing de
efects does not
n help if the
e system built is unusable
e and does n
not fulfill the users
needs an
nd expectatio
ons.
Version 2011
2
Internationa
Q
Board
Page 14 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
1.4
Fundam
mental Test
T
Pro
ocess (K
K1)
35 minuttes
Terms
Confirma
ation testing,, re-testing, exit
e criteria, incident, regrression testin
ng, test basiss, test condittion,
test cove
erage, test da
ata, test execution, test log, test plan, test proced
dure, test policy, test suite
e, test
summaryy report, testtware
Backgrround
The mosst visible partt of testing iss test executiion. But to be
e effective an
nd efficient, ttest plans sh
hould
also inclu
ude time to be
b spent on planning
p
the tests, designing test casses, preparin
ng for execution
and evalluating resultts.
The fund
damental tesst process co
onsists of the following ma
ain activities:
o Testt planning an
nd control
o Testt analysis and design
o Testt implementa
ation and exe
ecution
o Evaluating exit criteria
c
and re
eporting
o Testt closure activities
Although
h logically se
equential, the
e activities in the process may overlap
p or take placce concurren
ntly.
Tailoring
g these main activities witthin the context of the system and the
e project is u
usually requirred.
1.4.1
Test Plan
nning and
d Control (K1)
(
Test plan
nning is the activity
a
of de
efining the ob
bjectives of te
esting and th
he specificatio
on of test ac
ctivities
in order to meet the objectives
o
an
nd mission.
Test con
ntrol is the on
ngoing activitty of comparing actual prrogress again
nst the plan, and reportin
ng the
status, in
ncluding deviations from the plan. It in
nvolves takin
ng actions ne
ecessary to m
meet the mis
ssion
and obje
ectives of the
e project. In order
o
to contrrol testing, th
he testing activities shoulld be monitorred
througho
out the projecct. Test planning takes in
nto account the feedbackk from monito
oring and con
ntrol
activitiess.
nning and co
ontrol tasks are
a defined in
n Chapter 5 of
o this syllab
bus.
Test plan
1.4.2
Test Ana
alysis and Design (K
K1)
Test ana
alysis and de
esign is the activity
a
during
g which gene
eral testing objectives are
e transformed
d into
tangible test conditio
ons and test cases.
c
The test analysis and
d design actiivity has the following ma
ajor tasks:
o Reviiewing the te
est basis (succh as require
ements, softw
ware integrityy level1 (risk level), risk
analysis reports, architecture
e, design, inte
erface speciffications)
o Evaluating testab
bility of the te
est basis and
d test objects
s
o Identifying and prioritizing
p
tesst conditions based on an
nalysis of tesst items, the specification
n,
beha
avior and stru
ucture of the
e software
o Desiigning and prioritizing hig
gh level test cases
c
o Identifying necesssary test data to supportt the test con
nditions and test cases
o Desiigning the tesst environme
ent setup and
d identifying any required
d infrastructu
ure and tools
o Crea
ating bi-direcctional tracea
ability betwee
en test basis and test casses
1
The degrree to which sofftware compliess or must complyy with a set of stakeholder-sele
s
ected software a
and/or software--based
system cha
aracteristics (e.g
g., software com
mplexity, risk asssessment, safe
ety level, securitty level, desired performance,
reliability, or
o cost) which are
a defined to re
eflect the importa
ance of the softtware to its stakkeholders.
Version 2011
2
Internationa
Q
Board
Page 15 of 78
31-Ma
ar-2011
International
esting
Software Te
Q
Qualifications
s Board
Certiffied Teste
er
Founda
1.4.3
Test Imp
plementation and Ex
xecution (K1)
Test imp
plementation and executio
on is the activity where te
est procedurres or scriptss are specifie
ed by
combinin
ng the test ca
ases in a parrticular orderr and includin
ng any other information needed for test
t
executio
on, the enviro
onment is sett up and the tests are run
n.
Test imp
plementation and executio
on has the fo
ollowing majo
or tasks:
o Fina
alizing, implem
menting and prioritizing test
t
cases (in
ncluding the identification
n of test data
a)
o Deve
eloping and prioritizing te
est procedure
es, creating test
t
data and
d, optionally, preparing te
est
harn
nesses and writing
w
autom
mated test scrripts
o Crea
ating test suittes from the test procedu
ures for efficient test execcution
o Veriffying that the
e test environ
nment has be
een set up co
orrectly
o Veriffying and updating bi-dire
ectional trace
eability between the test basis and te
est cases
o Execcuting test prrocedures either manuallly or by using
g test executtion tools, acccording to th
he
planned sequencce
o Logg
ging the outccome of test execution an
nd recording the identitiess and versions of the sofftware
unde
er test, test to
ools and testtware
o Com
mparing actua
al results with
h expected results
r
o Repo
orting discrepancies as in
ncidents and
d analyzing th
hem in orderr to establish
h their cause (e.g.,
a de
efect in the co
ode, in specified test data
a, in the test document, or
o a mistake in the way th
he test
was executed)
o Repe
eating test activities as a result of acttion taken for each discre
epancy, for e
example, reexeccution of a te
est that previo
ously failed in order to co
onfirm a fix (cconfirmation testing), exe
ecution
of a corrected tesst and/or exe
ecution of tessts in order to
t ensure tha
at defects have not been
intro
oduced in uncchanged areas of the sofftware or that defect fixing did not unccover other
defe
ects (regressiion testing)
1.4.4
Evaluatin
ng Exit Crriteria and Reporting
g (K1)
Evaluatin
ng exit criteria is the activvity where te
est execution is assessed
d against the defined
objective
es. This shou
uld be done for
f each test level (see Section
S
2.2).
Evaluatin
ng exit criteria has the following majo
or tasks:
o Checcking test log
gs against th
he exit criteria
a specified in
n test plannin
ng
o Asse
essing if morre tests are needed
n
or if the
t exit criterria specified should be ch
hanged
o Writiing a test sum
mmary reporrt for stakeho
olders
1.4.5
Test Clos
sure Activ
vities (K1)
Test clossure activities collect data

a from comp
pleted test ac
ctivities to consolidate exp
perience,
testware
e, facts and numbers.
n
Tesst closure acctivities occurr at project milestones
m
su
uch as when a
software
e system is re
eleased, a te
est project is completed (o
or cancelled), a milestone has been
achieved
d, or a mainte
enance relea
ase has been
n completed.
Version 2011
2
Internationa
Q
Board
Page 16 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
Test clossure activities include the

e following major
m
tasks:
o Checcking which planned deliverables havve been deliv
vered
o Clossing incident reports or ra
aising change
e records forr any that rem
main open
o Docu
umenting the
e acceptance
e of the syste
em
o Fina
alizing and arrchiving testw
ware, the tesst environmen
nt and the te
est infrastructture for later reuse
o Hand
ding over the
e testware to
o the mainten
nance organiization
o Anallyzing lesson
ns learned to
o determine changes
c
nee
eded for futurre releases a
and projects
o Usin
ng the information gathere
ed to improvve test maturity
Version 2011
2
Internationa
Q
Board
Page 17 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
1.5
The Pssycholog
gy of Tessting (K2)
25 minuttes
Terms
Error gue
essing, indep
pendence
Backgrround
The mind
dset to be ussed while tessting and revviewing is diffferent from th
hat used whiile developing
software
e. With the rig
ght mindset developers
d
a able to te
are
est their own code, but se
eparation of this
t
responsiibility to a tesster is typically done to help focus efffort and provide additiona
al benefits, su
uch as
an indep
pendent view
w by trained and
a professio
onal testing resources.
r
In
ndependent ttesting may be
b
carried out
o at any levvel of testing.
A certain
n degree of in
ndependencce (avoiding the
t author bias) often ma
akes the teste
er more effec
ctive
at finding
g defects and
d failures. Ind
dependence
e is not, howe
ever, a replaccement for fa
amiliarity, an
nd
develope
ers can efficiently find ma
any defects in their own code.
c
Severa
al levels of in
ndependence
e can
be define
ed as shown
n here from lo
ow to high:
o Testts designed by
b the person(s) who wro
ote the softw
ware under test (low level of independence)
b another person(s) (e.g
g., from the development
d
t team)
b a person(s) from a diffferent organiizational grou
up (e.g., an iindependentt test
team
m) or test spe
ecialists (e.g.., usability orr performanc
ce test specia
alists)
b a person(s) from a diffferent organiization or com
mpany (i.e., outsourcing or
certification by an external bo
ody)
People and
a projects are driven byy objectives.. People tend
d to align the
eir plans with the objectives set
by mana
agement and other stakeh
holders, for example,
e
to find
f
defects or
o to confirm
m that softwarre
meets itss objectives. Therefore, itt is important to clearly state the obje
ectives of testing.
Identifyin
ng failures du
uring testing may be percceived as criticism againsst the producct and agains
st the
author. As
A a result, te
esting is ofte
en seen as a destructive activity,
a
even
n though it iss very constru
uctive
in the ma
anagement of
o product rissks. Looking for failures in a system requires
r
curio
osity, profess
sional
pessimissm, a critical eye, attentio
on to detail, good
g
commu
unication with
h developme
ent peers, and
experien
nce on which to base erro
or guessing.
If errors, defects or fa
ailures are co
ommunicated in a constrructive way, bad feelings between the
e
testers and
a the analyysts, designe
ers and developers can be
b avoided. This
T
applies tto defects fou
und
during re
eviews as we
ell as in testin
ng.
The teste
er and test le
eader need good
g
interperrsonal skills to communiccate factual information about
a
defects, progress and risks in a constructive
c
w
way.
For the author of the software o
or document,
defect in
nformation ca
an help them
m improve the
eir skills. Defe
ects found and fixed duriing testing will
w
save time and moneyy later, and reduce
r
risks..
Commun
nication prob
blems may occcur, particularly if testers are seen only
o
as messengers of
unwante
ed news abou
ut defects. However, therre are severa
al ways to im
mprove comm
munication an
nd
relationsships betwee
en testers and
d others:
Version 2011
2
Internationa
Q
Board
Page 18 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
o
o
o
o
Startt with collabo

oration rather than battless remind everyone
e
of th
he common goal of bette
er
quality systems
Com
mmunicate fin
ndings on the
e product in a neutral, fac
ct-focused way
w without crriticizing the
persson who crea
ated it, for example, write objective an
nd factual inccident reportss and review
w
findings
Try to
t understand how the otther person feels
f
and why they react as they do
Conffirm that the other person
n has undersstood what yo
ou have said
d and vice ve
ersa
Version 2011
2
Internationa
Q
Board
Page 19 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
1.6
10 minuttes
Code of
o Ethicss
Involvem
ment in software testing enables
e
indivviduals to learn confidential and privile
eged informa
ation. A
code of ethics
e
is necessary, amo
ong other rea
asons to ensu
ure that the information iss not put to
inapprop
priate use. Re
ecognizing th
he ACM and
d IEEE code of ethics for engineers, th
he ISTQB states the
following
g code of ethics:
PUBLIC - Certified so
oftware teste
ers shall act consistently with the pub
blic interest
CLIENT AND EMPLO
OYER - Certtified softwarre testers sha
all act in a manner
m
that iss in the best interests
of their client
c
and em
mployer, conssistent with th
he public inte
erest
PRODUC
CT - Certified
d software te
esters shall ensure
e
that th
he deliverables they provvide (on the products
p
and systtems they tesst) meet the highest profe
essional stan
ndards possible
JUDGME
ENT- Certifie
ed software testers
t
shall maintain inte
egrity and ind
dependence in their profe
essional
judgmen
nt
MANAGEMENT - Ce
ertified softwa
are test man
nagers and le
eaders shall subscribe to and promote an
ethical approach
a
to the managem
ment of softw
ware testing
on of the pro
PROFES
SSION - Cerrtified softwarre testers shall advance the integrity and reputatio
ofession
consistent with the public interestt
COLLEA
AGUES - Cerrtified softwa
are testers sh
hall be fair to and supporttive of their ccolleagues, and
a
promote cooperation
n with software developerrs
SELF - Certified
C
softw
ware testers shall particip
pate in lifelon
ng learning regarding
r
the
e practice of their
professio
on and shall promote an ethical appro
oach to the practice
p
of the profession
n
Refere
ences
1.1.5 Black, 2001, Kaner,
K
2002
ack, 2001, Myers,
M
1979
1.2 Beizzer, 1990, Bla
1.3 Beizzer, 1990, He
etzel, 1988, Myers,
M
1979
1.4 Hetzzel, 1988
1.4.5 Black, 2001, Craig,
C
2002
1.5 Blacck, 2001, Hettzel, 1988
Version 2011
2
Internationa
Q
Board
Page 20 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
2. Testing
T
g Throug
ghout th
he Softw
ware Liffe
Cycle
e (K2)
1
115 minutes
Learniing Objecctives forr Testing Througho

out the Software
S
L
Life Cycle
e
The obje
t do followin
h module.
2.1 Sofftware Dev

velopmen
nt Models (K2)
(
LO-2.1.1
1
LO-2.1.2
2
LO-2.1.3
3
Explain the
t relationship between developmen
nt, test activitties and work products in
n the
developm
ment life cyccle, by giving examples us
sing project and
a product types (K2)
Recognize the fact th
hat software developmen
nt models mu
ust be adapte
ed to the con
ntext
of projecct and producct characterisstics (K1)
Recall ch
haracteristicss of good tessting that are
e applicable to
t any life cyycle model (K
K1)
2.2 Tes
st Levels (K2)
(
LO-2.2.1
1
Compare
e the differen
nt levels of te
esting: majorr objectives, typical objeccts of testing,,
typical ta
argets of testting (e.g., fun
nctional or sttructural) and
d related worrk products, people
who testt, types of de
efects and failures to be id
dentified (K2
2)
2.3 Tes
st Types (K2)
LO-2.3.1
1
LO-2.3.2
2
LO-2.3.3
3
LO-2.3.4
4
LO-2.3.5
5
Compare
e four softwa
are test typess (functional,, non-functional, structura
al and chang
gerelated) by example (K2)
Recognize that functtional and strructural tests
s occur at any test level (K1)
al requireme
Identify and
a describe
e non-functio
onal test type
es based on non-function
n
ents
(K2)
Identify and
a describe
e test types based
b
on the
e analysis of a software syystems struc
cture
or archite
ecture (K2)
Describe
e the purpose
e of confirma
ation testing and regression testing (K
K2)
2.4 Maintenance
e Testing (K2)
(
LO-2.4.1
1
LO-2.4.2
2
LO-2.4.3
3.
Compare
e maintenance testing (te
esting an existing system
m) to testing a new application
with resp
pect to test tyypes, triggers for testing and amount of testing (K
K2)
Recognize indicatorss for mainten
nance testing
g (modificatio
on, migration and retirement)
(K1)
Describe
e the role of regression
r
te
esting and im
mpact analysis in mainten
nance (K2)
Version 2011
2
Internationa
Q
Board
Page 21 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
2.1
Softwa
are Deve
elopmen
nt Models (K2)
20 minuttes
Terms
Commerrcial Off-The--Shelf (COTS
S), iterative-iincremental development model, validation,
verification, V-model
Backgrround
Testing does
d
not exisst in isolation
n; test activitiies are relate
ed to softwarre developme
ent activities.
Differentt developmen
nt life cycle models
m
need
d different approaches to testing.
2.1.1
V-model (Sequential Develo

opment Mo
odel) (K2)
Although
h variants of the V-modell exist, a com
mmon type off V-model usses four test levels,
correspo
onding to the
e four develop
pment levelss.
bus are:
The fourr levels used in this syllab
o Com
mponent (unitt) testing
o Integ
gration testin
ng
o Systtem testing
o Acce
eptance testiing
In practicce, a V-mode
el may have more, fewerr or different levels of devvelopment an
nd testing,
dependin
ng on the pro
oject and the
e software prroduct. For example, therre may be co
omponent
integratio
on testing aftter compone
ent testing, an
nd system in
ntegration tessting after syystem testing
g.
Software
e work produ
ucts (such ass business sccenarios or use
u cases, re
equirements sspecification
ns,
design documents
d
an
nd code) pro
oduced during developme
ent are often the basis off testing in on
ne or
more tesst levels. Refferences for generic
g
workk products include Capab
bility Maturityy Model Integ
gration
(CMMI) or
o Software life cycle pro
ocesses (IEE
EE/IEC 1220
07). Verification and valid
dation (and early
e
test design) can be carried
c
out du
uring the devvelopment off the software
e work produ
ucts.
2.1.2
Iterative--incremen
ntal Develo
opment Models (K2)
Iterative--incremental developmen
nt is the proccess of estab
blishing requiirements, designing, build
ding
and testiing a system
m in a series of
o short deve
elopment cyc
cles. Examples are: proto
otyping, Rapid
Applicatiion Developm
ment (RAD), Rational Un
nified Process
s (RUP) and agile develo
opment mode
els. A
system that
t
is producced using the
ese models may
m be teste
ed at several test levels d
during each
iteration.. An increme
ent, added to others deve
eloped previo
ously, forms a growing pa
artial system,
which sh
hould also be
e tested. Reg
gression testing is increas
singly importtant on all ite
erations afterr the
first one.. Verification and validatio
on can be ca
arried out on each increm
ment.
2.1.3
Testing within
w
a Life Cycle Model
M
(K2
2)
In any liffe cycle model, there are several characteristics of

o good testin
ng:
o For every
e
develo
opment activiity there is a corresponding testing acctivity
o Each
h test level has
h test objecctives specifiic to that leve
el
o The analysis and
d design of te
ests for a givven test level should begiin during the correspondiing
deve
elopment acttivity
o Testters should be
b involved in
n reviewing documents
d
as
a soon as drrafts are available in the
deve
elopment life cycle
Test leve
els can be co
ombined or reorganized
r
d
depending
on the nature of the projecct or the systtem
architectture. For exa
ample, for the
e integration of a Comme
ercial Off-The
e-Shelf (COT
TS) software
product into a system
m, the purcha
aser may perrform integra
ation testing at
a the system
m level (e.g.,
Version 2011
2
Internationa
Q
Board
Page 22 of 78
31-Ma
ar-2011
International
esting
Software Te
Q
Qualifications
s Board
Certiffied Teste
er
Founda
integratio
on to the infrrastructure and other systems, or sys
stem deploym
ment) and accceptance tes
sting
(function
nal and/or no
on-functional,, and user an
nd/or operational testing)).
Version 2011
2
Internationa
Q
Board
Page 23 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
2.2
40 minuttes
Test Le
evels (K
K2)
Terms
Alpha testing, beta te
esting, comp
ponent testing
g, driver, field
d testing, fun
nctional requ
uirement,
integratio
on, integratio
on testing, no
on-functionall requiremen
nt, robustnesss testing, stu
ub, system te
esting,
test environment, tesst level, test-d
driven development, use
er acceptance
e testing
Backgrround
For each
h of the test levels, the fo
ollowing can be
b identified: the genericc objectives, tthe work
product(s) being refe
erenced for deriving
d
test cases
c
(i.e., th
he test basiss), the test ob
bject (i.e., wh
hat is
being tessted), typicall defects and
d failures to be
b found, tes
st harness requirements a
and tool supp
port,
and speccific approacches and responsibilities.
Testing a systems configuration data shall be
e considered
d during test planning,
2.2.1
Component Testin
ng (K2)
Test bassis:
o Com
mponent requ
uirements
o Deta
ailed design
o Code
e
Typical test
t
objects:
o Com
mponents
o Prog
grams
o Data
a conversion / migration programs
p
o Data
abase modules
Compon
nent testing (a
also known as
a unit, modu
ule or progra
am testing) searches for d
defects in, an
nd
verifies the
t functionin
ng of, softwa
are modules, programs, objects,
o
classses, etc., that are separattely
testable.. It may be do
one in isolatiion from the rest of the sy
ystem, depending on the
e context of the
developm
ment life cycle and the syystem. Stubss, drivers and
d simulators may be used
d.
nent testing may
m include testing
t
of fun
nctionality an
nd specific no
on-functionall characteristtics,
Compon
such as resource-behavior (e.g., searching fo
or memory le
eaks) or robu
ustness testin
ng, as well as
s
structura
al testing (e.g
g., decision coverage).
c
Te
est cases are
e derived fro
om work prod
ducts such as
sa
specifica
ation of the component, th
he software design or the
e data model.
Typicallyy, component testing occcurs with acce
ess to the co
ode being tessted and with
h the supportt of a
developm
ment environ
nment, such as a unit test framework or debugging tool. In practice, comp
ponent
testing usually
u
involvves the progrrammer who wrote the co
ode. Defects are typicallyy fixed as soo
on as
they are found, witho
out formally managing
m
the
ese defects.
One app
proach to com
mponent testting is to prepare and auttomate test cases
c
before
e coding. This
s is
called a test-first app
proach or tesst-driven deve
elopment. Th
his approach
h is highly iterative and is
s
based on
n cycles of developing te
est cases, the
en building and integratin
ng small piecces of code, and
a
executing the compo
onent tests co
orrecting anyy issues and iterating unttil they pass.
Version 2011
2
Internationa
Q
Board
Page 24 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
2.2.2
Integratio
on Testing
g (K2)
Test bassis:
o Softw
ware and sysstem design
o Arch
hitecture
o Workflows
o Use cases
Typical test
t
objects:
o Subssystems
o Data
abase implem
mentation
o Infra
astructure
o Interrfaces
o Systtem configura
ation and configuration data
d
Integratio
on testing tests interfaces between components, interactions with differen
nt parts of a
system, such as the operating syystem, file syystem and ha
ardware, and interfaces b
between systtems.
There may be more than
t
one levvel of integrattion testing and
a it may be
e carried out on test objec
cts of
varying size
s
as follow
ws:
1. Com
mponent integ
gration testin
ng tests the in
nteractions between
b
softw
ware compo
onents and is
s done
afterr component testing
2. Systtem integratio
on testing tests the intera
actions betwe
een differentt systems or between
hard
dware and so
oftware and may
m be done
e after system
m testing. In this case, the developing
g
orga
anization mayy control onlyy one side off the interface. This migh
ht be conside
ered as a risk
k.
Business processses impleme
ented as worrkflows may involve a serries of system
ms. Cross-platform
issue
es may be siignificant.
The grea
ater the scop
pe of integrattion, the more difficult it becomes
b
to issolate defectts to a speciffic
compone
ent or system
m, which mayy lead to incrreased risk and
a additiona
al time for tro
oubleshooting
g.
Systema
atic integratio
on strategies may be bassed on the sy
ystem archite
ecture (such as top-down
n and
bottom-u
up), functiona
al tasks, tran
nsaction proccessing sequ
uences, or so
ome other asspect of the system
s
or compo
onents. In orrder to ease fault isolation
n and detectt defects earlly, integration
n should norrmally
be increm
mental rathe
er than big bang.
Testing of
o specific no
on-functionall characteristtics (e.g., performance) may
m be includ
ded in integrration
testing as
a well as fun
nctional testin
ng.
At each stage of inte
egration, teste
ers concentrrate solely on
n the integrattion itself. Fo
or example, iff they
are integ
grating modu
ule A with mo
odule B they are intereste
ed in testing the commun
nication betw
ween
the modu
ules, not the functionalityy of the indiviidual module
e as that wass done during
g componentt
testing. Both
B
function
nal and strucctural approaches may be
e used.
Ideally, testers
t
should understand
d the archite
ecture and inffluence integ
gration plann
ning. If integra
ation
tests are
e planned before compon
nents or syste
ems are built, those com
mponents can
n be built in th
he
order req
quired for mo
ost efficient testing.
t
Version 2011
2
Internationa
Q
Board
Page 25 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
2.2.3
System Testing
T
(K
K2)
Test bassis:
o Systtem and softw
ware require
ement specification
o Use cases
o Funcctional speciffication
o Riskk analysis rep
ports
Typical test
t
objects:
o Systtem, user and operation manuals
m
o Systtem configura
ation and configuration data
d
System testing
t
is con
ncerned with
h the behavio
or of a whole system/prod
duct. The tessting scope shall
s
be clearlly addressed
d in the Master and/or Levvel Test Plan
n for that test level.
In system
m testing, the
e test environ
nment should correspond
d to the final target or pro
oduction
environm
ment as much as possible
e in order to minimize the
e risk of environment-spe
ecific failures
s not
being fou
und in testing
g.
t
may include testss based on risks and/or on
o requirements specifica
ations, busine
ess
System testing
processe
es, use case
es, or other high level textt descriptions
s or models of system be
ehavior,
interactio
ons with the operating syystem, and syystem resources.
System testing
t
should investigate
e functional and
a non-func
ctional requirrements of th
he system, and
data qua
ality characte
eristics. Teste
ers also need
d to deal with
h incomplete
e or undocum
mented
requirem
ments. System
m testing of functional
f
requirements starts
s
by usin
ng the most a
appropriate
specifica
ation-based (black-box)
(
te
echniques fo
or the aspectt of the syste
em to be teste
ed. For exam
mple, a
decision table may be
b created for combinations of effects
s described in
n business ru
ules. Structurebased te
echniques (w
white-box) ma
ay then be ussed to asses
ss the thoroughness of th
he testing with
respect to
t a structura
al element, such
s
as menu
u structure or
o web page navigation
n
(ssee Chapter 4).
An indep
pendent test team often carries
c
out syystem testing
g.
2.2.4
Acceptan
nce Testin
ng (K2)
Test bassis:
o Userr requiremen
nts
o Systtem requirem
ments
o Use cases
o Business processses
o Riskk analysis rep
ports
Typical test
t
objects:
o Business processses on fully integrated syystem
o Operational and maintenance
e processes
o Userr proceduress
o Form
ms
o Repo
orts
o Conffiguration da
ata
Acceptance testing iss often the re
esponsibility of the customers or userrs of a system
m; other
e involved ass well.
stakeholders may be
The goal in acceptan
nce testing iss to establish
h confidence in the system
m, parts of th
he system orr
specific non-functional characteriistics of the system.
s
Find
ding defects is not the ma
ain focus in
acceptan
nce testing. Acceptance
A
t
testing
may assess the systems
s
read
diness for de
eployment an
nd
Version 2011
2
Internationa
Q
Board
Page 26 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
use, alth
hough it is no
ot necessarilyy the final levvel of testing. For example, a large-sccale system
integratio
on test may come
c
after th
he acceptancce test for a system.
Acceptance testing may
m occur att various time
es in the life cycle, for exa
ample:
o A CO
OTS software product ma
ay be accepttance tested when it is in
nstalled or inttegrated
o Acce
eptance testiing of the usa
ability of a co
omponent may be done during
d
component testing
g
o Acce
eptance testiing of a new functional en
nhancementt may come before
b
system
m testing
Typical forms
f
of acce
eptance testiing include th
he following:
ceptance te
esting
User acc
Typicallyy verifies the fitness for use of the sysstem by business users.
onal (accepttance) testin
ng
Operatio
The acce
eptance of th
he system byy the system administrato
ors, including
g:
o Testting of backu
up/restore
o Disa
aster recoverry
o Userr manageme
ent
o Main
ntenance tassks
o Data
a load and migration
m
taskks
o Perio
odic checks of security vulnerabilitiess
ct and regula
ation accepttance testin
ng
Contrac
Contractt acceptance
e testing is pe
erformed aga
ainst a contra
acts accepta
ance criteria for producing
custom-d
developed so
oftware. Accceptance crite
eria should be
b defined wh
hen the partiies agree to the
t
contract.. Regulation acceptance testing is pe
erformed aga
ainst any regu
ulations that must be adh
hered
to, such as governme
ent, legal or safety regula
ations.
g
Alpha and beta (or field) testing
Developers of marke
et, or COTS, software ofte
en want to get feedback from potentia
al or existing
g
custome
ers in their ma
arket before the software
e product is put
p up for sale commercia
ally. Alpha te
esting
is performed at the developing
d
orrganizationss site but not by the developing team. Beta testing
g, or
field-testting, is perforrmed by custtomers or po
otential custo
omers at their own locatio
ons.
Organiza
ations may use
u other term
ms as well, such
s
as facto
ory acceptancce testing an
nd site accep
ptance
testing fo
or systems th
hat are tested before and
d after being moved to a customers ssite.
Version 2011
2
Internationa
Q
Board
Page 27 of 78
31-Ma
ar-2011
International
esting
Software Te
Q
Qualifications
s Board
Certiffied Teste
er
Founda
2.3
40 minuttes
Test Tyypes (K2

2)
Terms
Black-bo
ox testing, co
ode coverage
e, functional testing, interroperability te
esting, load ttesting,
maintain
nability testing
g, performan
nce testing, portability
p
tes
sting, reliabiliity testing, se
ecurity testing,
stress te
esting, structu
ural testing, usability
u
testting, white-bo
ox testing
Backgrround
A group of test activities can be aimed
a
at veriifying the sofftware system
m (or a part o
of a system) based
on a spe
ecific reason or target for testing.
A test typ
pe is focused
d on a particcular test obje
ective, which
h could be an
ny of the follo
owing:
o A fun
nction to be performed byy the software
o A no
on-functional quality characteristic, su
uch as reliabiility or usability
o The structure or architecture of the softwa
are or system
m
o Change related, i.e., confirmiing that defe
ects have bee
en fixed (con
nfirmation tessting) and loo
oking
for unintended
u
ch
hanges (regrression testin
ng)
A model of the software may be developed
d
and/or used in
n structural te
esting (e.g., a control flow
w
model orr menu struccture model), non-function
nal testing (e
e.g., performa
ance model, usability mo
odel
security threat modeling), and fun
nctional testing (e.g., a process flow model,
m
a statte transition model
or a plain
n language specification)
s
).
2.3.1
Testing of
o Functio
on (Functio
onal Testiing) (K2)
The funcctions that a system, subssystem or co

omponent are
e to perform may be described in work
productss such as a re
equirementss specification
n, use cases
s, or a functio
onal specifica
ation, or they
y may
be undoccumented. The
T functionss are what the
t system does.
d
Function
nal tests are based on fun
nctions and features
f
(des
scribed in do
ocuments or u
understood by
b the
testers) and
a their inte
eroperability with specificc systems, an
nd may be pe
erformed at a
all test levels
s (e.g.,
tests for componentss may be bassed on a com
mponent specification).
Specifica
ation-based techniques
t
m be used to derive tes
may
st conditionss and test casses from the
functiona
ality of the so
oftware or syystem (see Chapter
C
4). Fu
unctional tessting conside
ers the extern
nal
behaviorr of the softw
ware (black-b
box testing).
A type off functional testing, security testing, in
nvestigates the
t functionss (e.g., a firew
wall) relating
g to
detection
n of threats, such as virusses, from ma
alicious outsiders. Anothe
er type of fun
nctional testing,
interoperrability testin
ng, evaluatess the capabiliity of the softtware producct to interact with one or more
specified
d componentts or systemss.
2.3.2 Testing of
o Non-fun
nctional Software
S
Characteris
C
stics (Non
n-functional
Testing
g) (K2)
Non-funcctional testing includes, but
b is not limited to, perfo
ormance testing, load testing, stress
testing, usability
u
testing, maintain
nability testin
ng, reliability testing
t
and portability
p
tessting. It is the
e
testing of
o how the system
s
workss.
Non-funcctional testing may be pe
erformed at all
a test levels. The term non-functiona
al testing des
scribes
the testss required to measure cha
aracteristics of systems and
a software
e that can be quantified on
o a
varying scale,
s
such as
a response times for perrformance te
esting. These
e tests can be referenced
d to a
quality model
m
such as
a the one de
efined in Sofftware Engine
eering Softtware Product Quality (IS
SO
Version 2011
2
Internationa
Q
Board
Page 28 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
9126). Non-functiona
N
al testing con
nsiders the external beha
avior of the so
oftware and in most case
es
uses bla
ack-box test design
d
techn
niques to acccomplish thatt.
2.3.3
Testing of
o Softwarre Structu
ure/Archite
ecture (Strructural Testing) (K
K2)
Structura
al (white-boxx) testing mayy be perform
med at all testt levels. Structural techniiques are best
used afte
er specification-based techniques, in order to help
p measure th
he thoroughn
ness of testin
ng
through assessment of coverage
e of a type of structure.
Coverag
ge is the exte
ent that a stru
ucture has be
een exercise
ed by a test suite,
s
expressed as a
percenta
age of the ite
ems being co
overed. If covverage is not 100%, then more tests m
may be desig
gned
to test th
hose items th
hat were misssed to increa
ase coverage
e. Coverage techniques a
are covered in
Chapter 4.
At all tesst levels, but especially in
n componentt testing and component integration te
esting, tools can
be used to measure the code covverage of ele
ements, such
h as stateme
ents or decisions. Structural
testing may
m be based
d on the arch
hitecture of th
he system, such
s
as a callling hierarch
hy.
Structura
al testing app
proaches can
n also be applied at syste
em, system integration
i
or acceptance
e
testing le
evels (e.g., to
o business models
m
or me
enu structure
es).
2.3.4
Testing Related
R
to
o Changes
s: Re-testing and Re
egression Testing (K2)
After a defect
d
is dete
ected and fixe
ed, the softw
ware should be
b re-tested to
t confirm th
hat the origina
al
defect ha
as been succcessfully rem
moved. This is
i called confirmation. De
ebugging (loccating and fix
xing a
defect) iss a developm
ment activity, not a testing
g activity.
Regresssion testing iss the repeate
ed testing of an already te
ested progra
am, after mod
dification, to
discoverr any defectss introduced or
o uncovered
d as a result of the chang
ge(s). These defects may
y be
either in the software
e being tested, or in anoth
her related or
o unrelated software
s
com
mponent. It is
s
performe
ed when the software, or its environm
ment, is changed. The exttent of regresssion testing
g is
based on
n the risk of not finding defects in soft
ftware that was working previously.
p
hould be repe
eatable if the
ey are to be used
u
for conffirmation testting and to assist regress
sion
Tests sh
testing.
Regresssion testing may
m be performed at all te
est levels, an
nd includes functional, no
on-functional and
structura
al testing. Re
egression tesst suites are run
r many tim
mes and gene
erally evolve
e slowly, so
regressio
on testing is a strong can
ndidate for au
utomation.
Version 2011
2
Internationa
Q
Board
Page 29 of 78
31-Ma
ar-2011
International
esting
Software Te
Q
Qualifications
s Board
Certiffied Teste
er
Founda
2.4
Maintenance Testing
T
(
(K2)
15 minuttes
Terms
Impact analysis,
a
maintenance tessting
Backgrround
Once de
eployed, a so
oftware syste
em is often in
n service for years
y
or decades. During
g this time the
system, its configura
ation data, or its environm
ment are often
n corrected, changed or extended. Th
he
planning
g of releases in advance is
i crucial for successful maintenance
m
e testing. A distinction has
s to be
made be
etween plann
ned releases and hot fixe
es. Maintenan
nce testing iss done on an
n existing
operational system, and
a is triggered by modiffications, mig
gration, or retirement of th
he software or
system.
Modifica
ations include
e planned en
nhancement changes
c
(e.g
g., release-ba
ased), correcctive and
emergen
ncy changes, and change
es of environ
nment, such as
a planned operating
o
sysstem or database
upgrades, planned upgrade of Co
ommercial-O
Off-The-Shelff software, orr patches to correct newly
exposed
d or discovere
ed vulnerabilities of the operating
o
sys
stem.
Maintena
ance testing for migration
n (e.g., from one platform
m to another) should inclu
ude operation
nal
tests of the
t new environment as well
w as of the
e changed so
oftware. Migration testing
g (conversion
n
testing) is
i also neede
ed when data
a from anoth
her applicatio
on will be mig
grated into th
he system be
eing
maintain
ned.
Maintena
ance testing for the retire
ement of a syystem may in
nclude the te
esting of data
a migration or
archiving
g if long data
a-retention pe
eriods are required.
In additio
on to testing what has be
een changed, maintenanc
ce testing inccludes regression testing
g to
parts of the
t system that have nott been chang
ged. The sco
ope of mainte
enance testin
ng is related to
t the
risk of th
he change, th
he size of the
e existing sysstem and to the
t size of th
he change. D
Depending on
n the
changess, maintenancce testing may be done at
a any or all test
t
levels an
nd for any orr all test types.
Determin
ning how the
e existing sysstem may be affected by changes is called
c
impactt analysis, an
nd is
used to help
h
decide how
h
much re
egression tessting to do. The
T impact analysis may be used to
determin
ne the regresssion test suiite.
Maintena
ance testing can be difficcult if specificcations are out
o of date orr missing, or testers with
domain knowledge
k
a not availa
are
able.
Refere
ences
2.1.3 CM
MMI, Craig, 2002,
2
Hetzell, 1988, IEEE
E 12207
2.2 Hetzzel, 1988
2.2.4 Co
opeland, 200
04, Myers, 19
979
2.3.1 Be
eizer, 1990, Black,
B
2001, Copeland, 2004
2
2.3.2 Black, 2001, IS
SO 9126
2.3.3 Be
eizer, 1990, Copeland,
C
20
004, Hetzel, 1988
2.3.4 He
etzel, 1988, IEEE
I
STD 82
29-1998
2.4 Blacck, 2001, Cra
aig, 2002, He
etzel, 1988, IEEE
I
STD 82
29-1998
Version 2011
2
Internationa
Q
Board
Page 30 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
3.
S
Static
T
Techniq
ues (K2
2)
6
60 minuttes
Learniing Objecctives forr Static Te

echniques
The obje
t do followin
h module.
3.1 Sta
atic Techniques and
d the Test Process (K2)
(
LO-3.1.1
1
LO-3.1.2
2
LO-3.1.3
3
Recognize software work produccts that can be

b examined by the differrent static
techniqu
ues (K1)
Describe
e the importa
ance and valu
ue of conside
ering static te
echniques fo
or the assess
sment
of softwa
are work products (K2)
Explain the
t differencce between static
s
and dyn
namic techniques, consid
dering objecttives,
types of defects to be
e identified, and
a the role of these tech
hniques with
hin the softwa
are life
cycle (K2
2)
3.2 Rev
view Proc
cess (K2)
LO-3.2.1
1
LO-3.2.2
2
LO-3.2.3
3
Recall th
he activities, roles and responsibilities
s of a typical formal revie
ew (K1)
Explain the
t differencces between different type
es of reviewss: informal re
eview, techniical
and inspection (K2)
review, walkthrough
w
Explain the
t factors fo
or successful performanc
ce of reviewss (K2)
3.3 Sta
atic Analys
sis by Too
ols (K2)
LO-3.3.1
1
LO-3.3.2
2
LO-3.3.3
3
Recall tyypical defectss and errors identified by

y static analyssis and comp
pare them to
o
reviews and dynamicc testing (K1)
Describe
e, using exam
mples, the tyypical benefits of static an
nalysis (K2)
List typiccal code and design defe
ects that may
y be identified
d by static an
nalysis tools (K1)
Version 2011
2
Internationa
Q
Board
Page 31 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
3.1 Static Techniq

T
ues and
d the Tes
st Proce
ess
(K2)
15 minuttes
Terms
Dynamicc testing, stattic testing
Backgrround
Unlike dyynamic testin
ng, which req
quires the exxecution of so
oftware, static testing tecchniques rely
y on
the manu
ual examinattion (reviewss) and autom
mated analysiis (static ana
alysis) of the code or othe
er
project documentatio
d
on without the execution of the code.
Reviewss are a way of
o testing softtware work products
p
(including code)) and can be performed well
w
before dynamic test execution.
e
D
Defects
deteccted during re
eviews early in the life cyycle (e.g., deffects
found in requirementts) are often much cheap
per to remove
e than those detected byy running testts on
the execcuting code.
A review
w could be do
one entirely as
a a manual activity, but there is also tool supportt. The main
manual activity
a
is to examine
e
a work
w
product and make co
omments about it. Any so
oftware work
k
product can
c be reviewed, includin
ng requireme
ents specifica
ations, desig
gn specifications, code, te
est
plans, te
est specifications, test casses, test scriipts, user guides or web pages.
Benefits of reviews in
nclude early defect detecction and corrrection, deve
elopment pro
oductivity
improvem
ments, reducced developm
ment timesca
ales, reduced
d testing cosst and time, liifetime cost
reduction
ns, fewer deffects and improved comm
munication. Reviews
R
can
n find omissio
ons, for exam
mple,
in require
ements, whicch are unlike
ely to be foun
nd in dynamic testing.
Reviewss, static analyysis and dyna
amic testing have the same objective
e identifying
g defects. Th
hey
are complementary; the different techniques can find diffe
erent types of
o defects effe
ectively and
efficiently. Compared
d to dynamicc testing, stattic technique
es find causes of failures (defects) rather
than the failures them
mselves.
Typical defects
d
that are
a easier to find in reviews than in dynamic testin
ng include: d
deviations fro
om
standard
ds, requireme
ent defects, design
d
defeccts, insufficie
ent maintaina
ability and inccorrect interfa
ace
specifica
ations.
Version 2011
2
Internationa
Q
Board
Page 32 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
3.2
25 minuttes
Review
w Processs (K2)
Terms
Entry criteria, formal review, inforrmal review, inspection, metric,
m
mode
erator, peer rreview, review
wer,
scribe, te
echnical review, walkthro
ough
Backgrround
The diffe
erent types of
o reviews vary from inform
mal, characterized by no
o written instrructions for
reviewerrs, to systematic, charactterized by tea
am participattion, docume
ented resultss of the review
w, and
documen
nted procedu
ures for cond
ducting the re
eview. The fo
ormality of a review proce
ess is related
d to
factors such
s
as the maturity
m
of the developme
ent process, any legal or regulatory re
equirements
s or the
need forr an audit traiil.
The wayy a review is carried out depends
d
on the
t agreed objectives of the
t review (e
e.g., find defe
ects,
gain und
derstanding, educate testters and new
w team memb
bers, or discu
ussion and d
decision by
consenssus).
3.2.1
Activities
s of a Form
mal Revie
ew (K1)
A typicall formal revie

ew has the fo
ollowing main
n activities:
1. Plan
nning
Defining
D
the review criterria
Selecting
S
the
e personnel
Allocating
A
ro
oles
Defining
D
the entry and exxit criteria forr more forma
al review type
es (e.g., insp
pections)
Selecting
S
wh
hich parts of documents to
t review
Checking
C
en
ntry criteria (ffor more form
mal review types)
2. Kickk-off
Distributing
D
d
documents
Explaining
E
th
he objectivess, process an
nd documentts to the participants
3. Indivvidual preparration
Preparing
P
for the review meeting by reviewing
r
the
e document(s)
Noting
N
poten
ntial defects, questions an
nd commentts
4. Exam
mination/eva
aluation/recorrding of resu
ults (review meeting)
m
Discussing
D
o logging, with documented results or
or
o minutes (fo
or more form
mal review typ
pes)
Noting
N
defeccts, making re
ecommenda
ations regarding handling the defects, making dec
cisions
a
about
the de
efects
Examining/e
E
evaluating and recording issues during
g any physiccal meetings or tracking any
a
g
group
electro
onic commun
nications
5. Rew
work
Fixing
F
defectts found (typ
pically done by
b the authorr)
Recording
R
updated status of defects (in formal reviews)
6. Follo
ow-up
Checking
C
tha
at defects ha
ave been add
dressed
Gathering
G
metrics
Checking
C
on
n exit criteria (for more forrmal review types)
t
3.2.2
Roles an
nd Respon
nsibilities (K1)
A typicall formal revie

ew will includ
de the roles below:
b
o Manager: decide
es on the exe
ecution of revviews, alloca
ates time in project
p
sched
dules and
dete
ermines if the
e review obje
ectives have been met.
Version 2011
2
Internationa
Q
Board
Page 33 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
o
o
Moderator: the person

p
who le
eads the review of the do
ocument or set
s of docume
ents, includin
ng
planning the reviiew, running the meeting, and followin
ng-up after th
he meeting. If necessary
y, the
moderator may mediate
m
betw
ween the various points of
o view and iss often the pe
erson upon whom
w
the success
s
of th
he review ressts.
Auth
hor: the writer or person with
w chief ressponsibility fo
or the docum
ment(s) to be reviewed.
Reviiewers: indivviduals with a specific technical or bus
siness backg
ground (also called check
kers or
inspe
ectors) who, after the necessary prep
paration, iden
ntify and desscribe finding
gs (e.g., defe
ects) in
the product
p
unde
er review. Re
eviewers sho
ould be chose
en to represe
ent different perspectives
s and
roless in the revie
ew process, and
a should ta
ake part in any review me
eetings.
Scrib
be (or record
der): docume
ents all the isssues, proble
ems and open points thatt were identiffied
durin
ng the meetin
ng.
Looking at software products

p
or related
r
work products fro
om different perspectives
p
and using
checklistts can make reviews morre effective and
a efficient. For example
e, a checklistt based on various
v
perspecttives such ass user, mainttainer, testerr or operation
ns, or a checcklist of typica
al requirements
problemss may help to
o uncover prreviously und
detected issu
ues.
3.2.3
Types off Reviews (K2)
A single software pro

oduct or relatted work pro
oduct may be
e the subject of more than
n one review
w. If
more tha
an one type of
o review is used,
u
the ord
der may vary
y. For example, an inform
mal review ma
ay be
carried out
o before a technical
t
revview, or an in
nspection ma
ay be carried out on a req
quirements
specifica
ation before a walkthroug
gh with customers. The main
m
characte
eristics, optio
ons and purp
poses
of comm
mon review tyypes are:
Informal Review
o No fo
ormal processs
o May take the form
m of pair pro
ogramming or
o a technical lead review
wing designs and code
o Resu
ults may be documented
d
o Varie
es in usefuln
ness dependiing on the re
eviewers
o Main
n purpose: in
nexpensive way
w to get so
ome benefit
Walkthrrough
o Mee
eting led by author
a
o May take the form
m of scenarios, dry runs,, peer group participation
n
o Open-ended sesssions
O
pre-meeting pre
eparation of reviewers
r
Optional
Optional
O
preparation of a review repo
ort including list of finding
gs
o Optio
onal scribe (who is not th
he author)
o May vary in pracctice from quiite informal to very forma
al
o Main
n purposes: learning, gaining undersstanding, find
ding defects
cal Review
Technic
o Docu
umented, de
efined defect--detection prrocess that in
ncludes peerrs and techniical experts with
w
optio
onal manage
ement particip
pation
o May be performe
ed as a peer review witho
out managem
ment participation
o Idea
ally led by trained modera
ator (not the author)
a
o Pre-meeting prep
paration by reviewers
r
o Optio
onal use of checklists
c
o Prep
paration of a review reporrt which inclu
udes the list of findings, the
t verdict whether the
recommendations relate
softw
ware productt meets its re
equirements and, where appropriate,
a
ed to
findings
o May vary in pracctice from quiite informal to very forma
al
o Main
n purposes: discussing, making decissions, evalua
ating alternattives, finding
g defects, sollving
technical problem
ms and checcking conform
mance to spe
ecifications, plans,
p
regula
ations, and
standards
Version 2011
2
Internationa
Q
Board
Page 34 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
Inspectiion
o Led by trained moderator
m
(no
ot the author)
o Usua
ally conducte
ed as a peer examination
n
o Defin
ned roles
o Inclu
udes metrics gathering
o Form
mal process based
b
on rules and checcklists
o Speccified entry and
a exit criterria for accep
ptance of the software pro
oduct
o Pre-meeting prep
paration
o Inspection reportt including lisst of findings
o Form
mal follow-up
p process (wiith optional process
p
impro
ovement com
mponents)
o Optio
onal reader
o Main
n purpose: fin
nding defectss
Walkthro
oughs, technical reviews and inspectiions can be performed
p
w
within
a peer g
group,
i.e., colle
eagues at the
e same organizational levvel. This type
e of review iss called a pe
eer review.
3.2.4
Success
s Factors for
f Review
ws (K2)
Successs factors for reviews

r
include:
o Each
h review hass clear predeffined objectivves
o The right people for the revie
ew objectivess are involved
d
o Testters are value
ed reviewerss who contrib
bute to the re
eview and alsso learn abou
ut the produc
ct
whicch enables th
hem to prepa
are tests earlier
o Defe
ects found arre welcomed and expresssed objective
ely
o Peop
ple issues an
nd psycholog
gical aspectss are dealt with (e.g., makking it a positive experien
nce for
the author)
a
o The review is conducted in an atmospherre of trust; th
he outcome will
w not be ussed for the
evaluation of the
e participantss
o Reviiew techniqu
ues are applie
ed that are suitable
s
to ac
chieve the ob
bjectives and to the type and
a
level of software work produccts and revie
ewers
o Checcklists or role
es are used if appropriate
e to increase
e effectivenesss of defect identification
n
o Train
ning is given in review techniques, esspecially the more formall techniques such as
inspe
ection
o Management sup
pports a goo
od review pro
ocess (e.g., by
b incorporatting adequate
e time for rev
view
ect scheduless)
activvities in proje
o Therre is an emphasis on learrning and pro
ocess improv
vement
Version 2011
2
Internationa
Q
Board
Page 35 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
3.3
Static Analysis
A
s by Too
ols (K2)
20 minuttes
Terms
Compiler, complexityy, control flow
w, data flow, static analys
sis
Backgrround
The obje
ective of statiic analysis iss to find defects in softwa
are source co
ode and softw
ware models
s.
Static an
nalysis is perrformed witho
out actually executing
e
the
e software be
eing examine
ed by the too
ol;
dynamicc testing doess execute the
e software co
ode. Static analysis can locate
l
defectts that are ha
ard to
find in dyynamic testin
ng. As with re
eviews, staticc analysis fin
nds defects rather
r
than fa
ailures. Static
c
analysis tools analyzze program code
c
(e.g., co
ontrol flow an
nd data flow)), as well as g
generated ou
utput
such as HTML and XML.
X
The valu
ue of static an
nalysis is:
o Earlyy detection of
o defects prior to test exe
ecution
o Earlyy warning ab
bout suspicio
ous aspects of
o the code or
o design by the
t calculatio
on of metrics
s, such
as a high comple
exity measurre
o Identification of defects
d
not easily
e
found by
b dynamic testing
t
o Dete
ecting dependencies and inconsistenccies in softw
ware models such
s
as linkss
o Imprroved mainta
ainability of code
c
and dessign
o Prevvention of defects, if lesso
ons are learn
ned in develo
opment
Typical defects
d
disco
overed by sta
atic analysis tools include
e:
o Refe
erencing a va
ariable with an
a undefined
d value
o Inconsistent interfaces betwe
een moduless and compon
nents
o Varia
ables that arre not used or
o are improp
perly declared
d
o Unre
eachable (de
ead) code
o Misssing and erro
oneous logic (potentially infinite loops)
o Overly complicatted constructts
o Prog
gramming sta
andards viola
ations
o Secu
urity vulnerab
bilities
o Synttax violationss of code and
d software models
m
Static an
nalysis tools are typically used by devvelopers (che
ecking against predefined
d rules or
programming standa
ards) before and
a during component an
nd integration testing or w
when checking-in
c
n manageme
ent tools, and
d by designers during sofftware modelling. Static
code to configuration
analysis tools may produce a larg
ge number of
o warning me
essages, which need to b
be well-mana
aged
to allow the most effe
ective use off the tool.
Compilers may offer some suppo
ort for static analysis,
a
inclluding the ca
alculation of m
metrics.
Refere
ences
3.2 IEEE
E 1028
3.2.2 Giilb, 1993, van
n Veenendaa
al, 2004
3.2.4 Giilb, 1993, IEE
EE 1028
3.3 van Veenendaall, 2004
Version 2011
2
Internationa
Q
Board
Page 36 of 78
31-Ma
ar-2011
International
esting
Software Te
Q
Qualifications
s Board
Certiffied Teste
er
Founda
4.
T
Test
De
esign Te
echniqu
ues (K4))
28
85 minu
utes
Learniing Objecctives forr Test Dessign Tech

hniques
The obje
t do followin
h module.
4.1 The
e Test Dev
velopmentt Process (K3)
LO-4.1.1
1
LO-4.1.2
2
LO-4.1.3
3
LO-4.1.4
4
Differenttiate between
n a test desig
gn specificattion, test case specificatio
on and test
procedure specificatiion (K2)
Compare
e the terms test
t
condition
n, test case and
a test proccedure (K2)
Evaluate
e the quality of test casess in terms of clear traceab
bility to the re
equirements
s and
expected
d results (K2
2)
Translate
e test cases into a well-sstructured tes
st procedure specification
n at a level of
o
detail rellevant to the knowledge of
o the testers
s (K3)
4.2 Cattegories of
o Test Des
sign Tech
hniques (K
K2)
LO-4.2.1
1
LO-4.2.2
2
Recall re
easons that both
b
specification-based (black-box) and
a structure
e-based (whitebox) testt design tech
hniques are useful
u
and lis
st the commo
on technique
es for each (K
K1)
Explain the
t characteristics, comm
monalities, an
nd difference
es between sspecification--based
testing, structure-bas
s
sed testing and
a experienc
ce-based tessting (K2)
4.3 Spe
ecification
n-based or Black-bo
ox Techniques (K3)
LO-4.3.1
1
LO-4.3.2
2
LO-4.3.3
3
Write tesst cases from

m given softw
ware models using equiva
alence partitiioning, bound
dary
value an
nalysis, decission tables an
nd state transition diagra
ams/tables (K
K3)
Explain the
t main purrpose of each
h of the four testing techn
niques, whatt level and ty
ype of
testing could
c
use the
e technique, and
a how cov
verage may be
b measured
d (K2)
Explain the
t concept of use case testing and its benefits (K
K2)
4.4 Strructure-ba
ased or Wh
hite-box Technique
T
s (K4)
LO-4.4.1
1
LO-4.4.2
2
LO-4.4.3
3
LO-4.4.4
4
Describe
e the concep
pt and value of
o code cove
erage (K2)
Explain the
t conceptss of statemen
nt and decision coverage
e, and give re
easons why these
t
conceptss can also be
e used at tesst levels othe
er than component testing
g (e.g., on
businesss proceduress at system le
evel) (K2)
Write tesst cases from
m given contrrol flows usin
ng statementt and decision test design
n
techniqu
ues (K3)
Assess statement
s
an
nd decision coverage
c
for completenesss with respe
ect to defined
d exit
criteria. (K4)
(
4.5 Exp
perience-b
based Tec
chniques (K2)
(
LO-4.5.1
1
LO-4.5.2
2
Recall re
easons for writing
w
test ca
ases based on
o intuition, experience
e
an
nd knowledg
ge
about co
ommon defeccts (K1)
Compare
e experience
e-based tech
hniques with specification
n-based testin
ng technique
es (K2)
4.6 Cho
oosing Te
est Techniiques (K2))
LO-4.6.1
1
Classify test design techniques

t
a
according
to their
t
fitness to
t a given co
ontext, for the
e test
basis, re
espective mo
odels and sofftware charac
cteristics (K2
2)
Version 2011
2
Internationa
Q
Board
Page 37 of 78
31-Ma
ar-2011
International
esting
Software Te
Q
Qualifications
s Board
Certiffied Teste
er
Founda
4.1
The Te
est Deve
elopmen
nt Proces
ss (K3)
15 minuttes
Terms
Test casse specificatio
on, test desig
gn, test execcution schedule, test proccedure speciification, testt
script, tra
aceability
Backgrround
The test developmen
nt process de
escribed in th
his section ca
an be done in different w
ways, from ve
ery
informal with little or no documen
ntation, to very formal (as
s it is describ
bed below). T
The level of
formalityy depends on
n the contextt of the testin
ng, including the maturity of testing an
nd development
processe
es, time consstraints, safe
ety or regulattory requirem
ments, and th
he people invvolved.
During te
est analysis, the test basis documenttation is analyzed in orde
er to determin
ne what to te
est,
i.e., to id
dentify the tesst conditionss. A test cond
dition is defin
ned as an item or event th
hat could be
verified by
b one or mo
ore test case
es (e.g., a fun
nction, transa
action, quality characterisstic or structu
ural
element)).
Establish
hing traceability from testt conditions back
b
to the specifications
s
s and require
ements enab
bles
both effe
ective impactt analysis wh
hen requirem
ments change
e, and determ
mining requirrements cove
erage
for a set of tests. Durring test analysis the deta
ailed test approach is implemented to
o select the test
t
design te
echniques to
o use based on,
o among other
o
conside
erations, the identified risks (see Chapter 5
for more on risk analysis).
During te
est design th
he test casess and test datta are create
ed and speciffied. A test ccase consists
s of a
set of inp
put values, execution
e
pre
econditions, expected
e
res
sults and exe
ecution postcconditions, de
efined
to cover a certain tesst objective(ss) or test con
ndition(s). The Standard for Software Test
Docume
entation (IEE
EE STD 829-1998) descriibes the conttent of test design specifiications
(containiing test cond
ditions) and test case spe
ecifications.
Expected
d results sho
ould be produ
uced as part of the specification of a test case and include outputs,
changess to data and states, and any other co
onsequences
s of the test. If expected rresults have not
been deffined, then a plausible, but erroneouss, result may
y be interpretted as the co
orrect one.
Expected
d results sho
ould ideally be
b defined prrior to test ex
xecution.
During te
est implemen
ntation the te
est cases are
e developed, implemente
ed, prioritized
d and organiz
zed in
the test procedure
p
sp
pecification (IEEE STD 829-1998). Th
he test proce
edure specifies the seque
ence
of action
ns for the exe
ecution of a test.
t
If tests are
a run using
g a test execution tool, the sequence of
actions is specified in
n a test scrip
pt (which is an automated
d test procedure).
The vario
ous test proccedures and automated test
t
scripts are subseque
ently formed into a test
executio
on schedule that
t
defines the
t order in which
w
the various test pro
ocedures, an
nd possibly
automate
ed test scriptts, are execu
uted. The test execution schedule will take into account such
factors as
a regression
n tests, prioritization, and technical an
nd logical dependencies.
Version 2011
2
Internationa
Q
Board
Page 38 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
4.2 Catego
ories of Test
T
Design Tec
chnique
es
(K2)
15 minuttes
Terms
Black-bo
ox test design
n technique, experience--based test design
d
techniique, test dessign techniqu
ue,
white-bo
ox test design
n technique
Backgrround
The purp
pose of a tesst design tech
hnique is to identify
i
test conditions,
c
te
est cases, an
nd test data.
assic distinction to denote
e test techniq
ques as blac
ck-box or whiite-box. Blacck-box test de
esign
It is a cla
techniqu
ues (also called specificattion-based te
echniques) are
a a way to derive
d
and select test
condition
ns, test cases, or test datta based on an analysis of
o the test ba
asis documentation. This
s
includes both functio
onal and non--functional te
esting. Black
k-box testing, by definition, does not use
u
any inforrmation rega
arding the inte
ernal structure of the com
mponent or system
s
to be tested. Whitte-box
test design technique
es (also calle
ed structural or structure--based techn
niques) are b
based on an
analysis of the structture of the co
omponent or system. Black-box and white-box
w
tessting may als
so be
combine
ed with experrience-based
d techniques to leverage the experien
nce of develo
opers, testers
s and
users to determine what
w
should be
b tested.
Some techniques fall clearly into a single cate
egory; others
s have eleme
ents of more than one
categoryy.
This sylla
abus refers to
t specificatio
on-based tesst design tec
chniques as black-box
b
tecchniques and
d
structure
e-based test design techn
niques as wh
hite-box techniques. In ad
ddition experrience-based
d test
design te
echniques arre covered.
Common
n characterisstics of specification-base
ed test design techniquess include:
o Models, either fo
ormal or inforrmal, are use
ed for the spe
ecification off the problem
m to be solved
d, the
softw
ware or its co
omponents
o Testt cases can be
b derived syystematicallyy from these models
Common
n characterisstics of structture-based te
est design te
echniques incclude:
o Inforrmation abou
ut how the so
oftware is constructed is used to derivve the test ca
ases (e.g., code
c
and detailed dessign informatiion)
o The extent of covverage of the
e software ca
an be measu
ured for existting test case
es, and furthe
er test
case
es can be derived system
matically to in
ncrease cove
erage
Common
n characterisstics of experrience-based
d test design techniques include:
o The knowledge and
a experien
nce of people
e are used to
o derive the test
t
cases
o The knowledge of
o testers, de
evelopers, ussers and othe
er stakeholde
ers about the
e software, itts
usag
ge and its en
nvironment iss one source of informatio
on
o Know
wledge abou
ut likely defeccts and their distribution is
i another so
ource of inforrmation
Version 2011
2
Internationa
Q
Board
Page 39 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
4.3 Specification-b
based orr Black-b
box
Techn
niques (K3)
(
1
150 minu
utes
Terms
Boundarry value analysis, decisio
on table testin
ng, equivalen
nce partitioniing, state transition testin
ng, use
case tessting
4.3.1
Equivale
ence Partittioning (K
K3)
In equiva
alence partitiioning, inputss to the softw
ware or syste
em are divide
ed into group
ps that are
expected
d to exhibit similar
s
behavvior, so they are
a likely to be
b processed
d in the same way.
Equivale
ence partition
ns (or classess) can be fou
und for both valid data, i.e., values that should be
e
accepted
d and invalid data, i.e., va
alues that sh
hould be rejected. Partitio
ons can also be identified
d for
outputs, internal valu
ues, time-rela
ated values (e.g.,
(
before or after an event)
e
and for interface
parameters (e.g., inte
egrated com
mponents bein
ng tested during integratiion testing). T
Tests can be
e
d to cover alll valid and in
nvalid partitions. Equivale
ence partition
ning is appliccable at all levels of
designed
testing.
Equivale
ence partition
ning can be used
u
to achie
eve input and
d output cove
erage goals. It can be ap
pplied
to human input, input via interfacces to a syste
em, or interfa
ace paramete
ers in integra
ation testing.
4.3.2
Boundarry Value Analysis

A
(K
K3)
Behaviorr at the edge

e of each equ
uivalence partition is morre likely to be
e incorrect th
han behavior within
the partittion, so boun
ndaries are an
a area wherre testing is likely to yield defects. The
e maximum and
minimum
m values of a partition are
e its boundarry values. A boundary
b
va
alue for a valiid partition is
sa
valid bou
undary value
e; the bounda
ary of an inva
alid partition is an invalid boundary va
alue. Tests can
c be
designed
d to cover bo
oth valid and invalid boun
ndary values. When desig
gning test ca
ases, a test fo
or
each bou
undary value
e is chosen.
Boundarry value analysis can be applied at all test levels. It is relatively easy to apply and its defectfinding capability
c
is high.
h
Detailed
d specificatio
ons are helpfful in determiining the inte
eresting
boundarries.
This tech
hnique is ofte
en considere
ed as an exte
ension of equ
uivalence partitioning or o
other black-b
box
test design technique
es. It can be used on equ
uivalence cla
asses for use
er input on sccreen as well as,
for exam
mple, on time ranges (e.g., time out, trransactional speed requirements) or ttable ranges
s (e.g.,
table size is 256*256
6).
4.3.3
Decision
n Table Testing (K3))
Decision
n tables are a good way to
t capture syystem require
ements that contain
c
logiccal conditions
s, and
to docum
ment internal system design. They ma
ay be used to
o record com
mplex business rules thatt a
system is to impleme
ent. When crreating decision tables, th
he specificatiion is analyzzed, and cond
ditions
and actio
ons of the syystem are ide
entified. The input conditions and actions are mosst often stated in
such a way
w that theyy must be true or false (Boolean). The
e decision tab
ble contains the triggering
condition
ns, often com
mbinations off true and false for all inp
put conditionss, and the ressulting action
ns for
each com
mbination of conditions. Each
E
column
n of the table
e corresponds to a busine
ess rule that
defines a unique com
mbination of conditions an
nd which res
sult in the exe
ecution of the actions
associated with that rule. The covverage stand
dard commonly used with
h decision table testing is
s to
have at least
l
one tesst per column
n in the table
e, which typic
cally involvess covering alll combination
ns of
triggering
g conditions..
Version 2011
2
Internationa
Q
Board
Page 40 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
The strength of decission table tessting is that itt creates com

mbinations of
o conditions that otherwis
se
might no
ot have been exercised during testing
g. It may be applied
a
to all situations w
when the actio
on of
the softw
ware depends on several logical decissions.
4.3.4
State Tra
ansition Te
esting (K3
3)
A system
m may exhibiit a different response de
epending on current cond
ditions or previous history
y (its
state). In
n this case, th
hat aspect off the system can be show
wn with a sta
ate transition diagram. It allows
a
the teste
er to view the
e software in terms of its states, trans
sitions betwee
en states, the inputs or events
e
that trigg
ger state cha
anges (transittions) and the actions wh
hich may result from thosse transitions
s. The
states off the system or object und
der test are separate,
s
ide
entifiable and
d finite in num
mber.
A state table shows the
t relationship between the states and
a inputs, an
nd can highliight possible
transition
ns that are in
nvalid.
Tests ca
an be designe
ed to cover a typical sequ
uence of states, to coverr every state,, to exercise every
transition
n, to exercise
e specific seq
quences of transitions
t
orr to test invalid transitionss.
State tra
ansition testin
ng is much used within th
he embedded
d software in
ndustry and technical
automation in genera
al. However, the techniqu
ue is also suitable for mo
odeling a bussiness object
having specific
s
statess or testing screen-dialog
s
gue flows (e..g., for Intern
net applicatio
ons or busine
ess
scenario
os).
4.3.5
Use Case
e Testing (K2)
Tests ca
an be derived
d from use ca
ases. A use case
c
describ
bes interactio
ons between actors (userrs or
systems), which prod
duce a resultt of value to a system use
er or the cusstomer. Use ccases may be
b
describe
ed at the absttract level (business use case, techno
ology-free, business
b
proccess level) or
o at
the syste
em level (sysstem use casse on the sysstem function
nality level). Each use ca
ase has
preconditions which need to be met
m for the usse case to work
w
successffully. Each use case
terminate
es with postcconditions which are the observable results
r
and final state of tthe system after
a
the use case
c
has bee
en completed
d. A use casse usually has a mainstre
eam (i.e., most likely) sce
enario
and alterrnative scena
arios.
es describe the
t processs flows throu
ugh a system
m based on itss actual likely use, so the
e test
Use case
cases de
erived from use
u cases are most usefu
ul in uncoverring defects in the processs flows durin
ng
real-worlld use of the system. Use
e cases are very
v
useful fo
or designing acceptance tests with
custome
er/user participation. Theyy also help uncover
u
integ
gration defects caused byy the interacttion
and interrference of different
d
components, which individua
al componentt testing wou
uld not see.
Designin
ng test casess from use ca
ases may be combined with
w other spe
ecification-ba
ased test
techniqu
ues.
Version 2011
2
Internationa
Q
Board
Page 41 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
4.4 Structu
ure-base
ed or Wh
hite-box
Techn
niques (K4)
60 minuttes
Terms
Code co
overage, deciision coverag
ge, statemen
nt coverage, structure-ba
ased testing
Backgrround
Structure
e-based or white-box
w
testing is based
d on an identtified structurre of the softtware or the
system, as seen in th
he following examples:
o Com
mponent level: the structu
ure of a softw
ware component, i.e., stattements, deccisions, branc
ches
or evven distinct paths
p
o Integ
gration level: the structure may be a call
c tree (a diagram in wh
hich moduless call other
modules)
e structure may
m be a men
nu structure, business prrocess or web page struc
cture
o Systtem level: the
In this se
ection, three code-related
d structural te
est design te
echniques for code coverrage, based on
o
statemen
nts, branches and decisio
ons, are disccussed. For decision
d
testting, a contro
ol flow diagra
am
may be used
u
to visua
alize the alte
ernatives for each
e
decisio
on.
4.4.1
Statemen
nt Testing
g and Cove
erage (K4)
In compo
onent testing
g, statement coverage is the assessm
ment of the pe
ercentage off executable
echnique derives
statemen
nts that have
e been exerccised by a tesst case suite. The statem
ment testing te
test case
es to execute
e specific sta
atements, normally to increase statem
ment coverag
ge.
Statement coverage is determine
ed by the num
mber of exec
cutable statements coverred by (desig
gned
or execu
uted) test casses divided by
b the numbe
er of all exec
cutable statem
ments in the code under test.
4.4.2
Decision
n Testing and
a Coverrage (K4)
Decision
n coverage, related
r
to bra
anch testing, is the asses
ssment of the
e percentage
e of decision
outcome
es (e.g., the True
T
and Fallse options of
o an IF statement) that ha
ave been exxercised by a test
case suite. The decission testing technique
t
de
erives test ca
ases to execu
ute specific d
decision outc
comes.
Branche
es originate frrom decision
n points in the
e code and show
s
the tran
nsfer of contrrol to differen
nt
locationss in the code
e.
Decision
n coverage iss determined
d by the numb
ber of all dec
cision outcom
mes covered by (designe
ed or
executed
d) test casess divided by the
t number of
o all possible
e decision ou
utcomes in th
he code under
test.
Decision
n testing is a form of conttrol flow testin
ng as it follow
ws a specificc flow of conttrol through the
t
decision points. Deciision coverag
ge is stronge
er than statem
ment coverag
ge; 100% de
ecision coverrage
guarante
ees 100% sta
atement cove
erage, but no
ot vice versa
a.
4.4.3
Other Structure-ba
ased Tech
hniques (K
K1)
There arre stronger le

evels of strucctural covera
age beyond decision
d
cove
erage, for exxample, cond
dition
coverage
e and multiple condition coverage.
c
The conccept of coverage can also be applied
d at other test levels For example, at the integration
level the percentage of modules, componentss or classes that have be
een exercised
d by a test ca
ase
suite cou
uld be expresssed as mod
dule, compon
nent or class coverage.
Tool sup
pport is usefu
ul for the stru
uctural testing
g of code.
Version 2011
2
Internationa
Q
Board
Page 42 of 78
31-Ma
ar-2011
International
esting
Software Te
Q
Qualifications
s Board
Certiffied Teste
er
Founda
4.5
Experie
ence-ba
ased Tecchniques
s (K2)
30 minuttes
Terms
Exploratory testing, (fault)
(
attack
Backgrround
Experien
nce-based te
esting is where tests are derived
d
from the testers skill and intu
uition and the
eir
experien
nce with similar applicatio
ons and technologies. Wh
hen used to augment
a
sysstematic
techniqu
ues, these tecchniques can
n be useful in
n identifying special testss not easily ccaptured by formal
f
techniqu
ues, especially when applied after mo
ore formal ap
pproaches. However, this technique may
m
yield wid
dely varying degrees
d
of effectiveness, depending on the testerrs experiencce.
A commonly used exxperience-ba
ased techniqu
ue is error gu
uessing. Gen
nerally testerrs anticipate
defects based
b
on exp
perience. A structured
s
ap
pproach to th
he error guesssing techniq
que is to
enumera
ate a list of possible defects and to de
esign tests th
hat attack the
ese defects. This systematic
approach is called fa
ault attack. Th
hese defect and failure lists can be built based on
n experience
e,
available
e defect and failure data, and from co
ommon know
wledge aboutt why softwarre fails.
Exploratory testing iss concurrent test design, test executio
on, test loggiing and learn
ning, based on
o a
test charrter containin
ng test objecttives, and ca
arried out within time-boxxes. It is an a
approach that is
most use
eful where th
here are few or inadequatte specificatiions and sevvere time pre
essure, or in order
o
to augme
ent or complement otherr, more forma
al testing. It can
c serve ass a check on the test proc
cess,
to help ensure
e
that th
he most serio
ous defects are
a found.
Version 2011
2
Internationa
Q
Board
Page 43 of 78
31-Ma
ar-2011
International
esting
Software Te
Q
Qualifications
s Board
Certiffied Teste
er
Founda
4.6
Choosiing Testt Techniques (K

K2)
15 minuttes
Terms
No specific terms.
Backgrround
The choice of which test techniqu
ues to use de
epends on a number of fa
actors, includ
ding the type
e of
system, regulatory sttandards, customer or co
ontractual req
quirements, level of risk, type of risk, test
objective
e, documenta
ation availab
ble, knowledg
ge of the testters, time and
d budget, de
evelopment liife
cycle, usse case models and prevvious experie
ence with types of defectss found.
Some techniques are
e more applicable to certtain situations and test levels; others are applicab
ble to
all test le
evels.
When crreating test cases,
c
testerss generally use
u a combin
nation of test techniques including pro
ocess,
rule and data-driven techniques to
t ensure adequate cove
erage of the object
o
under test.
Refere
ences
4.1 Craiig, 2002, Hettzel, 1988, IE
EEE STD 829-1998
4.2 Beizzer, 1990, Co
opeland, 200
04
4.3.1 Co
opeland, 200
04, Myers, 19
979
4.3.2 Co
opeland, 200
04, Myers, 19
979
4.3.3 Be
C
20
004
4.3.4 Be
C
20
004
4.3.5 Co
opeland, 200
04
4.4.3 Be
C
20
004
4.5 Kaner, 2002
4.6 Beizzer, 1990, Co
opeland, 200
04
Version 2011
2
Internationa
Q
Board
Page 44 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
5.
T
Test
Ma
anagem
ment (K3
3)
17
70 minu
utes
Learniing Objecctives forr Test Managemen

nt
The obje
t do followin
h module.
5.1 Tes
st Organizzation (K2)
LO-5.1.1
1
LO-5.1.2
2
LO-5.1.3
3
LO-5.1.4
4
Recognize the imporrtance of inde

ependent tes
sting (K1)
Explain the
t benefits and drawbaccks of indepe
endent testin
ng within an o
organization (K2)
Recognize the differe
ent team members to be considered for the creation of a test team
(K1)
Recall th
he tasks of a typical test leader
l
and te
ester (K1)
5.2 Tes
st Planning and Esttimation (K
K3)
LO-5.2.1
1
LO-5.2.2
2
LO-5.2.3
3
LO-5.2.4
4
LO-5.2.5
5
LO-5.2.6
6
LO-5.2.7
7
LO-5.2.8
8
LO-5.2.9
9
Recognize the differe

ent levels an
nd objectives of test plann
ning (K1)
Summarrize the purpose and content of the te
est plan, test design speccification and
d test
procedure documentts according to the Stand
dard for Softw
ware Test Documentatio
on
(IEEE Sttd 829-1998)) (K2)
n conceptuallly different te
est approach
hes, such as analytical, modelm
based, methodical,
m
p
process/stand
dard complia
ant, dynamic/heuristic, co
onsultative and
regressio
on-averse (K
K2)
n the subjectt of test planning for a syystem and sccheduling tes
st
executio
on (K2)
Write a test
t
execution schedule for
f a given se
et of test casses, considerring prioritiza
ation,
and tech
hnical and log
gical depend
dencies (K3)
List test preparation and executio
on activities that
t
should be
b considered during testt
planning
g (K1)
Recall tyypical factorss that influencce the effort related to testing (K1)
n two concep
ptually differe
ent estimatio
on approache
es: the metric
csbased ap
pproach and
d the expert-b
based approa
ach (K2)
Recognize/justify ade
equate entryy and exit critteria for speccific test leve
els and group
ps of
test case
es (e.g., for integration te
esting, accep
ptance testing
g or test case
es for usability
testing) (K2)
(
5.3 Tes
st Progres
ss Monitorring and Control
C
(K
K2)
LO-5.3.1
1
LO-5.3.2
2
LO-5.3.3
3
Recall co
ommon metrrics used for monitoring test preparation and execcution (K1)
Explain and
a compare
e test metricss for test rep
porting and te
est control (e
e.g., defects found
f
and fixed
d, and tests passed
p
and failed)
f
relate
ed to purpose
e and use (K
K2)
Summarrize the purpose and content of the te
est summaryy report document accord
ding to
the Stan
ndard for Sofftware Test Documentatio
D
on (IEEE Std 829-1998) (K2)
5.4 Configuratio
on Manage
ement (K2)
LO-5.4.1
1
Summarrize how configuration ma

anagement supports
s
testting (K2)
5.5 Ris
sk and Tes
sting (K2)
LO-5.5.1
1
LO-5.5.2
2
LO-5.5.3
3
LO-5.5.4
4
LO-5.5.5
5
Describe
e a risk as a possible pro
oblem that wo
ould threaten
n the achieve
ement of one
e or
more sta
akeholders project
p
objectives (K2)
Rememb
ber that the level of risk iss determined
d by likelihoo
od (of happen
ning) and impact
(harm re
esulting if it does happen)) (K1)
Distinguish between the project and
a product risks (K2)
Recognize typical product and prroject risks (K
K1)
Describe
e, using exam
mples, how risk
r analysis and risk man
nagement may be used for
f test
planning
g (K2)
Version 2011
2
Internationa
Q
Board
Page 45 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
5.6 Inc
cident Man
nagement (K3)
LO-5.6.1
1
LO-5.6.2
2
Recognize the conte

ent of an incid
dent report according
a
to the
t Standard
d for Softwarre
Test Doccumentation (IEEE Std 829-1998)
8
(K
K1)
Write an incident rep
port covering the observa
ation of a failu
ure during te
esting. (K3)
Version 2011
2
Internationa
Q
Board
Page 46 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
5.1
30 minuttes
Test Organizattion (K2)
Terms
Tester, test leader, te
est managerr
5.1.1
Test Org
ganization and Indep
pendence
e (K2)
The effectiveness of finding defects by testing

g and review
ws can be imp
proved by ussing independent
testers. Options
O
for in
ndependencce include the
e following:
o No in
ndependent testers; deve
elopers test their
t
own cod
de
o Inde
ependent testters within th
he developme
ent teams
o Inde
ependent testt team or gro
oup within the
e organizatio
on, reporting to project management or
o
execcutive manag
gement
o Inde
ependent testters from the
e business orrganization or
o user comm
munity
o Inde
ependent testt specialists for
f specific te
est types suc
ch as usability testers, se
ecurity testerrs or
certification teste
ers (who certtify a softwarre product ag
gainst standa
ards and regu
ulations)
o Inde
ependent testters outsourcced or extern
nal to the org
ganization
For large
e, complex or
o safety criticcal projects, it is usually best
b
to have multiple leve
els of testing, with
some or all of the levvels done by independent testers. Development staff
s
may partticipate in tes
sting,
especially at the lowe
er levels, butt their lack off objectivity often
o
limits th
heir effectiveness. The
independ
dent testers may have th
he authority to
o require and
d define test processes a
and rules, bu
ut
testers should
s
take on
o such process-related roles
r
only in the presence
e of a clear m
managementt
mandate
e to do so.
The benefits of indep
pendence incclude:
o Inde
ependent testters see othe
er and differe
ent defects, and
a are unbiased
o An in
ndependent tester can ve
erify assump
ptions people
e made during specificatio
on and
imple
ementation of
o the system
m
Drawbaccks include:
o Isola
ation from the
e developme
ent team (if trreated as tottally independent)
o Deve
elopers may lose a sense
e of responssibility for qua
ality
o Inde
ependent tessters may be seen as a bottleneck
b
or blamed for delays
d
in rele
ease
Testing tasks
t
may be
e done by pe
eople in a specific testing
g role, or mayy be done byy someone in
n
another role, such ass a project manager,
m
qua
ality managerr, developer, business an
nd domain ex
xpert,
infrastruccture or IT operations.
5.1.2
Tasks off the Test Leader an

nd Tester (K1)
(
In this syyllabus two te

est positionss are covered
d, test leaderr and tester. The activities and tasks
performe
ed by people
e in these two
o roles depen
nd on the pro
oject and pro
oduct contexxt, the people
e in the
roles, an
nd the organization.
Sometim
mes the test leader is called a test ma
anager or tes
st coordinatorr. The role off the test leader
may be performed
p
byy a project manager,
m
a de
evelopment manager, a quality
q
assurrance manag
ger or
the mana
ager of a tesst group. In la
arger projects two positio
ons may exist: test leaderr and test
managerr. Typically th
he test leade
er plans, mon
nitors and co
ontrols the testing activitie
es and tasks
s as
defined in
i Section 1.4.
Typical test
t
leader ta
asks may incclude:
o Coordinate the te
est strategy and
a plan with
h project managers and others
o
o Write
e or review a test strateg
gy for the pro
oject, and tes
st policy for th
he organizatiion
Version 2011
2
Internationa
Q
Board
Page 47 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
o
o
o
o
o
o
o
o
o
o
Conttribute the te
esting perspe
ective to othe
er project acttivities, such as integratio
on planning
Plan
n the tests considering
c
t context and
the
a understa
anding the test objectivess and risks
inclu
uding selectin
ng test appro
oaches, estim
mating the tim
me, effort and cost of testing, acquirin
ng
reso
ources, definiing test levels, cycles, an
nd planning in
ncident management
Initia
ate the speciffication, prep
paration, imp
plementation and execution of tests, m
monitor the te
est
results and checck the exit criteria
Adap
pt planning based
b
on tesst results and
d progress (sometimes do
ocumented in
n status repo
orts)
and take any acttion necessary to compen
nsate for pro
oblems
Set up
u adequate
e configuratio
on managem
ment of testwa
are for tracea
ability
Intro
oduce suitablle metrics forr measuring test progress
s and evalua
ating the qua
ality of the tes
sting
and the product
Deciide what sho
ould be autom
mated, to what degree, and how
Sele
ect tools to su
upport testing
g and organiize any trainiing in tool usse for testerss
Deciide about the
e implementa
ation of the te
est environm
ment
Write
e test summary reports based
b
on the
e information gathered du
uring testing
Typical tester
t
tasks may
m include:
o Reviiew and conttribute to testt plans
o Anallyze, review and assess user requirements, specifications and
d models forr testability
o Crea
ate test speccifications
o Set up
u the test environment (often
(
coordinating with system
s
administration and network
management)
o Prep
pare and acq
quire test data
o Implement tests on all test levels, execute
e and log the
e tests, evalu
uate the resu
ults and docu
ument
the deviations
d
fro
om expected
d results
o Use test adminisstration or ma
anagement tools and test monitoring tools as requ
uired
o Auto
omate tests (may be supp
ported by a developer
d
or a test autom
mation expertt)
o Mea
asure perform
mance of com
mponents and systems (iff applicable)
o Reviiew tests devveloped by others
o
People who
w work on test analysiss, test design
n, specific test types or te
est automatio
on may be
specialissts in these ro
oles. Depend
ding on the test
t
level and
d the risks re
elated to the p
product and the
project, different
d
peo
ople may take
e over the role of tester, keeping
k
som
me degree of independence.
Typicallyy testers at th
he componen
nt and integrration level would
w
be developers, testters at the
acceptan
nce test leve
el would be business expe
erts and use
ers, and teste
ers for operattional accepttance
testing would
w
be ope
erators.
Version 2011
2
Internationa
Q
Board
Page 48 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
5.2
Test Pllanning and Esttimation (K3)
40 minuttes
Terms
Test app
proach, test strategy
s
5.2.1
Test Plan
nning (K2))
This secction covers the

t purpose of
o test planning within de
evelopment and
a impleme
entation proje
ects,
and for maintenance
m
e activities. Planning mayy be documen
nted in a master test plan
n and in sepa
arate
test plan
ns for test levvels such as system testin
ng and acceptance testin
ng. The outlin
ne of a testplanning
g document iss covered byy the Standa
ard for Softwa
are Test Doccumentation (IEEE Std 8298
1998).
Planning
g is influence
ed by the testt policy of the
e organizatio
on, the scope
e of testing, o
objectives, risks,
constrain
nts, criticalityy, testability and
a the availlability of res
sources. As the project an
nd test plann
ning
progresss, more inform
mation becomes availablle and more detail can be
e included in
n the plan.
Test plan
nning is a co
ontinuous acttivity and is performed
p
in all life cycle processes a
and activities
s.
Feedbacck from test activities
a
is used
u
to recog
gnize changin
ng risks so th
hat planning can be adjusted.
5.2.2
Test Plan
nning Activities (K3
3)
Test plan
nning activities for an enttire system or
o part of a sy
ystem may in
nclude:
o Dete
ermining the scope and riisks and iden
ntifying the objectives
o
of testing
o Defin
ning the overall approach
h of testing, including
i
the
e definition off the test leve
els and entry
y and
exit criteria
c
o Integ
grating and coordinating
c
the testing activities
a
into the software
e life cycle acctivities
(acquisition, supply, developm
ment, operattion and maintenance)
o Makking decisionss about whatt to test, wha
at roles will perform
p
the te
est activities,, how the tes
st
activvities should be done, and how the te
est results willl be evaluate
ed
o Sche
eduling test analysis
a
and design activvities
o Sche
eduling test implementati
i
ion, executio
on and evalua
ation
o Assigning resourrces for the different
d
activvities defined
d
o Defin
ning the amo
ount, level off detail, struccture and tem
mplates for th
he test docum
mentation
o Sele
ecting metricss for monitorring and conttrolling test preparation
p
a execution
and
n, defect reso
olution
and risk issues
o Settiing the level of detail for test procedu
ures in order to provide en
nough inform
mation to sup
pport
repro
oducible testt preparation
n and executiion
5.2.3
Entry Criteria (K2))
Entry criteria define when

w
to startt testing such
h as at the beginning of a test level or when a sett of
tests is ready
r
for exe
ecution.
Typicallyy entry criteria may coverr the following:
o Testt environmen
nt availability and readine
ess
o Testt tool readine
ess in the tesst environment
o Testtable code avvailability
o Testt data availab
bility
5.2.4
Exit Crite
eria (K2)
Exit crite
eria define wh
hen to stop testing
t
such as at the end
d of a test levvel or when a set of tests
s has
achieved
d specific goa
al.
Version 2011
2
Internationa
Q
Board
Page 49 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
Typicallyy exit criteria may cover the

t following:
o Thorroughness measures,
m
such as covera
age of code, functionalityy or risk
o Estim
mates of defe
ect density or
o reliability measures
m
o Costt
o Resiidual risks, such as defeccts not fixed or lack of tes
st coverage in
i certain are
eas
o Sche
edules such as those bassed on time to
t market
5.2.5
Test Estiimation (K
K2)
Two app
proaches for the estimatio
on of test effo
ort are:
o The metrics-base
ed approach
h: estimating the testing effort
e
based on
o metrics off former or siimilar
ects or based
d on typical values
v
proje
o The expert-based approach: estimating the tasks bas
sed on estimates made b
by the owner of the
taskss or by experts
Once the
e test effort iss estimated, resources can
c be identiffied and a scchedule can b
be drawn up
p.
ay depend on
n a number of
o factors, inc
cluding:
The testing effort ma
o Characteristics of
o the producct: the qualityy of the speciification and other inform
mation used fo
or test
models (i.e., the test basis), the
t size of th
he product, th
he complexitty of the prob
blem domain, the
requ
uirements forr reliability an
nd security, and
a the requiirements for documentatiion
o Characteristics of
o the development proce
ess: the stabiility of the org
ganization, to
ools used, te
est
proccess, skills off the people involved,
i
and
d time pressure
o The outcome of testing:
t
the number
n
of de
efects and th
he amount off rework requ
uired
5.2.6
Test Stra
ategy, Tes
st Approac
ch (K2)
The test approach is the impleme

entation of th
he test strategy for a speccific project. The test app
proach
is define
ed and refined
d in the test plans and te
est designs. It typically inccludes the de
ecisions mad
de
based on
n the (test) projects
p
goall and risk asssessment. It is the startin
ng point for planning the test
t
process,, for selecting
g the test dessign techniqu
ues and test types to be applied, and
d for defining the
entry and
d exit criteria
a.
The sele
ected approa
ach depends on the conte
ext and may consider riskks, hazards a
and safety,
available
e resources and
a skills, the technologyy, the nature of the system (e.g., custtom built vs.
COTS), test
t
objective
es, and regu
ulations.
a
i
include:
Typical approaches
o Anallytical approa
aches, such as risk-base
ed testing where testing iss directed to areas of gre
eatest
risk
proaches, su
uch as stocha
astic testing using statisttical informattion about faiilure
o Model-based app
ratess (such as re
eliability grow
wth models) or
o usage (such as operattional profiless)
o Meth
hodical appro
oaches, such
h as failure-b
based (includ
ding error guessing and ffault attacks),
expe
erience-base
ed, checklist--based, and quality
q
chara
acteristic-bassed
o Proccess- or standard-complia
ant approach
hes, such as those speciffied by indusstry-specific
standards or the various agile
e methodolo
ogies
o Dyna
amic and heuristic approaches, such as explorato
ory testing where
w
testing is more reac
ctive to
even
nts than pre-planned, and
d where execcution and ev
valuation are
e concurrent tasks
o Conssultative app
proaches, such as those in which testt coverage iss driven primarily by the advice
a
and guidance of technology and/or
a
business domain experts outsside the test tteam
o Regression-averrse approach
hes, such as those that in
nclude reuse of existing test material,
extensive automation of funcctional regresssion tests, and
a standard
d test suites
Differentt approachess may be com
mbined, for example,
e
a risk-based dynamic appro
oach.
Version 2011
2
Internationa
Q
Board
Page 50 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
5.3 Test Prrogress Monitorring and Control

(K2)
20 minuttes
Terms
Defect density, failurre rate, test control,
c
test monitoring,
m
te
est summaryy report
5.3.1
Test Progress Mon

nitoring (K
K1)
The purp
pose of test monitoring
m
iss to provide feedback
f
and
d visibility ab
bout test activvities. Inform
mation
to be mo
onitored mayy be collected
d manually or automatica
ally and may be used to m
measure exitt
criteria, such
s
as cove
erage. Metriccs may also be
b used to assess progre
ess against tthe planned
schedule
e and budgett. Common test
t
metrics include:
o Perccentage of wo
ork done in test
t
case pre
eparation (or percentage of planned te
est cases
prep
pared)
o Perccentage of wo
ork done in test
t
environm
ment prepara
ation
o Testt case execution (e.g., nu
umber of testt cases run/n
not run, and test
t
cases pa
assed/failed))
o Defe
ect informatio
on (e.g., defe
ect density, defects
d
found
d and fixed, failure
f
rate, a
and re-test re
esults)
o Testt coverage off requiremen
nts, risks or code
c
o Subjjective confid
dence of testters in the prroduct
o Date
es of test mile
estones
o Testting costs, including the cost
c
compare
ed to the ben
nefit of finding the next de
efect or to run the
nextt test
5.3.2
Test Rep
porting (K2
2)
Test reporting is concerned with summarizing

g information
n about the te
esting endea
avor, includin
ng:
o Wha
at happened during a perriod of testing
g, such as da
ates when exxit criteria we
ere met
o Anallyzed informa
ation and me
etrics to supp
port recommendations an
nd decisions about future
e
actio
ons, such as an assessm
ment of defects remaining
g, the econom
mic benefit off continued
testing, outstand
ding risks, and the level of
o confidence
e in the tested
d software
The outline of a test summary rep
port is given in Standard
d for Software
e Test Docum
mentation (IEEE
Std 829--1998).
Metrics should
s
be co
ollected durin
ng and at the end of a tes
st level in ord
der to assesss:
o The adequacy off the test objectives for th
hat test level
o The adequacy off the test app
proaches takken
o The effectivenesss of the testiing with resp
pect to the ob
bjectives
5.3.3
Test Con
ntrol (K2)
Test con
ntrol describe
es any guidin
ng or correctiive actions ta
aken as a ressult of inform
mation and metrics
m
gathered
d and reporte
ed. Actions may
m cover an
ny test activitty and may affect
a
any oth
her software life
cycle acttivity or task..
Example
es of test con
ntrol actions include:
o Makking decisionss based on in
nformation frrom test mon
nitoring
o Re-p
prioritizing tests when an identified rissk occurs (e.g., software delivered latte)
nment
o Changing the tesst schedule due
d to availa
ability or unav
vailability of a test environ
o Settiing an entry criterion requ
uiring fixes to
o have been re-tested (confirmation ttested) by a
deve
eloper before
e accepting them into a build
b
Version 2011
2
Internationa
Q
Board
Page 51 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
5.4
Configu
uration Manage
M
ement (K
K2)
10 minuttes
Terms
Configurration manag
gement, verssion control
Backgrround
The purp
pose of configuration management is to establish and maintain the integritty of the prod
ducts
(compon
nents, data and
a documen
ntation) of the
e software orr system thro
ough the projject and prod
duct
life cycle
e.
For testing, configura
ation manage
ement may involve ensurring the following:
o All items of testw
ware are iden
ntified, versio
on controlled, tracked for changes, related to each
h other
and related to de
evelopment ittems (test ob
bjects) so tha
at traceabilityy can be maintained
throu
ughout the te
est process
o All id
dentified doccuments and software item
ms are refere
enced unambiguously in test
docu
umentation
For the tester,
t
config
guration management hellps to unique
ely identify (a
and to reprod
duce) the tes
sted
item, tesst documentss, the tests and the test harness(es).
h
During te
est planning,, the configurration manag
gement procedures and infrastructure
i
e (tools) shou
uld be
chosen, documented
d and implem
mented.
Version 2011
2
Internationa
Q
Board
Page 52 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
5.5
30 minuttes
Risk an
nd Testing (K2)
Terms
Product risk, project risk, risk, risk-based testting
Backgrround
Risk can
n be defined as the chancce of an even
nt, hazard, th
hreat or situa
ation occurrin
ng and resultting in
undesira
able consequ
uences or a potential
p
prob
blem. The level of risk will be determiined by the
likelihood
d of an adve
erse event ha
appening and
d the impact (the harm re
esulting from that event).
5.5.1
Project Risks
R
(K2))
Project risks
r
are the risks that surround the projects capa
ability to delivver its objecttives, such as:
o Orga
anizational fa
actors:
Skill, traiining and sta
aff shortagess
Personn
nel issues
Political issues, such
h as:
Problems with testers co
ommunicating
g their needss and test ressults
Failure by the team to follow up on in
nformation fo
ound in testin
ng and review
ws
(e.g., not imp
proving deve
elopment and
d testing pracctices)
Improper attitude tow
ward or expectations of te
esting (e.g., not
n appreciating the value of
finding defects
d
during
g testing)
o Tech
hnical issuess:
Problem
ms in defining the right req
quirements
The exte
ent to which requirements
r
s cannot be met given exxisting constrraints
Test envvironment no
ot ready on tim
me
Late data
a conversion
n, migration planning
p
and
d development and testing data
conversiion/migration
n tools
Low qua
ality of the de
esign, code, configuration
c
n data, test data and testss
o Supp
plier issues:
Failure of
o a third partty
Contracttual issues
When an
nalyzing, managing and mitigating
m
the
ese risks, the
e test manag
ger is followin
ng well-estab
blished
project management
m
t principles. The
T Standarrd for Software Test Docu
umentation ((IEEE Std 82
291998) ou
utline for testt plans requirres risks and
d contingenciies to be statted.
5.5.2
Product Risks (K2

2)
Potential failure area

as (adverse future
f
eventss or hazards)) in the software or system
m are known
n as
product risks,
r
as theyy are a risk to
o the quality of the produ
uct. These in
nclude:
o Failu
ure-prone software delive
ered
o The potential tha
at the softwarre/hardware could cause
e harm to an individual orr company
o Poorr software ch
haracteristicss (e.g., functionality, reliability, usability and perforrmance)
o Poorr data integriity and qualitty (e.g., data migration issues, data conversion
c
prroblems, data
a
transsport problem
ms, violation of data standards)
o Softw
ware that does not perforrm its intended functions
Risks are
e used to de
ecide where to
t start testin
ng and where
e to test more
e; testing is u
used to reduce the
risk of an
n adverse efffect occurring, or to reduce the impac
ct of an adve
erse effect.
Version 2011
2
Internationa
Q
Board
Page 53 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
Product risks are a special

s
type of
o risk to the success of a project. Tessting as a rissk-control acttivity
providess feedback ab
bout the residual risk by measuring th
he effectiven
ness of critica
al defect rem
moval
and of co
ontingency plans.
p
A risk-ba
ased approacch to testing provides pro
oactive oppo
ortunities to re
educe the levvels of produ
uct
risk, starrting in the in
nitial stages of
o a project. It
I involves the identificatio
on of producct risks and th
heir
use in gu
uiding test planning and control,
c
speccification, pre
eparation and
d execution o
of tests. In a riskbased ap
pproach the risks identifie
ed may be used to:
o Dete
ermine the te
est technique
es to be employed
o Dete
ermine the exxtent of testin
ng to be carrried out
o Priorritize testing in an attemp
pt to find the critical defec
cts as early as
a possible
o Dete
ermine wheth
her any non-ttesting activiities could be
e employed to
t reduce risk (e.g., proviiding
training to inexpe
erienced dessigners)
Risk-bassed testing draws on the collective kn
nowledge and
d insight of th
he project sta
akeholders to
t
determin
ne the risks and
a the levelss of testing required
r
to ad
ddress those
e risks.
To ensurre that the ch
hance of a product failure
e is minimize
ed, risk mana
agement actiivities provide a
discipline
ed approach to:
o Asse
ess (and reassess on a regular basis) what can go wrong (riskks)
o Dete
ermine what risks are imp
portant to deal with
o Implement action
ns to deal witth those risks
In additio
on, testing may
m support the
t identificattion of new risks,
r
may he
elp to determ
mine what risk
ks
should be
b reduced, and
a may lower uncertaintty about risks
s.
Version 2011
2
Internationa
Q
Board
Page 54 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
5.6
Inciden
nt Manag
gement (K3)
40 minuttes
Terms
Incident logging, incident manage
ement, incide
ent report
Backgrround
Since on
ne of the obje
ectives of tessting is to find
d defects, the discrepanccies between
n actual and
expected
d outcomes need
n
to be lo
ogged as inccidents. An in
ncident mustt be investiga
ated and may turn
out to be
e a defect. Ap
ppropriate acctions to disp
pose incidents and defeccts should be
e defined. Inc
cidents
and defe
ects should be
b tracked fro
om discoveryy and classification to corrrection and confirmation
n of the
solution. In order to manage
m
all in
ncidents to completion,
c
an
a organizatio
on should esstablish an in
ncident
management processs and rules for
f classificattion.
Incidentss may be raissed during development,, review, testting or use off a software product. The
ey may
be raised
d for issues in
i code or the working syystem, or in any
a type of documentatio
d
on including
requirem
ments, develo
opment docu
uments, test documents,
d
and user info
ormation succh as Help or
installatio
on guides.
Incident reports have
e the followin
ng objectivess:
o Provvide develope
ers and othe
er parties with
h feedback about
a
the pro
oblem to enable identifica
ation,
isola
ation and corrrection as ne
ecessary
o Provvide test lead
ders a meanss of tracking the quality of
o the system
m under test a
and the progress
of the testing
o Provvide ideas forr test processs improveme
ent
Details of
o the inciden
nt report mayy include:
o Date
e of issue, isssuing organizzation, and author
a
o Expe
ected and acctual results
o Identification of the
t test item (configuratio
on item) and environmentt
o Softw
ware or syste
em life cycle process in which
w
the inc
cident was ob
bserved
o Desccription of the incident to enable repro
oduction and
d resolution, including log
gs, database
e
dum
mps or screen
nshots
o Scop
pe or degree
e of impact on
n stakeholde
er(s) interests
s
o Seve
erity of the im
mpact on the system
o Urge
ency/priority to fix
o Statu
us of the inciident (e.g., open,
o
deferre
ed, duplicate,, waiting to be
b fixed, fixed
d awaiting re
e-test,
close
ed)
o Concclusions, reccommendatio
ons and apprrovals
o Glob
bal issues, su
uch as other areas that may
m be affectted by a change resulting
g from the inc
cident
o Change history, such as the sequence off actions take
en by projectt team memb
bers with res
spect
to the incident to
o isolate, repa
air, and conffirm it as fixed
d
o Refe
erences, inclu
uding the ide
entity of the test
t
case spe
ecification tha
at revealed tthe problem
The structure of an in
ncident report is also covvered in the Standard forr Software Te
est
Docume
entation (IEE
EE Std 829-1998).
Version 2011
2
Internationa
Q
Board
Page 55 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
Refere
ences
5.1.1 Black, 2001, Hetzel,
H
1988
5.1.2 Black, 2001, Hetzel,
H
1988
C
2002, IEEE
I
Std 829
9-1998, Kaner 2002
C
2002, Hetzel,
H
1988
8, IEEE Std 829-1998
8
5.4 Craiig, 2002
5.5.2 Black, 2001 , IEEE Std 829
9-1998
5.6 Blacck, 2001, IEE
EE Std 829-1
1998
Version 2011
2
Internationa
Q
Board
Page 56 of 78
31-Ma
ar-2011
International
esting
Software Te
Q
Qualifications
s Board
Certiffied Teste
er
Founda
6.
T
Tool
Su
upport for
f Testiing (K2))
8
80 minutes
Learniing Objecctives forr Tool Sup

pport for Testing
The obje
t do followin
h module.
6.1 Typ
pes of Tes
st Tools (K
K2)
LO-6.1.1
1
LO-6.1.3
3
Classify different types of test too

ols according
g to their purpose and to the activities
s of
the funda
amental testt process and
d the softwarre life cycle (K2)
(
Explain the
t term testt tool and the
e purpose of tool support for testing (K
K2) 2
6.2 Effe
ective Use
e of Tools
s: Potentia
al Benefits
s and Risk
ks (K2)
LO-6.2.1
1
LO-6.2.2
2
Summarrize the poten

ntial benefitss and risks off test automa
ation and too
ol support forr
testing (K
K2)
Rememb
ber special consideration
c
ns for test exe
ecution toolss, static analyysis, and tes
st
management tools (K
K1)
6.3 Intrroducing a Tool into

o an Orga
anization (K1)
LO-6.3.1
1
LO-6.3.2
2
LO-6.3.3
3
State the
e main princiiples of introd
ducing a tool into an orga
anization (K1
1)
State the
e goals of a proof-of-conc
p
cept for tool evaluation and a piloting phase for to
ool
impleme
entation (K1)
Recognize that facto
ors other than
n simply acquiring a tool are required for good too
ol
support (K1)
LO-6.1.2 Intentiona
ally skipped
Version 2011
2
Internationa
Q
Board
Page 57 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
6.1
Types of Test Tools

T
(K
K2)
45 minuttes
Terms
gement tool, coverage too
ol, debugging tool, dynam
mic analysis tool, inciden
nt
management tool, load testing to
ool, modeling
g tool, monito
oring tool, performance te
esting tool, probe
effect, re
equirements managemen
nt tool, review
w tool, security tool, staticc analysis tool, stress tes
sting
tool, testt comparatorr, test data prreparation to
ool, test desig
gn tool, test harness,
h
testt execution tool,
test man
nagement too
ol, unit test frramework too
ol
6.1.1
Tool Sup
pport for Testing
T
(K
K2)
Test toolls can be use

ed for one orr more activitties that support testing. These inclu
ude:
1. Tools that are dirrectly used in
n testing succh as test exe
ecution toolss, test data ge
eneration too
ols
and result compa
arison tools
2. Tools that help in
n managing the
t testing process such as those used to manag
ge tests, test
results, data, req
quirements, incidents, defects, etc., and for reportting and mon
nitoring test
execcution
3. Tools that are ussed in reconn
naissance, or, in simple terms:
t
explorration (e.g., ttools that mo
onitor
file activity
a
for an
n application))
4. Any tool that aidss in testing (a
a spreadshe
eet is also a test
t
tool in this meaning)
Tool sup
pport for testing can have
e one or more
e of the follow
wing purpose
es depending on the con
ntext:
o Imprrove the efficciency of testt activities byy automating repetitive ta
asks or suppo
orting manua
al test
activvities like testt planning, te
est design, te
est reporting and monitorring
o Auto
omate activitiies that require significan
nt resources when done manually
m
(e.g
g., static testting)
o Auto
omate activitiies that cann
not be executted manually
y (e.g., large scale perforrmance testin
ng of
clien
nt-server app
plications)
o Incre
ease reliabilitty of testing (e.g., by auto
omating large data comp
parisons or siimulating
beha
avior)
The term
m test frameworks is alsso frequently used in the industry, in at
a least three
e meanings:
o Reussable and exxtensible testting libraries that can be used to build
d testing toolls (called tes
st
harn
nesses as we
ell)
o A typ
pe of design of test autom
mation (e.g., data-driven,, keyword-driven)
o Overall process of execution of testing
For the purpose
p
of th
his syllabus, the term tesst framework
ks is used in its first two meanings as
s
describe
ed in Section 6.1.6.
6.1.2
Test Too
ol Classific
cation (K2
2)
There arre a number of tools that support diffe

erent aspects
s of testing. Tools
T
can be
e classified based
on severral criteria su
uch as purpose, commerccial / free / op
pen-source / shareware, technology used
and so fo
orth. Tools are
a classified in this syllab
bus according to the testiing activities that they support.
Some to
ools clearly su
upport one activity;
a
otherrs may suppo
ort more than
n one activityy, but are
classified
d under the activity
a
with which
w
they are most clos
sely associate
ed. Tools fro
om a single
provider, especially those
t
that ha
ave been dessigned to work together, may be bund
dled into one
e
package
e.
Some types of test to
ools can be intrusive, which means th
hat they can affect the acctual outcome
e of
the test. For example
e, the actual timing may be
b different due
d to the exxtra instructio
ons that are
executed
d by the tool,, or you mayy get a differe
ent measure of code cove
erage. The cconsequence
e of
intrusive
e tools is calle
ed the probe
e effect.
Version 2011
2
Internationa
Q
Board
Page 58 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
Some to
ools offer sup
pport more ap
ppropriate fo
or developers
s (e.g., tools that are used
d during
compone
ent and component integ
gration testing
g). Such tools are marke
ed with (D) iin the list bellow.
6.1.3
Tool Sup
pport for Manageme
M
ent of Testing and Tests
T
(K1)
Management tools apply to all tesst activities over

o
the entirre software life cycle.
Test Ma
anagement Tools
T
These to
ools provide interfaces for executing tests,
t
tracking defects an
nd managing requirementts,
along with support fo
or quantitative
e analysis an
nd reporting of the test objects. They also supporrt
he test objeccts to require
ement specifications and might have an
a independent version control
c
tracing th
capability or an interfface to an exxternal one.
Require
ements Mana
agement To
ools
These to
ools store req
quirement sta
atements, store the attrib
butes for the requirementts (including
priority), provide uniq
que identifierrs and suppo
ort tracing the
e requiremen
nts to individu
ual tests. Th
hese
ay also help with
w identifyin
ng inconsiste
ent or missing requirements.
tools ma
ent Tools (D
Defect Tracking Tools)
Incidentt Manageme
These to
ools store and manage in
ncident reporrts, i.e., defec
cts, failures, change requ
uests or perc
ceived
problemss and anoma
alies, and he
elp in managiing the life cy
ycle of incide
ents, optionally with supp
port for
statistica
al analysis.
Configu
uration Mana
agement Tools
Although
h not strictly test
t
tools, the
ese are nece
essary for sto
orage and ve
ersion manag
gement of
testware
e and related software especially whe
en configuring
g more than one hardware/software
environm
ment in termss of operating
g system verrsions, comp
pilers, browse
ers, etc.
6.1.4
Tool Sup
pport for Static
S
Testting (K1)
Static tessting tools prrovide a costt effective wa

ay of finding more defects at an earlie
er stage in th
he
developm
ment processs.
Review Tools
ools assist with review pro
ocesses, che
ecklists, revie
ew guideline
es and are ussed to store and
a
These to
commun
nicate review
w comments and
a report on
n defects and
d effort. Theyy can be of ffurther help by
b
providing
g aid for onlin
ne reviews fo
or large or ge
eographically
y dispersed teams.
t
Static Analysis
A
Too
ols (D)
These to
ools help devvelopers and testers find defects priorr to dynamic testing by providing support
for enforrcing coding standards (in
ncluding seccure coding), analysis of structures
s
an
nd dependen
ncies.
They can
n also help in
n planning orr risk analysiis by providin
ng metrics fo
or the code (e
e.g., complex
xity).
Modelin
ng Tools (D)
These to
ools are used
d to validate software mo
odels (e.g., physical data model (PDM
M) for a relational
database
e), by enume
erating incon
nsistencies and finding de
efects. These
e tools can o
often aid in
generating some test cases base
ed on the mo
odel.
6.1.5
Tool Sup
pport for Test
T
Speciification (K
K1)
Test Des
sign Tools
These to
ools are used
d to generate
e test inputs or executable tests and/o
or test oracle
es from
requirem
ments, graphiical user inte
erfaces, desig
gn models (s
state, data orr object) or ccode.
Version 2011
2
Internationa
Q
Board
Page 59 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
Test Datta Preparation Tools

Test data
a preparation
n tools manip
pulate databases, files or data transm
missions to set up test da
ata to
be used during the execution
e
of tests
t
to ensu
ure security th
hrough data anonymity.
6.1.6
Tool Sup
pport for Test
T
Execu
ution and Logging (K1)
(
Test Exe
ecution Too
ols
These to
ools enable te
ests to be exxecuted auto
omatically, orr semi-autom
matically, usin
ng stored inp
puts
and expe
ected outcom
mes, through
h the use of a scripting language and usually provvide a test log
g for
each tesst run. They can
c also be used
u
to recorrd tests, and usually support scripting
g languages or
GUI-bassed configura
ation for para
ameterization
n of data and
d other customization in th
he tests.
T
Framew
work Tools (D)
(
Test Harness/Unit Test
A unit test harness or
o framework facilitates th
he testing of components
c
or parts of a system by
ng the enviro
onment in wh
hich that test object will ru
un, through the provision of mock objects
simulatin
as stubss or drivers.
Test Comparators
Test com
mparators de
etermine diffe
erences betw
ween files, da
atabases or test
t
results. T
Test executio
on
tools typ
pically include
e dynamic co
omparators, but post-exe
ecution comp
parison may b
be done by a
separate
e comparison
n tool. A test comparator may use a te
est oracle, especially if itt is automate
ed.
ge Measurem
ment Tools (D)
Coverag
These to
ools, through intrusive or non-intrusive
e means, me
easure the pe
ercentage off specific types of
code stru
uctures that have been exercised
e
(e.g
g., statements, branchess or decisionss, and module or
function calls) by a set of tests.
Security
y Testing To
ools
These to
ools are used
d to evaluate
e the securityy characteristtics of softwa
are. This inccludes evalua
ating
the abilitty of the softw
ware to prote
ect data conffidentiality, in
ntegrity, authentication, a
authorization,,
availability, and non--repudiation. Security too
ols are mostly
y focused on
n a particular technology,
platform, and purposse.
6.1.7
Tool Sup
pport for Performan
P
nce and Mo
onitoring (K1)
Dynamic
c Analysis Tools
T
(D)
Dynamicc analysis too
ols find defeccts that are evident
e
only when
w
softwa
are is executiing, such as time
depende
encies or memory leaks. They are typ
pically used in componen
nt and compo
onent integra
ation
testing, and
a when tessting middlew
ware.
mance Testin
ng/Load Tes
sting/Stress Testing Too
ols
Perform
Performa
ance testing tools monito
or and report on how a sy
ystem behaves under a vvariety of sim
mulated
usage co
onditions in terms
t
of num
mber of concu
urrent users, their ramp-u
up pattern, frrequency and
d
relative percentage
p
o transaction
of
ns. The simu
ulation of load
d is achieved
d by means o
of creating viirtual
users ca
arrying out a selected set of transactio
ons, spread across
a
variou
us test mach
hines commo
only
known as
a load generrators.
Monitorring Tools
Monitorin
ng tools conttinuously ana
alyze, verify and report on usage of specific
s
syste
em resources
s, and
give warrnings of posssible service
e problems.
6.1.8
Tool Sup
pport for Specific
S
Te
esting Nee
eds (K1)
Data Qu
uality Assessment
Data is at
a the center of some pro
ojects such as data conve
ersion/migrattion projects and applicattions
like data
a warehousess and its attriibutes can va
ary in terms of criticality and
a volume. In such conttexts,
tools nee
ed to be emp
ployed for da
ata quality asssessment to
o review and verify the da
ata conversio
on and
Version 2011
2
Internationa
Q
Board
Page 60 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
migration
n rules to ensure that the
e processed data is corre
ect, complete
e and complie
es with a pre
edefined context-spec
c
cific standard
d.
Other tessting tools exxist for usabiility testing.
Version 2011
2
Internationa
Q
Board
Page 61 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
6.2 Effectivve Use of

o Tools: Poten
ntial
Benefits and Risks (K
K2)
20 minuttes
Terms
Data-drivven testing, keyword-driv
k
ven testing, scripting
s
lang
guage
6.2.1
(K2)
Potential Benefits and Risks

s of Tool Support
S
fo
or Testing
g (for all to
ools)
Simply purchasing
p
or leasing a to
ool does not guarantee success with that tool. Each type of to
ool
may requ
uire additional effort to acchieve real and
a lasting be
enefits. Therre are potenttial benefits and
a
opportun
nities with the
e use of toolss in testing, but
b there are
e also risks.
Potential benefits of using tools in
nclude:
o Repe
etitive work is
i reduced (e
e.g., running regression tests, re-ente
ering the sam
me test data, and
checcking againstt coding stan
ndards)
o Grea
ater consiste
ency and repe
eatability (e.g
g., tests exec
cuted by a to
ool in the sam
me order with
h the
same frequency,, and tests de
erived from requirements
r
s)
o Obje
ective assesssment (e.g., static measu
ures, coverag
ge)
o Ease
e of access to
t information
n about testss or testing (e
e.g., statisticcs and graphs about test
prog
gress, inciden
nt rates and performance
e)
Risks of using tools include:
o Unre
ealistic expecctations for th
he tool (inclu
uding functionality and ea
ase of use)
o Unde
erestimating the time, co
ost and effort for the initia
al introduction
n of a tool (in
ncluding train
ning
and external exp
pertise)
o Unde
erestimating the time and
d effort need
ded to achiev
ve significantt and continu
uing benefits from
the tool
t
(including the need fo
or changes in the testing
g process and
d continuouss improvement of
the way
w the tool is used)
o Unde
erestimating the effort required to ma
aintain the test assets generated by th
he tool
o Over-reliance on
n the tool (rep
placement fo
or test design
n or use of au
utomated tessting where
manual testing would
w
be bettter)
o Neglecting versio
on control off test assets within
w
the too
ol
o Neglecting relatio
onships and interoperabiility issues be
etween criticcal tools, such as requirem
ments
management too
ols, version control
c
tools, incident management to
ools, defect trracking tools
s and
toolss from multip
ple vendors
o Riskk of tool vend
dor going outt of business, retiring the tool, or sellin
ng the tool to
o a different
vend
dor
o Poorr response frrom vendor for
f support, upgrades,
u
an
nd defect fixe
es
o Riskk of suspension of open-ssource / free tool project
o Unfo
oreseen, succh as the inab
bility to support a new pla
atform
6.2.2
Special Considera
C
ations for Some Typ
pes of Too
ols (K1)
Test Exe
ecution Too
ols
Test exe
ecution tools execute testt objects usin
ng automated
d test scriptss. This type o
of tool often
requires significant effort
e
in orderr to achieve significant
s
be
enefits.
Capturin
ng tests by re
ecording the actions of a manual teste
er seems attractive, but tthis approach
h does
not scale
e to large numbers of auttomated test scripts. A ca
aptured scrip
pt is a linear rrepresentatio
on
with specific data and
d actions as part of each
h script. This type of scrip
pt may be unsstable when
unexpeccted events occur.
o
Version 2011
2
Internationa
Q
Board
Page 62 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
A data-d
driven testing
g approach separates outt the test inputs (the data
a), usually intto a spreadsheet,
and usess a more gen
neric test scrript that can read
r
the inpu
ut data and execute
e
the ssame test script
with diffe
erent data. Testers who are
a not familiiar with the scripting
s
lang
guage can then create the
e test
data for these predeffined scripts..
There arre other techniques employed in data
a-driven techniques, wherre instead off hard-coded data
combina
ations placed in a spreadssheet, data is generated using algoritthms based o
on configura
able
parameters at run tim
me and supplied to the ap
pplication. Fo
or example, a tool may use an algoritthm,
which ge
enerates a ra
andom user ID,
I and for re
epeatability in
n pattern, a seed
s
is emplloyed for
controllin
ng randomne
ess.
In a keyw
word-driven testing
t
appro
oach, the sprreadsheet co
ontains keyw
words describ
bing the actio
ons to
be taken
n (also called
d action word
ds), and test data. Testers
s (even if the
ey are not fam
miliar with th
he
scripting language) can
c then define tests usin
ng the keywo
ords, which can
c be tailore
ed to the
application being tessted.
Technica
al expertise in the scriptin
ng language is needed fo
or all approacches (either by testers orr by
specialissts in test auttomation).
Regardle
ess of the sccripting techn
nique used, th
he expected results for each
e
test nee
ed to be store
ed for
later com
mparison.
A
Too
ols
Static Analysis
Static an
nalysis tools applied to so
ource code can
c enforce coding
c
standards, but if a
applied to exiisting
code ma
ay generate a large quanttity of messa
ages. Warnin
ng messagess do not stop the code fro
om
being tra
anslated into an executab
ble program, but ideally should
s
be addressed so tthat maintena
ance
of the co
ode is easier in the future
e. A gradual implementatiion of the analysis tool w
with initial filte
ers to
exclude some messa
ages is an efffective appro
oach.
anagement Tools
T
Test Ma
Test management to
ools need to interface
i
with
h other tools or spreadsh
heets in order to produce useful
information in a format that fits th
he needs of the organizattion.
Version 2011
2
Internationa
Q
Board
Page 63 of 78
31-Ma
ar-2011
International
esting
Software Te
Q
Qualifications
s Board
Certiffied Teste
er
Founda
6.3 Introdu
ucing a Tool
T
into
o an Org
ganizatio
on
(K1)
15 minuttes
Terms
No specific terms.
Backgrround
The main considerattions in seleccting a tool fo
or an organiz
zation include
e:
o Asse
essment of organizationa
o
al maturity, sttrengths and
d weaknesses and identiffication of
oppo
ortunities for an improved
d test processs supported by tools
o Evaluation again
nst clear requ
uirements an
nd objective criteria
c
o A pro
oof-of-conce
ept, by using a test tool during the eva
aluation phasse to establissh whether itt
perfo
orms effectivvely with the software und
der test and within the cu
urrent infrastrructure or to
identify changes needed to th
hat infrastruccture to effec
ctively use th
he tool
o Evaluation of the
e vendor (inccluding trainin
ng, support and
a commerccial aspects)) or service support
s
supp
pliers in case
e of non-com
mmercial toolss
o Identification of internal requiirements for coaching an
nd mentoring in the use o
of the tool
o Evaluation of training needs considering the current test teams te
est automatio
on skills
o Estim
mation of a cost-benefit
c
r
ratio
based on
o a concrete
e business ca
ase
Introducing the seleccted tool into an organiza
ation starts with
w a pilot pro
oject, which has the follow
wing
objective
es:
o Learrn more deta
ail about the tool
t
o Evaluate how the
e tool fits with existing prrocesses and
d practices, and
a determin
ne what would
need
d to change
o Deciide on standard ways of using, mana
aging, storing
g and maintaining the too
ol and the tes
st
asse
ets (e.g., decciding on nam
ming conventtions for files
s and tests, creating
c
libraries and defining
the modularity
m
off test suites)
o Asse
ess whether the benefits will be achie
eved at reaso
onable cost
include:
Successs factors for the deployme
ent of the too
ol within an organization
o
o Rolling out the to
ool to the resst of the orga
anization incrrementally
o Adap
pting and improving proccesses to fit with
w the use of the tool
o Provviding training
g and coaching/mentorin
ng for new us
sers
o Defin
ning usage guidelines
g
o Implementing a way
w to gathe
er usage information from
m the actual use
u
o Monitoring tool use
u and bene
efits
o Provviding supporrt for the testt team for a given
g
tool
o Gath
hering lesson
ns learned fro
om all teamss
Refere
ences
6.2.2 Bu
uwalda, 2001
1, Fewster, 1999
1
6.3 Few
wster, 1999
Version 2011
2
Internationa
Q
Board
Page 64 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
7.
Referen
nces
Stand
dards
ISTQB Glossary
G
of Terms
T
used in Software Testing
T
Versiion 2.1
[CMMI] Chrissis,
C
M.B
B., Konrad, M.
M and Shrum
m, S. (2004) CMMI, Guidelines for Pro
ocess Integrration
and Prod
duct Improve
ement, Addisson Wesley: Reading, MA
A
See Secction 2.1
[IEEE Sttd 829-1998] IEEE Std 82
29 (1998) IEEE Standa
ard for Softw
ware Test Doccumentation,
See Secctions 2.3, 2.4
4, 4.1, 5.2, 5.3,
5 5.5, 5.6
[IEEE 10
028] IEEE Sttd 1028 (20
008) IEEE Standard for Software
S
Revviews and Au
udits,
See Secction 3.2
[IEEE 12
2207] IEEE 12207/ISO/IE
1
EC 12207-20
008, Software
e life cycle processes,
See Secction 2.1
[ISO 912
26] ISO/IEC 9126-1:2001
9
1, Software Engineering
E
Software Product
P
Quality,
See Secction 2.3
Bookss
[Beizer, 1990] Beizerr, B. (1990) Software
S
Tessting Techniq
ques (2nd ed
dition), Van N
Nostrand Reinhold:
Boston
3, 2.3, 4.2, 4.3,
4 4.4, 4.6
[Black, 2001]
2
Black, R. (2001) Ma
anaging the Testing Proc
cess (3rd ediition), John W
Wiley & Sons
s: New
York
2, 1.4, 1.5, 2.3,
2 2.4, 5.1, 5.2, 5.3, 5.5,, 5.6
[Buwalda
a, 2001] Buw
walda, H. et al.
a (2001) Inttegrated Test Design and
d Automation
n, Addison Wesley:
W
Reading, MA
See Secction 6.2
[Copelan
nd, 2004] Co
opeland, L. (2
2004) A Pracctitioners Gu
uide to Softw
ware Test Dessign, Artech
House: Norwood,
N
MA
A
3, 4.2, 4.3, 4.4,
4 4.6
[Craig, 2002]
2
Craig, Rick
R D. and Jaskiel,
J
Steffan P. (2002)) Systematic Software Te
esting, Artech
h
House: Norwood,
N
MA
A
See Secctions 1.4.5, 2.1.3,
2
2.4, 4.1, 5.2.5, 5.3, 5.4
[Fewsterr, 1999] Fewster, M. and Graham, D. (1999) Softw
ware Test Au
utomation, A
Addison Weslley:
Reading, MA
3
[Gilb, 1993]: Gilb, To
om and Graham, Dorothyy (1993) Software Inspection, Addison
n Wesley:
Reading, MA
See Secctions 3.2.2, 3.2.4
3
[Hetzel, 1988] Hetzel, W. (1988) Complete Guide
G
to Softw
ware Testing
g, QED: Welle
esley, MA
4, 1.5, 2.1, 2.2,
2 2.3, 2.4, 4.1,
4 5.1, 5.3
[Kaner, 2002]
2
Kaner,, C., Bach, J. and Petttico
ord, B. (2002
2) Lessons Learned
L
in So
oftware Testiing,
John Willey & Sons: New
N
York
5, 5.2
Version 2011
2
Internationa
Q
Board
Page 65 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
[Myers 1979] Myers, Glenford J. (1979) The Art

A of Softwa
are Testing, John
J
Wiley & Sons: New
w York
3, 2.2, 4.3
[van Vee
enendaal, 20
004] van Vee
enendaal, E. (ed.) (2004) The Testing
g Practitionerr (Chapters 6,
6 8,
10), UTN
N Publishers: The Netherrlands
3
Version 2011
2
Internationa
Q
Board
Page 66 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
8.
A
Append
dix A Syllabu
S
s Backg
ground
History
ry of this Documen
D
nt
This doccument was prepared
p
bettween 2004 and
a 2011 by
y a Working Group
G
comprrised of mem
mbers
appointe
ed by the Inte
ernational So
oftware Testing Qualificattions Board (ISTQB).
(
It w
was initially
reviewed
d by a selectted review pa
anel, and the
en by represe
entatives dra
awn from the internationa
al
software
e testing com
mmunity. The rules used in the produc
ction of this document
d
are
e shown in
Appendix C.
This doccument is the
e syllabus forr the Internattional Founda
ation Certificcate in Software Testing, the
first level internationa
al qualificatio
on approved by the ISTQ
QB (www.istqb.org).
Objectives of th
he Found
dation Ce
ertificate Qualificat
Q
tion
o
o
o
o
o
o
o
To gain
g
recognitiion for testing as an esse
ential and pro
ofessional so
oftware engin
neering
speccialization
To provide
p
a stan
ndard framew
work for the developmen
nt of testers' careers
c
To enable
e
professsionally qua
alified testerss to be recognized by employers, customers and peers,
p
and to raise the profile
p
of testers
To promote
p
conssistent and good testing practices
p
within all softwa
are engineerring discipline
es
To id
dentify testing topics thatt are relevantt and of value to industryy
To enable
e
softwa
are supplierss to hire certified testers and
a thereby gain
g
commercial advanta
age
overr their compe
etitors by advvertising their tester recru
uitment policyy
To provide
p
an op
pportunity forr testers and those with an
a interest in testing to accquire an
interrnationally re
ecognized qu
ualification in the subject
Objectives of th
he International Qualificatio
Q
on (adapted from ISTQB
meetin
ng at Solllentuna, Novembe
N
er 2001)
o
o
o
o
o
o
o
o
o
o
To be
b able to com
mpare testing skills acrosss different countries
c
To enable
e
testers to move accross countryy borders mo
ore easily
To enable
e
multin
national/intern
national projects to have a common understandin
u
ng of testing issues
To in
ncrease the number
n
of qu
ualified teste
ers worldwide
e
To have
h
more im
mpact/value as
a an interna
ationally-base
ed initiative than from anyy country-specific
apprroach
To develop
d
a com
mmon international bodyy of understanding and kn
nowledge ab
bout testing
throu
ugh the sylla
abus and term
minology, and to increase
e the level off knowledge about testing
g for
all pa
articipants
To promote
p
testing as a profe
ession in mo
ore countries
To enable
e
testers to gain a re
ecognized qu
ualification in
n their native language
To enable
e
sharin
ng of knowled
dge and reso
ources acros
ss countries
To provide
p
intern
national reco
ognition of tessters and this
s qualification due to parrticipation from
many countries
Entry Requirem
ments forr this Qua
alification
The entrry criterion fo
or taking the ISTQB Foun
ndation Certifficate in Softw
ware Testing
g examinatio
on is
that cand
didates have
e an interest in software testing.
t
Howe
ever, it is stro
ongly recommended thatt
candidattes also:
o Have
e at least a minimal
m
backkground in either software
e developme
ent or software testing, su
uch as
six months
m
experience as a system
s
or usser acceptanc
ce tester or as
a a software
e developer
Version 2011
2
Internationa
Q
Board
Page 67 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
Take
e a course th
hat has been accredited to
t ISTQB sta
andards (by one
o of the IS
STQB-recogn
nized
Natio
onal Boards)).
Backg
ground an
nd Historyy of the Foundatio
F
on Certificcate in So
oftware
Testin
ng
The inde
ependent cerrtification of software
s
testters began in
n the UK with
h the British C
Computer
Society'ss Information
n Systems Exxamination Board
B
(ISEB)), when a Software Testin
ng Board wa
as set
up in 199
98 (www.bcss.org.uk/iseb). In 2002, ASQF
A
in Germ
many began to support a German tes
ster
qualification scheme (www.asqf.d
de). This sylllabus is base
ed on the ISE
EB and ASQ
QF syllabi; it
includes reorganized
d, updated an
nd additionall content, and
d the empha
asis is directe
ed at topics that
will provide the mostt practical help to testers..
An existiing Foundation Certificate
e in Software
e Testing (e.g., from ISEB, ASQF or a
an ISTQBrecognizzed National Board) awarrded before this
t
Internatio
onal Certifica
ate was relea
ased, will be
deemed to be equiva
alent to the In
nternational Certificate. The
T Foundation Certificatte does not expire
e
and doess not need to
o be renewed
d. The date iti was awarded is shown on the Certificate.
Within ea
ach participa
ating countryy, local aspeccts are contro
olled by a na
ational ISTQB
B-recognized
d
Software
e Testing Boa
ard. Duties of
o National Boards are sp
pecified by th
he ISTQB, bu
ut are implem
mented
within ea
ach country. The duties of
o the countryy boards are expected to
o include accreditation of
training providers
p
and the setting
g of exams.
Version 2011
2
Internationa
Q
Board
Page 68 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
9. Append
A
dix B Learnin
L
ng Objec
ctives/C
Cognitiv
ve Level of
Know
wledge
The follo
owing learnin
ng objectives are defined as applying to this syllab
bus. Each top
pic in the syllabus
will be exxamined acccording to the
e learning ob
bjective for it..
Level 1: Remember (K1

1)
The cand
didate will re
ecognize, rem
member and recall a term
m or concept..
Keyword
ds: Rememb
ber, retrieve, recall, recog
gnize, know
Example
e
Can reco
ognize the de
efinition of fa
ailure as:
or
o Non
n-delivery of service to an
n end user or any other stakeholder
s
o Actu
ual deviation
n of the comp
ponent or sysstem from its
s expected delivery, service or result
Level 2: Underrstand (K2

2)
The cand
didate can se
elect the rea
asons or expllanations for statements related to the
e topic, and can
summarize, compare
e, classify, ca
ategorize and
d give examples for the testing
t
conce
ept.
Keyword
ds: Summarrize, generaliize, abstract,, classify, compare, map,, contrast, exxemplify, inte
erpret,
translate
e, represent, infer, conclu
ude, categorize, construct models
es
Example
Can exp
plain the reasson why testss should be designed
d
as early as posssible:
o To find defects when
w
they are
e cheaper to
o remove
o To find the most important de
efects first
Can exp
plain the similarities and differences
d
between integ
gration and system
s
testin
ng:
o Similarities: testing more than
n one compo
onent, and ca
an test non-ffunctional asspects
o Diffe
erences: integration testin
ng concentra
ates on interffaces and intteractions, an
nd system te
esting
conccentrates on whole-system aspects, such
s
as end--to-end proce
essing
Level 3: Apply (K3)

The cand
didate can se
elect the corrrect applicattion of a conc
cept or techn
nique and ap
pply it to a giv
ven
context.
Keyword
ds: Impleme
ent, execute, use, follow a procedure, apply a proccedure
Example
e
o Can identify boundary valuess for valid and invalid parrtitions
o Can select test cases
c
from a given state transition dia
agram in order to cover a
all transitions
s
Level 4: Analyzze (K4)

The cand
didate can se
eparate inforrmation relatted to a proce
edure or tech
hnique into itts constituen
nt parts
for better understand
ding, and can
n distinguish between fac
cts and infere
ences. Typiccal application is to
analyze a document,, software orr project situa
ation and pro
opose approp
priate actionss to solve a
problem or task.
Keyword
ds: Analyze,, organize, fin
nd coherencce, integrate, outline, parsse, structure,, attribute,
deconstrruct, differentiate, discrim
minate, disting
guish, focus,, select
Version 2011
2
Internationa
Q
Board
Page 69 of 78
31-Ma
ar-2011
International
esting
Software Te
Q
Qualifications
s Board
Certiffied Teste
er
Founda
e
Example
o Anallyze product risks and propose preve
entive and co
orrective mitig
gation activitties
o Desccribe which portions
p
of an
n incident report are factual and whicch are inferre
ed from results
Refere
ence
(For the cognitive levvels of learning objectivess)
Anderso
on, L. W. and Krathwohl, D. R. (eds) (2001) A Tax
xonomy for Learning, Tea
aching, and
Assessin
ng: A Revisio
on of Bloom'ss Taxonomyy of Education
nal Objective
es, Allyn & Bacon
Version 2011
2
Internationa
Q
Board
Page 70 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
10. Append
A
dix C Rules
R
A
Applied
to the ISTQB
Found
dation Syyllabus
The rules listed here were used in the develo
opment and review
r
of thiss syllabus. (A
A TAG is sh
hown
after eacch rule as a shorthand
s
ab
bbreviation of
o the rule.)
10.1.1 General Rules

SG1. The syllabus sh
hould be und
derstandable
e and absorb
bable by peop
ple with zero
o to six month
hs (or
more) exxperience in testing. (6-M
MONTH)
hould be pra
actical rather than theorettical. (PRACT
TICAL)
hould be clea
ar and unam
mbiguous to itts intended readers.
r
(CLE
EAR)
hould be und
derstandable
e to people frrom different countries, and easily
translata
able into diffe
erent languag
ges. (TRANS
SLATABLE)
hould use Am
merican English. (AMERICAN-ENGLISH)
10.1.2 Current Content

C
SC1. The syllabus sh
hould include
e recent testiing concepts
s and should reflect curre
ent best practtices
in softwa
are testing where this is generally
g
agrreed. The syllabus is sub
bject to review
w every three
e to
five yearrs. (RECENT
T)
SC2. The syllabus sh
hould minimiize time-relatted issues, such
s
as curre
ent market co
onditions, to
enable itt to have a sh
helf life of thrree to five ye
ears. (SHELF
F-LIFE).
10.1.3 Learning
g Objective
es
LO1. Lea
arning objecttives should distinguish between
b
item
ms to be reco
ognized/reme
embered (cognitive
level K1)), items the candidate
c
should understtand concepttually (K2), ittems the can
ndidate should be
able to practice/use
p
(
(K3),
and items the candidate should be able to use
u to analyzze a document,
software
e or project situation in co
ontext (K4). (KNOWLEDG
GE-LEVEL)
LO2. The
e description
n of the conte
ent should be
e consistent with the learrning objectivves. (LOCONSIS
STENT)
LO3. To illustrate the
e learning ob
bjectives, sam
mple exam questions for each major ssection shou
uld be
issued along
a
with the
e syllabus. (L
LO-EXAM)
10.1.4 Overall Structure

S
ST1. The
e structure of
o the syllabus should be clear and allow cross-refferencing to and from oth
her
parts, fro
om exam que
estions and from
f
other re
elevant documents. (CRO
OSS-REF)
ST2. Overlap betwee
en sections of
o the syllabu
us should be minimized. (OVERLAP)
ST3. Eacch section off the syllabuss should havve the same structure.
s
(STRUCTURE
E-CONSISTE
ENT)
ST4. The
e syllabus sh
hould contain
n version, da
ate of issue and
a page num
mber on everry page.
(VERSIO
ON)
ST5. The
e syllabus sh
hould include
e a guideline for the amou
unt of time to
o be spent in
n each sectio
on (to
reflect th
he relative im
mportance of each topic). (TIME-SPEN
NT)
Refere
ences
SR1. So
ources and re
eferences willl be given fo
or concepts in
n the syllabu
us to help training provide
ers
find out more
m
informa
ation about the topic. (RE
EFS)
SR2. Wh
here there arre not readilyy identified an
nd clear sources, more detail
d
should be provided in the
syllabus. For examplle, definitionss are in the Glossary,
G
so only the term
ms are listed in the syllab
bus.
(NON-REF DETAIL)
Version 2011
2
Internationa
Q
Board
Page 71 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
Source
es of Inforrmation
Terms used in the syyllabus are defined in the
e ISTQB Glos
ssary of Term
ms used in S
Software Testting. A
version of
o the Glossa
ary is availab
ble from ISTQ
QB.
A list of recommende
r
ed books on software tessting is also issued in parrallel with thiss syllabus. The
T
main boo
ok list is partt of the Referrences sectio
on.
Version 2011
2
Internationa
Q
Board
Page 72 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
11.
A
Appendi
ix D No
otice to Training
T
Providerrs
Each ma
ajor subject heading
h
in th
he syllabus iss assigned an
n allocated tiime in minute
es. The purp
pose of
this is bo
oth to give gu
uidance on th
he relative prroportion of time
t
to be allocated to ea
ach section of
o an
accredite
ed course, and to give an
n approximatte minimum time
t
for the teaching
t
of e
each section..
Training providers may spend mo
ore time than
n is indicated
d and candidates may spend more tim
me
again in reading and research. A course curriiculum does not have to follow the sa
ame order as
s the
syllabus.
The sylla
abus contains referencess to establish
hed standards, which musst be used in
n the prepara
ation
of trainin
ng material. Each
E
standarrd used musst be the vers
sion quoted in the currentt version of this
syllabus. Other publications, templates or sta
andards not referenced
r
in
n this syllabus may also be
b
used and
d referenced
d, but will nott be examine
ed.
All K3 an
nd K4 Learning Objective
es require a practical
p
exe
ercise to be in
ncluded in th
he training
materialss.
Version 2011
2
Internationa
Q
Board
Page 73 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
12.
A
Appendi
ix E Re
elease No
otes
Release 2010
1. C
Changes to Learning Ob
bjectives (LO) include som
me clarificatio
on
a. Wording
W
cha
anged for the
e following LO
Os (content and
a level of L
LO remains
unchanged):: LO-1.2.2, LO-1.3.1, LO--1.4.1, LO-1..5.1, LO-2.1.1, LO-2.1.3, LO2
2.4.2,
LO-4.1
1.3, LO-4.2.1
1, LO-4.2.2, LO-4.3.1, LO
O-4.3.2, LO-4
4.3.3, LO-4.4
4.1,
LO-4.4.2, LO
O-4.4.3, LO-4
4.6.1, LO-5.1
1.2, LO-5.2.2
2, LO-5.3.2, L
LO-5.3.3, LO
O5
5.5.2,
LO-5.6
6.1, LO-6.1.1
1, LO-6.2.2, LO-6.3.2.
b. LO-1.1.5 hass been reworrded and upg
graded to K2
2. Because a comparison
n of
t
terms
of defe
ect related te
erms can be expected.
c. LO-1.2.3 (K2
2) has been added.
a
The content wass already covvered in the 2007
2
s
syllabus.
d. LO-3.1.3 (K2
2) now comb
bines the con
ntent of LO-3.1.3 and LO--3.1.4.
e. LO-3.1.4 hass been removed from the
e 2010 syllab
bus, as it is p
partially redun
ndant
w LO-3.1.3.
with
f. LO-3.2.1 hass been reworrded for cons
sistency with
h the 2010 syyllabus conte
ent.
g. LO-3.3.2 hass been modiffied, and its level
l
has bee
en changed from K1 to K2,
K for
c
consistency
with LO-3.1.2.
h. LO 4.4.4 hass been modiffied for clarity
y, and has been changed
d from a K3 to
t a
K4. Reason
n: LO-4.4.4 had already been
b
written in
i a K4 mann
ner.
i. LO-6.1.2 (K1
1) was dropp
ped from the 2010 syllabu
us and was rreplaced with
h LO6
6.1.3
(K2). There
T
is no LO-6.1.2
L
in th
he 2010 sylla
abus.
2. Consistent
C
u for test approach acccording to the
use
e definition in
n the glossaryy. The term test
t
s
strategy
will not be required as term to
t recall.
3. Chapter
C
1.4 now contains the concep
pt of traceability between test basis and test cases.
4. Chapter
C
2.x now containss test objectss and test ba
asis.
5. Re-testing
R
iss now the ma
ain term in the glossary in
nstead of con
nfirmation tessting.
6. The
T aspect data
d
quality and
a testing has
h been add
ded at severa
al locations in the syllabu
us:
d
data
quality and
a risk in Chapter
C
2.2, 5.5,
5 6.1.8.
Reason: Consistency to Exit
7. Chapter
C
5.2.3 Entry Crite
eria are adde
ed as a new subchapter.
s
C
Criteria
(-> entry
e
criteria added to LO
O-5.2.9).
8. Consistent
C
u of the terrms test strattegy and testt approach with
use
w their definition in the
g
glossary.
9. Chapter
C
6.1 shortened be
ecause the tool
t
descriptions were too
o large for a 45 minute le
esson.
10. IEEE Std 829:2008 has been
b
release
ed. This vers
sion of the syyllabus does not yet consider
t
this
new edittion. Section 5.2 refers to
o the docume
ent Master Test Plan. The
e content of the
M
Master
Test Plan is cove
ered by the co
oncept that the
t documen
nt Test Plan covers diffe
erent
l
levels
of plan
nning: Test plans
p
for the test levels ca
an be create
ed as well as a test plan on
o the
p
project
level covering mu
ultiple test levvels. Latter is
s named Master Test Pla
an in this syllabus
a in the IS
and
STQB Glossa
ary.
11. Code
C
of Ethics has been moved from
m the CTAL to
o CTFL.
Release 2011
Changess made with the mainten
nance releasse 2011
1. General:
G
Wo
orking Party replaced
r
by Working
W
Gro
oup
2. Replaced
R
po
ost-conditionss by postcon
nditions in ord
der to be con
nsistent with the ISTQB
G
Glossary
2.1.
3. First
F
occurre
ence: ISTQB replaced by ISTQB
4. Introduction to this Syllab
bus: Descripttions of Cogn
nitive Levelss of Knowledg
ge removed,
b
because
thiss was redund
dant to Appendix B.
Version 2011
2
Internationa
Q
Board
Page 74 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
5. S
Section 1.6: Because the
e intent was not to define
e a Learning Objective forr the Code of
o
E
Ethics,
the cognitive
c
leve
el for the secction has bee
en removed.
6. Section
S
2.2.1
1, 2.2.2, 2.2.3 and 2.2.4, 3.2.3: Fixed formatting isssues in listss.
7. Section
S
2.2.2
2 The word failure
f
was no
ot correct forr isolate fa
ailures to a sspecific comp
ponent
. Thereforre replaced with
w defect in that sente
ence.
8. Section
S
2.3: Corrected fo
ormatting of bullet
b
list of test
t
objective
es related to test terms in
n
s
section
Test Types (K2).
9. Section
S
2.3.4
4: Updated description
d
off debugging to be consistent with Verrsion 2.1 of the
ISTQB Glosssary.
10. Section
S
2.4 removed
r
worrd extensive
e from inclu
udes extensivve regression
n testing,
b
because
the extensive depends on the change (size, risks, value,
v
etc.) a
as written in the
t
n
next
sentencce.
11. Section
S
3.2: The word in
ncluding hass been remov
ved to clarifyy the sentencce.
12. Section
S
3.2.1
1: Because the
t activities of a formal review
r
had been
b
incorrecctly formatted
d, the
r
review
proce
ess had 12 main
m
activitiess instead of six,
s as intend
ded. It has be
een changed
d back
t six, which makes this section
to
s
comp
pliant with th
he Syllabus 2007
2
and the
e ISTQB Advanced
L
Level
Syllabu
us 2007.
13. Section
S
4: Word
W
develop
ped replaced by defined
d because test cases ge
et defined an
nd not
d
developed.
14. Section
S
4.2: Text change
e to clarify ho
ow black-box
x and white-b
box testing co
ould be used
d in
c
conjunction
w experien
with
nce-based te
echniques.
15. Section
S
4.3.5
5 text change
e ..between actors, inclu
uding users and
a the syste
em.. to
b
between
acto
ors (users orr systems), .
16. Section
S
4.3.5
5 alternative path replace
ed by alterna
ative scenario
o.
17. Section
S
4.4.2
2: In order to
o clarify the te
erm branch testing
t
in the
e text of Secttion 4.4, a
s
sentence
to clarify the focus of brancch testing has
s been chang
ged.
18. Section
S
4.5, Section 5.2.6: The term experienced
d-based tessting has bee
en replaced by
b the
c
correct
term experience-based.
19. Section
S
6.1: Heading 6.1.1 Understa
anding the Meaning
M
and Purpose of T
Tool Supportt for
T
Testing
(K2) replaced byy 6.1.1 Tooll Support for Testing (K2).
20. Section
S
7 / Books:
B
The 3rd
3 edition of [Black,2001] listed, repla
acing 2nd edittion.
21. Appendix
A
D: Chapters re
equiring exerccises have been
b
replaced by the gen
neric requirem
ment
t
that
all Learn
ning Objectivves K3 and higher
h
require
e exercises. This is a req
quirement specified
i the ISTQB
in
B Accreditatio
on Process (Version
(
1.26
6).
22. Appendix
A
E: The change
ed learning objectives bettween Versio
on 2007 and 2010 are no
ow
c
correctly
liste
ed.
Version 2011
2
Internationa
Q
Board
Page 75 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
13.
Index
action word .............................................. 63

alpha tessting ...................................... 24, 27
architectture ................ 15, 21, 22, 25, 28, 29
archiving
g ............................................ 17, 30
automation ............................................... 29
benefits of independe
ence ....................... 47
benefits of using tooll ............................... 62
beta testting ........................................ 24, 27
37, 39, 40
black-bo
ox technique ....................
.
black-bo
ox test design
n technique ............. 39
black-bo
ox testing ...................................... 28
bottom-u
up................................................. 25
boundarry value analyysis ......................... 40
bug ........................................................... 11
captured
d script ......................................... 62
checklistts ........................................... 34, 35
choosing
g test techniq
que .......................... 44
code covverage ................. 28, 29, 37, 42, 58
commerccial off the sh
helf (COTS) ............ 22
compilerr ................................................... 36
complexxity .............................. 11, 36, 50, 59
compone
ent integratio
on testing22, 25, 29, 59,
60
compone
ent testing22
2, 24, 25, 27,, 29, 37, 41,
42
configura
ation management ......... 45, 48, 52
gement tool ............. 58
confirma
ation testing.... 13, 15, 16, 21, 28, 29
contract acceptance testing .................... 27
control fllow............................. 28, 36, 37, 42
coverage
e 15, 24, 28, 29, 37, 38, 39, 40, 42,
50, 51
1, 58, 60, 62
coverage
e tool ........................................... 58
custom-d
developed so
oftware.................... 27
data flow
w .................................................. 36
data-drivven approach
h .............................. 63
data-drivven testing ................................... 62
debuggin
ng .............................. 13, 24, 29, 58
debuggin
ng tool ................................... 24, 58
decision coverage .............................. 37, 42
decision table testing
g ........................ 40, 41
decision testing ........................................ 42
defect10
0, 11, 13, 14, 16, 18, 21, 24, 26, 28,
29, 31
1, 32, 33, 34, 35, 36, 37, 39, 40, 41,
43, 44
4, 45, 47, 49, 50, 51, 53, 54, 55, 59,
60, 69
9
defect de
ensity..................................... 50, 51
defect tra
acking tool................................... 59
developm
ment .. 8, 11, 12, 13, 14, 18, 21, 22,
24, 29
9, 32, 33, 36, 38, 44, 47, 49, 50, 52,
53, 55
5, 59, 67
...... 21, 22
developm
ment model ....................
.
drawbaccks of indepe
endence ................... 47
driver ........................................................ 24
ol ....................... 58, 60
dynamicc analysis too
Version 2011
2
Internationa
Q
Board
dy
ynamic testin
ng ..................... 13, 31, 32,
3 36
em
mergency ch
hange ................................. 30
en
nhancement .................................... 27,
2 30
en
ntry criteria ............................................. 33
eq
quivalence partitioning
p
.......................... 40
10, 11, 18, 43,
errror.................................. 1
4 50
errror guessing
g ............................. 18, 43,
4 50
ex
xhaustive tessting ................................... 14
ex
xit criteria13,, 15, 16, 33, 35, 45, 48, 49,
4 50,
51
ex
xpected resu
ult ...................... 16, 38, 48,
4 63
ex
xperience-ba
ased technique ....... 37, 39,
3 43
ex
xperience-ba
ased test dessign techniqu
ue 39
ex
xploratory tessting ............................. 43,
4 50
fa
actory accepttance testing
g ...................... 27
fa
ailure10, 11, 13, 14, 18, 2
21, 24, 26, 32
2, 36,
43, 46, 50, 51, 53, 54, 6
69
fa
ailure rate .......................................... 50,
5 51
fa
ault .............................................. 10, 11, 43
fa
ault attack ................................................ 43
fie
eld testing ......................................... 24,
2 27
fo
ollow-up ....................................... 33, 34,
3 35
fo
ormal review ....................
.
................. 31,
3 33
fu
unctional requ
uirement ...................... 24,
2 26
fu
unctional spe
ecification ............................ 28
fu
unctional taskk ......................................... 25
fu
unctional testt .......................................... 28
fu
unctional testting ..................................... 28
fu
unctionality ................ 24, 2
25, 28, 50, 53,
5 62
im
mpact analysis ........................... 21, 30,
3 38
incident ... 15, 16, 17, 19, 2
24, 46, 48, 55
5, 58,
59, 62
incident loggin
ng ....................................... 55
incident mana
agement.................. 48, 55,
5 58
incident mana
agement tool ................. 58,
5 59
incident reportt ................................... 46,
4 55
independence
e ............................. 18, 47,
4 48
informal review
w ............................ 31, 33,
3 34
inspection ............................... 31, 33, 34,
3 35
inspection leader ..................................... 33
integration13, 22, 24, 25, 2
27, 29, 36, 40, 41,
42, 45, 48, 59, 60, 69
integration tessting22, 24, 2
25, 29, 36, 40
0, 45,
59, 60, 69
interoperabilityy testing ............................. 28
introducing a tool
t
into an o
organization5
57, 64
IS
SO 9126 ................................ 11, 29, 30,
3 65
de
evelopment model
m
................................. 22
ite
erative-increm
mental development mod
del22
ke
eyword-drive
en approach........................ 63
ke
eyword-drive
en testing ............................ 62
kick-off ...................................................... 33
le
earning objecctive ... 8, 9, 10, 21, 31, 37
7, 45,
57, 69, 70, 71
lo
oad testing ................................... 28, 58,
5 60
Page 76 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
load testting tool........................................ 58

maintain
nability testing
g ............................. 28
maintena
ance testing ......................... 21, 30
management tool ................... 48, 58, 59, 63
maturity .................................. 17, 33, 38, 64
metric ........................................... 33, 35, 45
mistake ........................................ 10, 11, 16
modelling tool........................................... 59
moderator .................................... 33, 34, 35
monitorin
ng tool ................................... 48, 58
non-funcctional requirrement ......... 21, 24, 26
non-funcctional testing
g ....................... 11, 28
objective
es for testing ............................... 13
off-the-shelf .............................................. 22
operational acceptan
nce testing ............... 27
operational test ............................ 13, 23, 30
patch ........................................................ 30
peer review .................................. 33, 34, 35
...... 28, 58
performa
ance testing ....................
.
performa
ance testing tool ................... 58, 60
pesticide
e paradox..................................... 14
portabilitty testing ...................................... 28
probe eff
ffect .............................................. 58
procedurre................................................. 16
product risk
r ............................ 18, 45, 53, 54
project risk ................................... 12, 45, 53
prototyping ............................................... 22
quality 8,
8 10, 11, 13, 19, 28, 37, 38, 47, 48,
50, 53
3, 55, 59
rapid application devvelopment (R
RAD) ..... 22
Rational Unified Proccess (RUP) ............. 22
recorderr ................................................... 34
regressio
on testing ...... 15, 16, 21, 28, 29, 30
Regulation acceptance testing ............... 27
reliabilityy ..................... 11, 13, 28, 50, 53, 58
reliabilityy testing ....................................... 28
requirem
ment...................... 13, 22, 24, 32, 34
requirem
ments manag
gement tool .............. 58
requirem
ments specificcation ................ 26, 28
responsiibilities ............................. 24, 31, 33
re-testing
g . 29, See co
onfirmation testing,
t
See
confirm
mationtestingg
review13
3, 19, 31, 32, 33, 34, 35, 36, 47, 48,
53, 55
5, 58, 67, 71
review to
ool................................................ 58
reviewerr ............................................. 33, 34
risk11, 12, 13, 14, 25
5, 26, 29, 30,, 38, 44, 45,
49, 50
0, 51, 53, 54
risk-base
ed approach ............................... 54
risk-base
ed testing......................... 50, 53, 54
risks ....................................... 11, 25, 49, 53
risks of using
u
tool ..................................... 62
robustne
ess testing.................................... 24
roles ................ 8, 31, 33, 34, 35, 47, 48, 49
root causse .......................................... 10, 11
scribe ................................................. 33, 34
scripting language........................ 60, 62, 63
security ...................... 27, 28, 36, 47, 50, 58
Version 2011
2
Internationa
Q
Board
se
ecurity testing ........................................ 28
se
ecurity tool ........................................ 58,
5 60
simulators ................................................. 24
site acceptancce testing ........................... 27
so
oftware deve
elopment ............. 8, 11, 21,
2 22
so
oftware deve
elopment model .................. 22
sp
pecial consid
derations for some types of tool 62
te
est case ................................................... 38
sp
pecification-b
based technique..... 29, 39,
3 40
sp
pecification-b
based testing
g...................... 37
18, 26, 39, 45,
sttakeholders ... 12, 13, 16, 1
4 54
sttate transition
n testing ....................... 40,
4 41
sttatement covverage ................................ 42
sttatement testting ..................................... 42
sttatic analysiss .................................... 32,
3 36
sttatic analysiss tool ........... 3
31, 36, 58, 59,
5 63
sttatic techniqu
ue ................................. 31,
3 32
sttatic testing ....................................... 13, 32
........... 28, 58,
sttress testing ....................
.
5 60
sttress testing tool .............................. 58,
5 60
sttructural testiing .................... 24, 28, 29,
2 42
sttructure-base
ed technique
e ................ 39,
3 42
sttructure-base
ed test design technique .... 42
sttructure-base
ed testing ..................... 37,
3 42
sttub .......................................................... 24
su
uccess factors ....................................... 35
sy
ystem integra
ation testing ................. 22,
2 25
sy
ystem testing
g13, 22, 24, 2
25, 26, 27, 49,
4 69
te
echnical revie
ew .................... 31, 33, 34,
3 35
te
est analysis ........................... 15, 38, 48,
4 49
te
est approach ........................ 38, 48, 50,
5 51
te
est basis .................................................. 15
te
est case . 13, 14, 15, 16, 2
24, 28, 32, 37
7, 38,
39, 40, 41, 42, 45, 51, 5
55, 59, 69
te
est case speccification ................. 37, 38,
3 55
te
est cases ................................................. 28
te
est closure ................................... 10, 15, 16
....................... 38
te
est condition ....................
.
15, 16, 28, 38,
te
est conditionss ........... 13, 1
3 39
te
est control.................................... 15, 45,
4 51
te
est coverage .................................... 15, 50
te
est data ......... 15, 16, 38, 4
48, 58, 60, 62,
6 63
te
est data preparation tool .................. 58,
5 60
te
est design13,, 15, 22, 37, 38, 39, 43, 48,
4 58,
62
te
est design sp
pecification .......................... 45
te
est design tecchnique .................. 37, 38,
3 39
te
est design too
ol .................................. 58,
5 59
Te
est Developm
ment Processs ..................... 38
te
est effort .................................................. 50
17, 24, 26, 48,
te
est environme
ent . 15, 16, 1
4 51
te
est estimatio
on ....................................... 50
te
est execution
n13, 15, 16, 3
32, 36, 38, 43
3, 45,
57, 58, 60
te
est execution
n schedule .......................... 38
te
est execution
n tool ..... 16, 3
38, 57, 58, 60,
6 62
te
est harness...................... 1
16, 24, 52, 58,
5 60
te
est implemen
ntation ..................... 16, 38,
3 49
Page 77 of 78
31-Ma
ar-2011
International
Software Te
esting
Q
Qualifications
s Board
Certiffied Teste
er
Founda
der .............................. 18, 45, 47, 55

test lead
test lead
der tasks....................................... 47
test level. 21, 22, 24, 28, 29, 30, 37, 40, 42,
44, 45
5, 48, 49
test log ................................... 15, 16, 43, 60
test man
nagement ............................... 45, 58
test man
nagement too
ol ....................... 58, 63
test man
nager .................................. 8, 47, 53
test mon
nitoring ................................... 48, 51
test obje
ective ....... 13
3, 22, 28, 43, 44, 48, 51
test oraccle ................................................ 60
test orga
anization ...................................... 47
test plan
n .. 15, 16, 32
2, 45, 48, 49, 52, 53, 54
test plan
nning .............. 15, 16, 45, 49, 52, 54
test plan
nning activities ......................... 49
test proccedure ............ 15, 16, 37, 38, 45, 49
test proccedure speciffication .............. 37, 38
test prog
gress monitoring ......................... 51
test repo
ort........................................... 45, 51
test repo
orting ...................................... 45, 51
test scrip
pt ..................................... 16, 32, 38
test strattegy ............................................. 47
test suite
e .................................................. 29
test sum
mmary report ........
.
15, 16, 45, 48, 51
test tool classification
n .............................. 58
test type
e ........................... 21, 28, 30, 48, 75
test-drive
en developm
ment ......................... 24
tester 10
0, 13, 18, 34, 41, 43, 45, 47,
4 48, 52,
62, 67
7
tester tassks .............................................. 48
test-first approach .................................... 24
Version 2011
2
Internationa
Q
Board
te
esting and qu
uality ................................... 11
te
esting princip
ples ............................... 10, 14
15, 16, 17, 48,
te
estware............................ 1
4 52
to
ool support ...................... 2
24, 32, 42, 57,
5 62
to
ool support fo
or manageme
ent of testing
g and
tests ..................................................... 59
to
ool support fo
or performance and moniitoring 60
to
ool support fo
or static testin
ng ................... 59
to
ool support fo
or test execution and logg
ging60
to
ool support fo
or test speciffication ............ 59
to
ool support fo
or testing ...................... 57,
5 62
to
op-down .................................................. 25
tra
aceability .................................... 38, 48,
4 52
tra
ansaction pro
ocessing seq
quences ......... 25
ty
ypes of test to
ool ................................ 57,
5 58
un
nit test frame
ework ...................... 24, 58,
5 60
un
nit test frame
ework tool ..................... 58,
5 60
up
pgrades .................................................. 30
us
sability ...................... 11, 2
27, 28, 45, 47,
4 53
us
sability testin
ng ................................. 28,
2 45
us
se case test ....................
.
................. 37,
3 40
us
se case testing .......................... 37, 40,
4 41
us
se cases ............................... 22, 26, 28,
2 41
us
ser acceptan
nce testing .......................... 27
va
alidation .................................................. 22
ve
erification ................................................ 22
ve
ersion contro
ol ......................................... 52
V--model .................................................... 22
walkthrough .................................. 31, 33,
3 34
white-box testt design tech
hnique ....... 39,
3 42
white-box testting ............................... 28,
2 42
Page 78 of 78
31-Ma
ar-2011

3 Foundation Level Syllabus 2011

Uploaded by

Document Information

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

3 Foundation Level Syllabus 2011

Uploaded by

Copyright:

Available Formats

C

Certified Tester Foundation Levell Syllabus

Learniing Objecctives forr Fundam

1.1.3 Role of Testing

What iss Testing? (K2)

Seven Testing Principles (K2))

Test clossure activities collect data

Test clossure activities include the

Startt with collabo

Learniing Objecctives forr Testing Througho

2.1 Sofftware Dev

V-model (Sequential Develo

In any liffe cycle model, there are several characteristics of

Test Tyypes (K2

The funcctions that a system, subssystem or co

Learniing Objecctives forr Static Te

Recognize software work produccts that can be

Recall tyypical defectss and errors identified by

3.1 Static Techniq

A typicall formal revie

A typicall formal revie

Moderator: the person

Looking at software products

Types off Reviews (K2)

A single software pro

Successs factors for reviews

Learniing Objecctives forr Test Dessign Tech

Write tesst cases from

Classify test design techniques

Boundarry Value Analysis

Behaviorr at the edge

The strength of decission table tessting is that itt creates com

There arre stronger le

Choosiing Testt Techniques (K

Learniing Objecctives forr Test Managemen

Recognize the imporrtance of inde

Recognize the differe

Summarrize how configuration ma

Recognize the conte

Test Organizattion (K2)

The effectiveness of finding defects by testing

Tasks off the Test Leader an

In this syyllabus two te

Test Pllanning and Esttimation (K3)

This secction covers the

Entry Criteria (K2))

Entry criteria define when

Typicallyy exit criteria may cover the

The test approach is the impleme

5.3 Test Prrogress Monitorring and Control

Test Progress Mon

Test reporting is concerned with summarizing

Product Risks (K2

Potential failure area

Product risks are a special

Learniing Objecctives forr Tool Sup

Classify different types of test too

Summarrize the poten

6.3 Intrroducing a Tool into

Types of Test Tools

Test toolls can be use

There arre a number of tools that support diffe

Management tools apply to all tesst activities over

Static tessting tools prrovide a costt effective wa