Released Version Testing

(1)

Int

F

ternatio

ound

onal So

dation

R

Ver

ftware

n Lev

Released

rsion 201

Testing

vel Sy

11 g Qualif

yllabu

fication

us

ns Boarrd

(2)

This doc Copyrigh ISTQB is Copyrigh the ISTQ Copyrigh Klonk, R Copyrigh Friedenb Copyrigh Klaus Ol All rights The auth (ISTQB) have agr 1) Any auth and after Natio 2) Any othe copy 3) Any its tr cument may ht Notice © In s a registered ht © 2011 the QB WG Foun ht © 2010 the Rahul Verma) ht © 2007 the berg and Erik ht © 2005, th lsen, Maaret s reserved. hors hereby t . The author reed to the fo individual or ors and the provided tha r submission onal Board. individual or er derivative yright owners ISTQB-reco ranslation) to be copied in nternational d trademark e authors for ndation Leve e authors for ) e authors for k van Veene he authors (T Pyhäjärvi, G transfer the c rs (as current ollowing cond r training com ISTQB are at any adver n for official r group of in writings if th s of the sylla ognized Natio o other partie its entirety, Software Te of the Intern r the update l) r the update r the update ndaal) Thomas Mülle Geoff Thomp copyright to t t copyright h ditions of use mpany may u acknowledge rtisement of accreditatio ndividuals ma he authors a bus. onal Board m s. or extracts m esting Qualific national Softw 2011 (Thom 2010 (Thom 2007 (Thom er (chair), Re son and Erik

the Internatio olders) and I e:

use this sylla ed as the so such a train on of the tra

ay use this s and the IST may translate made, if the s cations Boar ware Testing as Müller (ch as Müller (ch as Müller (ch ex Black, Sig k van Veenen onal Softwar ISTQB (as th abus as the b ource and co ning course m aining mater syllabus as t QB are ack e this syllabu source is ack rd (hereinafte g Qualificatio hair), Debra hair), Armin B hair), Dorothy grid Eldh, Do ndaal). re Testing Qu he future cop

basis for a tra opyright own

may mention rials to an I the basis for nowledged a us and licens knowledged. er called IST ns Board, Friedenberg Beer, Martin y Graham, D rothy Graha ualifications pyright holde aining course ers of the sy n the syllabu ISTQB reco articles, boo as the sourc se the syllab QB®) , and Debra m, Board r) e if the yllabus us only gnized oks, or ce and bus (or

(3)

Version 2 © Internationa

Revis

Version ISTQB 2 ISTQB 2 ISTQB 2 ISTQB 2 ASQF V ISEB V2 2011 al Software Testing Q

ion Histo

D 2011 E 2010 E 2007 0 2005 0 2.2 J 2.0 2 Qualifications Board

ory

Date Effective 1-Ap Effective 30-M 01-May-2007 01-July-2005 July-2003 25-Feb-1999 pr-2011 Mar-2010 7 Page 3 of 7 Remarks Certified Maintena Notes Certified Maintena Notes Certified Maintena Certified ASQF Sy “Lehrplan ISEB Sof 25 Febru 78 s Tester Foun ance Release Tester Foun ance Release Tester Foun ance Release Tester Foun yllabus Foun n Grundlagen ftware Testin ary 1999 dation Level e – see Appe dation Level e – see Appe dation Level e dation Level dation Level n des Softwa ng Foundatio 31-Mar l Syllabus endix E – Re l Syllabus endix E – Re l Syllabus l Syllabus Version 2.2 are-testens“ on Syllabus V r-2011 elease elease V2.0

(4)

Acknowl Introduct Purpo The C Learn The E Accre Level How t 1. Fun 1.1 1.1 1.1 1.1 1.1 1.1 1.2 1.3 1.4 1.4 1.4 1.4 1.4 1.4 1.5 1.6 2. Tes 2.1 2.1 2.1 2.1 2.2 2.2 2.2 2.2 2.2 2.3 2.3 2.3 2.3 2.3 2.4 3. Sta 3.1 3.2 3.2 3.2 3.2 3.2 3.3 4. Tes 4.1 4.2 edgements.. tion to this S ose of this Do Certified Test ning Objective Examination . editation ... of Detail ... this Syllabus ndamentals o Why is Te .1 Softwa .2 Causes .3 Role of .4 Testing .5 How M What is T Seven Te Fundame 4.1 Test Pl 4.2 Test An 4.3 Test Im 4.4 Evalua 4.5 Test Cl The Psych Code of E sting Throug Software .1 V-mode .2 Iterative .3 Testing Test Leve 2.1 Compo 2.2 Integra 2.3 System 2.4 Accept Test Type 3.1 Testing 3.2 Testing 3.3 Testing 3.4 Testing Maintenan atic Techniqu Static Tec Review P 2.1 Activitie 2.2 Roles a 2.3 Types o 2.4 Succes Static Ana st Design Te The Test Categorie ... Syllabus ... ocument ... ter Foundatio es/Cognitive ... ... ... is Organize of Testing (K esting Neces re Systems C s of Software f Testing in S g and Quality uch Testing esting? (K2) sting Princip ntal Test Pro anning and C nalysis and D mplementatio

ting Exit Crit losure Activit hology of Te Ethics ... ghout the Sof Developmen el (Sequentia e-incrementa g within a Life els (K2) ... onent Testing ation Testing m Testing (K2 ance Testing es (K2) ... g of Function g of Non-func g of Software g Related to nce Testing ( ues (K2) ... chniques and rocess (K2) . es of a Form and Respons of Reviews ( ss Factors fo alysis by Too echniques (K Developmen es of Test De ... ... ... on Level in S Level of Kno ... ... ... d ... K2)... sary (K2) ... Context (K1) e Defects (K2 Software Dev y (K2) ... is Enough? ... ples (K2) ... ocess (K1) ... Control (K1) Design (K1) . on and Execu teria and Rep ties (K1) ... sting (K2) .... ... ftware Life C nt Models (K2 al Developm al Developm e Cycle Mod ... g (K2) ... (K2) ... 2) ... g (K2)... ... n (Functional ctional Softw e Structure/A Changes: Re (K2) ... ... d the Test Pr ... mal Review (K sibilities (K1) (K2) ... or Reviews (K ols (K2) ... K4) ... nt Process (K esign Techniq ... ... ... Software Tes owledge ... ... ... ... ... ... ... ) ... 2) ... velopment, M ... (K2) ... ... ... ... ... ... ution (K1) ... porting (K1) . ... ... ... Cycle (K2) ... 2) ... ent Model) ( ent Models ( el (K2) ... ... ... ... ... ... ... Testing) (K2 ware Characte Architecture ( e-testing and ... ... rocess (K2) .. ... K1) ... ) ... ... K2) ... ... ... K3) ... ques (K2) .... ... ... ... ting ... ... ... ... ... ... ... ... ... ... Maintenance ... ... ... ... ... ... ... ... ... ... ... ... ... ... K2) ... (K2) ... ... ... ... ... ... ... ... 2) ... eristics (Non Structural Te d Regression ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... and Operati ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... n-functional T esting) (K2) . n Testing (K2 ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ons (K2) ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... Testing) (K2) ... 2) ... ... ... ... ... ... ... ... ... ... ... ... ... ... 7 ... 8 ... 8 ... 8 ... 8 ... 8 ... 8 ... 9 ... 9 ... 10 ... 11 ... 11 ... 11 ... 11 ... 11 ... 12 ... 13 ... 14 ... 15 ... 15 ... 15 ... 16 ... 16 ... 16 ... 18 ... 20 ... 21 ... 22 ... 22 ... 22 ... 22 ... 24 ... 24 ... 25 ... 26 ... 26 ... 28 ... 28 ... 28 ... 29 ... 29 ... 30 ... 31 ... 32 ... 33 ... 33 ... 33 ... 34 ... 35 ... 36 ... 37 ... 38 ... 39

(5)

Version 2 © Internationa 4.3 4.3 4.3 4.3 4.3 4.3 4.4 4.4 4.4 4.4 4.5 4.6 5. Tes 5.1 5.1 5.1 5.2 5.2 5.2 5.2 5.2 5.2 5.2 5.3 5.3 5.3 5.3 5.4 5.5 5.5 5.5 5.6 6. Too 6.1 6.1 6.1 6.1 6.1 6.1 6.1 6.1 6.1 6.2 6.2 6.2 6.3 7. Re Stand Books 8. Ap Histor Objec Objec Novem Entry 2011 al Software Testing Q Specificat 3.1 Equiva 3.2 Bounda 3.3 Decisio 3.4 State T 3.5 Use Ca Structure-4.1 Statem 4.2 Decisio 4.3 Other S Experienc Choosing st Managem Test Orga .1 Test O .2 Tasks o Test Plan 2.1 Test Pl 2.2 Test Pl 2.3 Entry C 2.4 Exit Cr 2.5 Test Es 2.6 Test St Test Prog 3.1 Test Pr 3.2 Test Re 3.3 Test Co Configura Risk and T 5.1 Project 5.2 Produc Incident M ol Support fo Types of T .1 Tool Su .2 Test To .3 Tool Su .4 Tool Su .5 Tool Su .6 Tool Su .7 Tool Su .8 Tool Su Effective U 2.1 Potenti 2.2 Specia Introducin ferences ... dards ... s... pendix A – S ry of this Doc ctives of the F ctives of the I mber 2001) .. Requiremen Qualifications Board tion-based or lence Partitio ary Value An on Table Tes Transition Te ase Testing ( -based or Wh ment Testing a on Testing an Structure-bas ce-based Tec Test Techni ent (K3) ... anization (K2 rganization a of the Test L ning and Est anning (K2) anning Activ Criteria (K2) . iteria (K2) .... stimation (K2 trategy, Test gress Monitor rogress Mon eporting (K2 ontrol (K2) ... ation Manage Testing (K2) t Risks (K2) . ct Risks (K2) Management or Testing (K2 Test Tools (K upport for Te ool Classifica upport for Ma upport for Sta upport for Te upport for Te upport for Pe upport for Sp Use of Tools al Benefits a l Considerat ng a Tool into ... ... ... Syllabus Bac cument ... Foundation C International ... nts for this Qu r Black-box T oning (K3) ... nalysis (K3) .. sting (K3) ... sting (K3) .... (K2) ... hite-box Tec and Coverag nd Coverage sed Techniqu chniques (K2 iques (K2) .... ... 2) ... and Independ Leader and T timation (K3) ... vities (K3) ... ... ... 2) ... t Approach (K

ring and Con itoring (K1) .. ) ... ... ement (K2) ... ... ... ... (K3) ... 2)... K2) ... esting (K2) ... ation (K2) ... anagement o atic Testing est Specificat est Execution erformance a pecific Testin s: Potential B and Risks of

ions for Som o an Organiz ... ... ... kground ... ... Certificate Q Qualification ... ualification ... Page 5 of 7 Techniques ( ... ... ... ... ... hniques (K4 ge (K4) ... e (K4) ... ues (K1) ... 2) ... ... ... ... dence (K2) .. Tester (K1) ... ) ... ... ... ... ... ... K2) ... ntrol (K2) ... ... ... ... ... ... ... ... ... ... ... ... ... of Testing an (K1) ... tion (K1) ... n and Loggin and Monitorin ng Needs (K1 Benefits and Tool Suppor me Types of T zation (K1) ... ... ... ... ... ... ualification .. n (adapted fr ... ... 78 (K3) ... ... ... ... ... ... 4) ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... nd Tests (K1) ... ... ng (K1) ... ng (K1) ... 1) ... Risks (K2) .. rt for Testing Tools (K1) .... ... ... ... ... ... ... ... rom ISTQB m ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ) ... ... ... ... ... ... ... (for all tools ... ... ... ... ... ... ... ... meeting at So ... ... 31-Mar ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... s) (K2) ... ... ... ... ... ... ... ... ... ollentuna, ... ... r-2011 ... 40 ... 40 ... 40 ... 40 ... 41 ... 41 ... 42 ... 42 ... 42 ... 42 ... 43 ... 44 ... 45 ... 47 ... 47 ... 47 ... 49 ... 49 ... 49 ... 49 ... 49 ... 50 ... 50 ... 51 ... 51 ... 51 ... 51 ... 52 ... 53 ... 53 ... 53 ... 55 ... 57 ... 58 ... 58 ... 58 ... 59 ... 59 ... 59 ... 60 ... 60 ... 60 ... 62 ... 62 ... 62 ... 64 ... 65 ... 65 ... 65 ... 67 ... 67 ... 67 ... 67 ... 67

(6)

9. Ap Level Level Level Level 10. A Found 10. 10. 10. 10. 11. A 12. A Relea Relea 13. pendix B – L 1: Rememb 2: Understa 3: Apply (K3 4: Analyze ( Appendix C – dation Syllab .1.1 Genera .1.2 Curren .1.3 Learnin .1.4 Overall Appendix D – Appendix E – ase 2010 ... ase 2011 ... Index ... Learning Obje er (K1) ... nd (K2) ... 3) ... (K4) ... – Rules App bus ... al Rules ... t Content .... ng Objectives l Structure ... – Notice to T – Release N ... ... ... ectives/Cogn ... ... ... ... plied to the IS ... ... ... s ... ... Training Prov otes ... ... ... ... nitive Level o ... ... ... ... STQB ... ... ... ... ... ... viders ... ... ... ... ... of Knowledge ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... e ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 69 ... 69 ... 69 ... 69 ... 69 ... 71 ... 71 ... 71 ... 71 ... 71 ... 71 ... 73 ... 74 ... 74 ... 74 ... 76

(7)

Ackno

Internatio Thomas Armin Be Schaefe the curre Internatio Thomas review te Tuula Pä Veenend Internatio Thomas team tha Petterss Internatio Thomas Geoff Th suggesti 2011 al Software Testing Q

owledge

onal Softwar Müller (chai eer, Rex Bla r, Stephanie ent version o onal Softwar Müller (chai eam (Rex Bla ääkkönen, M daal) and all onal Softwar Müller (chai anks the revie

on, and Won onal Softwar Müller (chai hompson and ons. Qualifications Board

ments

re Testing Qu r), Debra Fri ck, Julie Gar Ulrich, Erik of the syllabu re Testing Qu r), Rahul Ve ack, Mette B Meile Posthum National Boa re Testing Qu r), Dorothy G ew team (Ha nil Kwon) and re Testing Qu r), Rex Black d Erik van Ve ualifications edenberg. T rdiner, Judy van Veenen s. ualifications rma, Martin K Bruhn-Peders ma, Hans Sc ards for their ualifications Graham, Deb ans Schaefer d all the Nati ualifications k, Sigrid Eldh eenendaal an

Page 7 of 7 Board Work The core team

McKay, Tuul daal) and all

Board Work Klonk and Ar son, Debra F chaefer, Step r suggestions Board Work bra Friedenb r, Stephanie onal Boards Board Work h, Dorothy G nd the review 78 ing Group Fo m thanks the la Pääkköne National Bo ing Group Fo rmin Beer. T Friedenberg, phanie Ulrich s. ing Group Fo erg, and Erik Ulrich, Meile for their sug ing Group Fo Graham, Klau w team and a oundation Le review team en, Eric Riou oards for the

oundation Le The core team

Klaus Olsen , Pete William oundation Le k van Veene e Posthuma, ggestions. oundation Le us Olsen, Ma all National B 31-Mar evel (Edition m (Dan Almog du Cosquier suggestions evel (Edition m thanks the n, Judy McKa ms, Erik van evel (Edition ndaal. The c Anders evel (Edition aaret Pyhäjär Boards for th r-2011 2011): g, r Hans for 2010): ay, 2007): core 2005): rvi, eir

(8)

Introd

Purpo

This sylla Level. Th Boards f language for accre Informat

The C

The Fou people in acceptan for anyo manager consulta testing q

Learni

Learning o K1: r o K2: u o K3: a o K4: a Further d All terms explicitly

The E

The Fou examina syllabus The form Exams m examina requisite

Accred

An ISTQ syllabus performs is allowe Further g

duction

ose of this

abus forms t he Internatio for them to a e. Training p editation. Th ion on the hi

Certified T

ndation Leve n roles such nce testers a ne who want rs, software ants. Holders qualification.

ing Objec

g objectives a remember understand apply analyze details and e s listed unde y mentioned

Examinatio

ndation Leve ation question . All sections mat of the exa

may be taken ation center o e for the exam

ditation

QB National B . Training pro s the accredi ed to have an guidance for

n to this

s Docume

the basis for onal Software ccredit the tr providers will e syllabus w story and ba

Tester Fo

el qualificatio as testers, te and software ts a basic un developmen of the Foun

ctives/Co

are indicated examples of l r “Terms” jus in the learnin

on

el Certificate ns may requ s of the syllab amination is n as part of a or in a public m. Board may a oviders shou tation. An ac n ISTQB exa training prov

s Syllab

ent

the Internati e Testing Qu raining provid determine a will help cand ackground of

undation

on is aimed a est analysts, developers. nderstanding nt managers, dation Certif

ognitive L

d for each se learning obje st below chap ng objectives examination ire the use o bus are exam

multiple cho an accredited exam). Com

ccredit traini uld obtain acc

ccredited cou amination as viders is give

us

onal Softwar alifications B ders and to d appropriate te idates in the f the syllabus

Level in

at anyone inv , test enginee This Founda of software business an ficate will be

evel of K

ction in this s ectives are g pter heading s. n will be base of material ba minable. oice. d training cou mpletion of a ng providers creditation g urse is recog part of the c en in Append re Testing Q Board (ISTQB derive exami eaching meth ir preparatio s can be foun

Software

volved in soft ers, test cons ation Level q testing, such nalysts, IT dir able to go on

Knowledge

syllabus and iven in Appe gs shall be re ed on this sy ased on more urse or taken an accredited s whose cour uidelines fro gnized as con ourse. dix D. ualification a B) provides i nation quest hods and pro

n for the exa nd in Append

e Testing

tware testing sultants, test qualification i h as project m rectors and m n to a higher

e

d classified as endix B. emembered ( yllabus. Answ e than one s n independen d training cou rse material f m the board nforming to t at the Founda t to the Natio tions in their oduce course amination. dix A. g. This includ t managers, is also appro managers, q managemen r-level softwa s follows: (K1), even if wers to ection of this ntly (e.g., at a urse is not a follows this or body that his syllabus, ation onal local eware des user opriate uality t are not s an pre-t and

(9)

Level

The leve order to o Gen o A lis requ o Lear mind o A lis o A de stan The sylla the level

How th

There ar learning example

2. Tes

This hea shown) a chapter. objective within th 2011 al Software Testing Q

of Detail

el of detail in achieve this eral instructi t of informati uired rning objectiv dset to be ac t of terms tha escription of t dards abus content of detail to b

his Syllab

re six major c objectives th e:

sting Thr

ading shows and K2 (but n Within each es and the am

e time for the

Qualifications Board this syllabus goal, the sy onal objectiv ion to teach, ves for each chieved

at students m the key conc

t is not a des be covered in

bus is Or

chapters. Th hat is covere

roughout

that Chapter not K3), and chapter the mount of time e section. s allows inter llabus consis ves describin including a d knowledge a must be able cepts to teac scription of th n Foundation

rganized

e top-level h ed within the

t the Sof

r 2 has learn it is intended re are a num e required. S Page 9 of 7 rnationally co sts of: ng the intentio description, a area, describ e to recall and h, including s he entire kno n Level traini heading for e chapter and

ftware Li

ing objective d to take 115 mber of sectio Subsections 78 onsistent tea on of the Fou and referenc bing the cogn d understand sources such owledge area ing courses. ach chapter specifies the

fe Cycle

es of K1 (ass 5 minutes to ons. Each se that do not h ching and ex undation Lev ces to additio nitive learnin d h as accepte a of software shows the h e time for the

(K2)

sumed when teach the m ection also ha have a time g 31-Mar xamination. I vel onal sources g outcome a ed literature o testing; it ref highest level e chapter. Fo

115 min

a higher lev aterial in the as the learni given are inc

r-2011 n if and or flects of or

nutes

el is e ng luded

(10)

1. Learni

The obje

1.1 Wh

LO-1.1.1 LO-1.1.2 LO-1.1.3 LO-1.1.4 LO-1.1.5

1.2 Wh

LO-1.2.1 LO-1.2.2 LO-1.2.3

1.3 Sev

LO-1.3.1

1.4 Fun

LO-1.4.1

1.5 The

LO-1.5.1 LO-1.5.2

Fundam

ing Objec

ectives identi

hy is Testi

1 Describe person, t 2 Distingu 3 Give rea 4 Describe contribut 5 Explain a mistake

hat is Test

1 Recall th 2 Provide cycle (K2 3 Different

ven Testin

1 Explain t

ndamenta

1 Recall th (K1)

e Psychol

1 Recall th 2 Contrast

mentals

ctives for

fy what you

ng Necess

e, with exam to the enviro ish between asons why te e why testing tes to higher and compare

and bug, usi

ing? (K2)

he common o examples fo 2) tiate testing f

ng Princip

the seven pr

al Test Pro

he five funda

ogy of Tes

he psycholog t the mindset

of Test

r Fundam

will be able t

sary? (K2

ples, the way onment or to

the root cau sting is nece g is part of qu r quality (K2) e the terms e ing examples objectives of r the objectiv from debugg

ples (K2)

rinciples in te

ocess (K1)

mental test a

sting (K2)

gical factors t t of a tester a

ting (K2

mentals of

to do followin

)

y in which a a company ( use of a defec essary by giv uality assura error, defect, s (K2) f testing (K1) ves of testing ging (K2) esting (K2)

)

activities and

)

that influence and of a deve

2)

f Testing

ng the compl defect in sof (K2)

ct and its effe ving example

nce and give fault, failure g in different d respective t e the succes eloper (K2)

15

letion of each ftware can ca ects (K2) es (K2) e examples o e, and the cor

phases of th tasks from p ss of testing (

55 minu

h module. ause harm to of how testin rresponding he software l lanning to cl (K1)

utes

o a g terms ife osure

(11)

1.1 Terms

Bug, def

1.1.1

Software products expected money, t

1.1.2

A human code, or (or do so result in Defects code, co Failures electroni changing

1.1.3 Operat

Rigorous during o corrected Software standard

1.1.4

With the for both f usability seeCha Software Testing c designed defects, Lessons found in reoccurr quality a Testing s standard 2011 al Software Testing Q

Why is

fect, error, fa

Software

e systems ar s (e.g., cars). d. Software t time or busin

Causes o

n being can m in a docume omething it s failures, but occur becau omplexity of i can be caus ic fields, and g the hardwa

Role of T

tions (K2)

s testing of s peration and d before the e testing may ds.

Testing a

help of testi functional an , efficiency, m apter 2; for m e Product Qu can give con d test that pa the quality o s should be le other projec ing and, as a ssurance. should be int ds, training a Qualifications Board

Testing

ailure, fault, m

e Systems

re an integral . Most people that does not ness reputati

of Softwar

make an erro ent. If a defec houldn’t), ca

not all defec se human be nfrastructure sed by enviro pollution ca are condition

Testing in

systems and d contribute to system is re y also be req

and Qualit

ng, it is poss nd non-functi maintainabili ore informat uality’ (ISO 9 nfidence in th asses reduce of the softwar earned from cts, processe a consequen tegrated as o nd defect an

g Necess

mistake, qual

s Context (

l part of life, f e have had a t work correc on, and coul

re Defects

or (mistake), ct in code is ausing a failu

cts do so. eings are fal e, changing t onmental con n cause faul s.

Software

documentati o the quality eleased for o quired to mee

ty (K2)

sible to meas ional softwar ty and portab tion on softw 126). he quality of t es the overal re system inc previous pro es can be imp nce, improve one of the qu nalysis). Page 11 of

sary (K2

lity, risk

(K1)

from busines an experienc ctly can lead ld even caus

s (K2)

which produ executed, th re. Defects i

lible and bec technologies nditions as w

ts in firmwar

Developm

ion can help

of the softw perational us et contractua

sure the qual re requireme bility). For m are characte the software l level of risk creases whe ojects. By un proved, whic the quality o uality assura 78

2)

ss applicatio ce with softwa to many pro se injury or de uces a defec he system ma n software, s cause there i , and/or man well. For exa

re or influenc

ment, Main

to reduce th are system, se. al or legal req lity of softwa ents and char

ore informat eristics see ‘S if it finds few k in a system en those defe derstanding ch in turn sho of future syst nce activities ns (e.g., ban are that did n oblems, inclu eath. t (fault, bug) ay fail to do w systems or d s time press ny system int mple, radiati ce the execut

ntenance a

he risk of pro if the defects quirements, o re in terms o racteristics (e ion on non-fu Software Eng w or no defec m. When testi

ects are fixed the root cau ould prevent tems. This is s (i.e., alongs 31-Ma

20 minut

nking) to cons not work as ding loss of in the progra what it shoul documents m sure, complex teractions. ion, magnetis tion of softwa

and

blems occur s found are or industry-s of defects fou e.g., reliabilit unctional tes gineering – cts. A proper ng does find d. ses of defec those defect an aspect o side develop ar-2011

tes

sumer am ld do may x sm, are by ring pecific und, ty, sting rly d cts ts from of pment

(12)

Deciding safety, a further in Testing s release o custome g how much t and business n Chapter 5. should provid of the softwa ers. testing is eno s risks, and p de sufficient are or system ough should project constr information t m being teste take accoun raints such a to stakehold ed, for the ne

nt of the leve as time and b ers to make xt developm el of risk, inclu budget. Risk informed de ent step or h uding technic k is discussed cisions abou handover to cal, d ut the

(13)

1.2 Terms

Debuggi

Backgr

A comm This is p Test acti choosing criteria, r activities (includin Both dyn and will developm Testing c o Find o Gain o Prov o Prev The thou test basi documen defects a Different testing (e many fai acceptan gain con be to ass stakehol testing th operatio availabil Debuggi Debuggi Subsequ responsi The proc 2011 al Software Testing Q

What is

ng, requirem

round

on perceptio part of testing ivities exist b g test conditi reporting on s after a test g source cod namic testing provide infor ment and tes can have the ing defects ning confiden viding inform venting defec ught process s via test de nts (e.g., req appearing in t viewpoints e.g., compon ilures as pos nce testing, t nfidence that sess the qua ders of the r hat no new d nal testing, t ity. ng and testin ng is the dev uent re-testin ibility for thes cess of testin Qualifications Board

s Testin

ment, review, on of testing i g, but not all o before and af

ons, designi the testing p phase has b de) and cond g and static te rmation that c sting process e following ob nce about the ation for dec cts s and activitie sign) can he quirements) a the code. in testing tak nent, integrat ssible so that the main obje

it has met th ality of the so risk of releas defects have he main obje ng are differe velopment ac ng by a teste se activities i ng and the te

g? (K2)

test case, te is that it only of the testing fter test exec ng and exec process and been complet ducting static esting can b can be used ses. bjectives: e level of qua cision-making es involved in elp to prevent

and the ident

ke different o tion and syst t defects in th ective may b he requireme oftware (with ing the syste been introdu ective may b

ent. Dynamic ctivity that fin r ensures tha is usually tes esting activitie Page 13 of esting, test o y consists of g activities. cution. Thes cuting test ca system unde ted. Testing c analysis. e used as a to improve b ality g n designing t t defects from tification and objectives into tem testing), he software a be to confirm ents. In some no intention em at a given uced during d e to assess s c testing can nds, analyze at the fix doe sters test and es are expla 78 objective running tests se activities in ses, checkin er test, and fi also includes means for ac both the syst

tests early in m being intro d resolution o o account. F the main ob are identified that the sys e cases the m of fixing defe n time. Maint developmen system chara show failure s and remov es indeed res d developers ined in Secti s, i.e., execu nclude plann ng results, ev inalizing or c s reviewing d chieving sim tem being tes

the life cycle oduced into c of issues also For example, bjective may d and can be tem works a main objectiv ects), to give tenance testi t of the chan acteristics su es that are ca ves the cause solve the fail s debug.

on 1.4.

31-Ma

30 minut

uting the softw

ning and cont valuating exit completing cl documents

milar objective sted and the

e (verifying t code. Review o help to prev in developm be to cause e fixed. In s expected, ve of testing e information ing often incl nges. During uch as reliab aused by def e of the failur ure. The ar-2011

tes

ware. trol, t osure es, e he ws of vent ment as to may n to ludes bility or fects. re.

(14)

1.3 Terms

Exhaust

Princip

A numbe guideline Principl Testing c reduces found, it Principl Testing e cases. In efforts. Principl To find d developm Principl Testing e modules release t Principl If the sam longer fin reviewed the softw Principl Testing i differentl Principl Finding a needs an

Seven

ive testing

ples

er of testing p es common f e 1 – Testin can show tha

the probabil is not a proo e 2 – Exhau everything (a nstead of exh e 3 – Early t defects early

ment life cyc e 4 – Defect effort shall be s. A small nu testing, or is e 5 – Pestic me tests are nd any new d d and revised ware or syste e 6 – Testin is done differ ly from an e-e 7 – Abse-en and fixing de nd expectatio

Testing

principles ha for all testing g shows pre at defects ar ity of undisco of of correctn ustive testin all combinatio haustive test testing , testing activ le, and shall t clustering e focused pr mber of mod responsible cide paradox repeated ov defects. To o d, and new a em to find po g is context rently in diffe -commerce s nce-of-errors efects does n ons.

Princip

ave been sug g. esence of d e present, bu overed defec ness. g is imposs ons of inputs ting, risk ana

vities shall b be focused roportionally dules usually for most of t x

ver and over overcome thi and different tentially mor t dependent erent context site. s fallacy not help if the

les (K2)

ggested over defects ut cannot pro cts remaining sible s and precon alysis and pri

e started as on defined o to the expec y contains mo the operation again, event is “pesticide tests need to re defects. t ts. For exam e system bui

)

r the past 40

ove that there g in the softw

nditions) is no orities should

early as pos objectives.

cted and late ost of the def nal failures.

tually the sam paradox”, te o be written t ple, safety-c lt is unusable years and o e are no defe ware but, eve

ot feasible ex d be used to ssible in the s r observed d fects discove me set of tes st cases nee to exercise d ritical softwa e and does n

35 minut

ffer general ects. Testing en if no defec

xcept for trivi o focus testin software or s defect density ered during p st cases will ed to be regu different parts are is tested

not fulfill the

tes

g cts are ial g system y of pre-no ularly s of users’

(15)

1.4 Terms

Confirma test cove summary

Backgr

The mos also inclu and eval The fund o Test o Test o Test o Eval o Test Although Tailoring

1.4.1

Test plan in order Test con status, in and obje througho activities Test plan

1.4.2

Test ana tangible The test o Revi anal o Eval o Iden beha o Desi o Iden o Desi o Crea 1 The degr system cha reliability, o 2011 al Software Testing Q

Fundam

ation testing, erage, test da y report, test

round

st visible part ude time to b luating result damental tes t planning an t analysis an t implementa uating exit c t closure acti h logically se g these main

Test Plan

nning is the a to meet the o ntrol is the on ncluding dev ectives of the out the projec s. nning and co

Test Ana

alysis and de test conditio analysis and iewing the te ysis reports, uating testab tifying and p avior and stru

igning and p tifying neces igning the tes ating bi-direc

ree to which sof aracteristics (e.g or cost) which a Qualifications Board

mental T

, re-testing, e

ata, test exe tware t of testing is be spent on p ts. st process co nd control d design ation and exe criteria and re vities equential, the activities wit

nning and

activity of de objectives an ngoing activit iations from e project. In o ct. Test plan ontrol tasks a

alysis and

esign is the a ons and test c

d design acti est basis (suc

architecture bility of the te prioritizing tes ucture of the rioritizing hig ssary test da st environme ctional tracea ftware complies g., software com are defined to re

Test Pro

exit criteria, i cution, test l s test executi planning the onsists of the ecution eporting e activities in thin the cont

d Control (

efining the ob nd mission. ty of compar the plan. It in order to contr ning takes in are defined in

Design (K

activity during cases. ivity has the ch as require e, design, inte est basis and st conditions e software gh level test c

ta to support ent setup and ability betwee

s or must comply mplexity, risk as eflect the importa

Page 15 of

ocess (K

ncident, regr og, test plan

ion. But to be tests, desig following ma the process ext of the sy

(K1)

bjectives of te ing actual pr nvolves takin rol testing, th nto account t n Chapter 5 o

K1)

g which gene following ma ements, softw erface specif d test objects based on an cases t the test con d identifying en test basis

y with a set of s ssessment, safe ance of the soft

78

K1)

ression testin , test proced

e effective an ning test cas

ain activities

may overlap stem and the

esting and th rogress again ng actions ne he testing ac he feedback of this syllab eral testing o ajor tasks: ware integrity fications) s nalysis of tes nditions and any required and test cas

stakeholder-sele ety level, securit tware to its stak

ng, test basis dure, test pol

nd efficient, t ses, preparin : p or take plac e project is u he specificatio nst the plan, ecessary to m tivities shoul k from monito bus. bjectives are y level1 (risk st items, the test cases d infrastructu ses ected software a ty level, desired keholders. 31-Ma

35 minut

s, test condit icy, test suite

test plans sh ng for execut ce concurren usually requir on of test ac and reportin meet the mis ld be monitor oring and con

e transformed

level), risk

specification

ure and tools

and/or software-performance, ar-2011

tes

tion, e, test hould ion ntly. red. ctivities ng the ssion red ntrol d into n, -based

(16)

Test imp combinin executio Test imp o Fina o Deve harn o Crea o Verif o Verif o Exec plan o Logg unde o Com o Repo a de was o Repe exec of a intro defe

1.4.4

Evaluatin objective Evaluatin o Chec o Asse o Writi

1.4.5

Test clos testware software achieved plementation ng the test ca on, the enviro plementation alizing, implem

eloping and nesses and w

ating test suit fying that the fying and up cuting test pr

ned sequenc ging the outc er test, test to mparing actua orting discre efect in the co executed) eating test a cution of a te corrected tes oduced in unc ects (regressi

Evaluatin

ng exit criter es. This shou

ng exit criter cking test log essing if mor

ing a test sum

Test Clos

sure activitie e, facts and n e system is re d, or a mainte and executio ases in a par onment is set and executio menting and prioritizing te writing autom tes from the e test environ

dating bi-dire rocedures ei ce

come of test ools and test al results with

pancies as in ode, in speci

ctivities as a est that previo

st and/or exe changed are ion testing)

ng Exit Cr

ia is the activ uld be done f ia has the fo gs against th re tests are n mmary repor

sure Activ

s collect data numbers. Tes eleased, a te enance relea on is the act rticular order t up and the on has the fo prioritizing t est procedure mated test scr test procedu nment has be ectional trace ther manuall execution an tware h expected r ncidents and

fied test data a result of act ously failed i ecution of tes as of the sof

riteria and

vity where te for each test

llowing majo he exit criteria needed or if t rt for stakeho

vities (K1)

a from comp st closure ac est project is ase has been

ivity where te r and includin tests are run ollowing majo test cases (in es, creating t ripts

ures for effici een set up co eability betw ly or by using nd recording results d analyzing th a, in the test tion taken fo n order to co sts in order t ftware or tha

Reporting

est execution level (see S or tasks: a specified in the exit criter olders pleted test ac ctivities occur completed (o n completed est procedur ng any other n. or tasks: ncluding the

test data and ent test exec orrectly een the test g test execut the identities hem in order document, o r each discre onfirm a fix (c to ensure tha t defect fixin

g (K1)

is assessed Section 2.2). n test plannin ria specified ctivities to co r at project m or cancelled . res or scripts information identification d, optionally, cution basis and te tion tools, ac s and versio r to establish or a mistake epancy, for e confirmation at defects ha g did not unc

d against the ng should be ch nsolidate exp milestones su ), a mileston s are specifie needed for t n of test data preparing te est cases ccording to th ns of the sof h their cause in the way th example, re-testing), exe ve not been cover other defined hanged perience, uch as when e has been ed by test a) est he ftware (e.g., he test ecution a

(17)

Version 2 © Internationa Test clos o Chec o Clos o Docu o Fina o Hand o Anal o Usin 2011 al Software Testing Q sure activitie cking which sing incident umenting the alizing and ar

ding over the lyzing lesson ng the inform Qualifications Board s include the planned deli reports or ra e acceptance rchiving testw e testware to ns learned to ation gathere e following m verables hav aising change e of the syste ware, the tes o the mainten o determine c ed to improv Page 17 of major tasks: ve been deliv e records for em st environmen nance organi changes nee ve test matur 78 vered r any that rem

nt and the te ization eded for futur

ity main open est infrastruct re releases a 31-Ma ture for later and projects

ar-2011 reuse

(18)

1.5 Terms

Error gue

Backgr

The mind software responsi an indep carried o A certain at finding develope be define o Test o Test o Test team o Test certi People a by mana meets its Identifyin author. A in the ma pessimis experien If errors, testers a during re The teste defects, defect in save tim Commun unwante relations

The Ps

essing, indep

round

dset to be us e. With the rig ibility to a tes pendent view out at any lev n degree of in

g defects and ers can effici ed as shown ts designed b ts designed b ts designed b m) or test spe ts designed b fication by a and projects agement and s objectives. ng failures du As a result, te anagement o sm, a critical nce on which defects or fa and the analy

eviews as we er and test le progress an nformation ca e and money nication prob ed news abou ships betwee

sycholog

pendence

sed while tes ght mindset d ster is typica w by trained a vel of testing ndependenc d failures. Ind ently find ma n here from lo by the perso by another p by a person( ecialists (e.g. by a person( n external bo are driven by other stakeh Therefore, it uring testing esting is ofte of product ris eye, attentio to base erro ailures are co ysts, designe ell as in testin eader need g d risks in a c an help them y later, and r blems may oc ut defects. H en testers and

gy of Tes

sting and rev developers a lly done to h and professio . ce (avoiding t dependence any defects i ow to high: n(s) who wro erson(s) (e.g s) from a diff ., usability or s) from a diff ody) y objectives. holders, for e t is importan may be perc en seen as a sks. Looking on to detail, g or guessing. ommunicate ers and deve

ng. good interper constructive w m improve the reduce risks. ccur, particu owever, ther d others:

sting (K

viewing is diff are able to te elp focus eff onal testing r

the author bi e is not, howe

n their own c ote the softw g., from the d ferent organi r performanc ferent organi . People tend example, to f t to clearly s ceived as cri destructive a for failures i good commu d in a constr lopers can b rsonal skills way. For the eir skills. Defe

.

larly if tester re are severa

2)

ferent from th est their own

fort and prov resources. In as) often ma ever, a replac code. Severa ware under te development izational grou ce test specia ization or com d to align the find defects o

tate the obje ticism agains activity, even n a system r unication with ructive way, be avoided. T to communic author of th ects found a s are seen o al ways to im

hat used whi code, but se ide additiona ndependent t

akes the teste cement for fa al levels of in st (low level t team) up (e.g., an i alists) mpany (i.e.,

eir plans with or to confirm ectives of tes st the produc n though it is requires curio h developme bad feelings This applies t cate factual i e software o nd fixed duri only as mess mprove comm

25 minut

ile developin eparation of t al benefits, su testing may b er more effec amiliarity, an ndependence of independ independent outsourcing the objectiv m that softwar ting. ct and agains s very constru osity, profess ent peers, an between the to defects fou nformation a or document, ing testing w engers of munication an

tes

g this uch as be ctive nd e can ence) t test or es set re st the uctive sional d e und about will nd

(19)

Version 2 © Internationa o Start qual o Com pers findi o Try t o Conf 2011 al Software Testing Q t with collabo ity systems mmunicate fin

son who crea ngs

to understan firm that the

Qualifications Board

oration rathe ndings on the ated it, for ex

d how the ot other person r than battles e product in a ample, write ther person f n has unders Page 19 of s – remind e a neutral, fac objective an feels and wh stood what yo 78 everyone of th ct-focused w nd factual inc y they react ou have said he common way without cr cident reports as they do d and vice ve 31-Ma goal of bette riticizing the s and review ersa ar-2011 er w

(20)

1.6

Involvem code of e inapprop following PUBLIC CLIENT of their c PRODUC and syst JUDGME judgmen MANAG ethical a PROFES consiste COLLEA promote SELF - C professio

Refere

1.1.5 Bl 1.2 Beiz 1.3 Beiz 1.4 Hetz 1.4.5 Bl 1.5 Blac

Code o

ment in softw ethics is nec priate use. Re g code of eth - Certified so AND EMPLO client and em CT - Certified tems they tes ENT- Certifie nt EMENT - Ce approach to t SSION - Cer nt with the p AGUES - Cer cooperation Certified softw on and shall

ences

ack, 2001, K zer, 1990, Bla zer, 1990, He zel, 1988 ack, 2001, C ck, 2001, Het

of Ethics

are testing e essary, amo ecognizing th ics: oftware teste OYER - Cert mployer, cons d software te st) meet the ed software t ertified softwa he managem rtified softwar ublic interest rtified softwa n with softwa ware testers promote an Kaner, 2002 ack, 2001, M etzel, 1988, M Craig, 2002 tzel, 1988

s

enables indiv ong other rea he ACM and

ers shall act tified softwar sistent with th esters shall e

highest profe testers shall

are test man ment of softw re testers sh t are testers sh re developer shall particip ethical appro Myers, 1979 Myers, 1979 viduals to lea asons to ensu d IEEE code consistently re testers sha he public inte ensure that th essional stan maintain inte nagers and le ware testing all advance hall be fair to rs pate in lifelon oach to the p rn confidenti ure that the i of ethics for

with the pub all act in a m erest he deliverab ndards possi egrity and ind

eaders shall the integrity and support ng learning r practice of th al and privile nformation is engineers, th blic interest manner that is

les they prov ble dependence subscribe to and reputatio tive of their c regarding the e profession

10 minut

eged informa s not put to he ISTQB st s in the best

vide (on the p

in their profe and promot on of the pro colleagues, a e practice of n

tes

ation. A ates the interests products essional e an ofession and their

(21)

2. T

Cycle

Learni

The obje

2.1 Sof

LO-2.1.1 LO-2.1.2 LO-2.1.3

2.2 Tes

LO-2.2.1

2.3 Tes

LO-2.3.1 LO-2.3.2 LO-2.3.3 LO-2.3.4 LO-2.3.5

2.4 Ma

LO-2.4.1 LO-2.4.2 LO-2.4.3 2011 al Software Testing Q

Testing

e (K2)

ing Objec

ectives identi

ftware Dev

1 Explain t developm 2 Recogni of projec 3 Recall ch

st Levels (

1 Compare typical ta who test

st Types (

1 Compare related) 2 Recogni 3 Identify a (K2) 4 Identify a or archite 5 Describe

intenance

1 Compare with resp 2 Recogni (K1) 3. Describe Qualifications Board

g Throug

ctives for

fy what you

velopmen

the relations ment life cyc ze the fact th ct and produc haracteristics

(K2)

e the differen argets of test t, types of de

K2)

e four softwa by example ze that funct and describe and describe ecture (K2) e the purpose

e Testing (

e maintenan pect to test ty ze indicators e the role of r

ghout th

r Testing

will be able t

nt Models (

hip between cle, by giving hat software ct characteris s of good tes nt levels of te ting (e.g., fun efects and fa

are test types (K2) tional and str e non-functio e test types b e of confirma

(K2)

ce testing (te ypes, trigger s for mainten regression te Page 21 of

he Softw

Througho

to do followin

(K2)

developmen examples us developmen stics (K1) sting that are

esting: major nctional or st ilures to be id

s (functional, ructural tests onal test type based on the ation testing esting an exi s for testing nance testing esting and im 78

ware Lif

out the S

ng the compl nt, test activit sing project a nt models mu e applicable t r objectives, tructural) and dentified (K2 , non-functio s occur at an es based on n e analysis of a and regress sting system and amount g (modificatio mpact analys

fe

1 Software L

letion of each

ties and wor and product ust be adapte to any life cy typical objec d related wor 2) nal, structura y test level ( non-function a software sy ion testing (K m) to testing a of testing (K on, migration is in mainten 31-Ma

115 min

Life Cycle

h module. k products in types (K2) ed to the con ycle model (K cts of testing, rk products, al and chang K1) al requireme ystem’s struc K2) a new applic K2) and retirem nance (K2) ar-2011

utes

e

n the ntext K1) , people ge-ents cture ation ent)

(22)

2.1 Terms

Commer verificati

Backgr

Testing d Different

2.1.1

Although correspo The four o Com o Integ o Syst o Acce In practic dependin integratio Software design d more tes (CMMI) o test desi

2.1.2

Iterative-and testi Applicati system t iteration. which sh first one.

2.1.3

In any lif o For e o Each o The deve o Test deve Test leve architect product

Softwa

rcial Off-The-on, V-model

round

does not exis t developmen

V-model

h variants of onding to the r levels used mponent (unit gration testin tem testing eptance testi ce, a V-mode ng on the pro on testing aft e work produ documents an st levels. Ref or ‘Software gn) can be c

Iterative--incremental ing a system ion Developm that is produc . An increme hould also be . Verification

Testing w

fe cycle mod every develo h test level h analysis and elopment act ters should b elopment life els can be co ture. For exa into a system

are Deve

-Shelf (COTS st in isolation nt life cycle m

(Sequent

the V-model e four develop in this syllab t) testing ng ing el may have oject and the ter compone ucts (such as nd code) pro ferences for g

life cycle pro carried out du

-incremen

developmen m in a series o ment (RAD), ced using the ent, added to

e tested. Reg and validatio

within a L

el, there are opment activi has test objec

d design of te tivity

be involved in cycle ombined or r ample, for the m, the purcha

elopmen

S), iterative-i n; test activiti models need

ial Develo

l exist, a com pment levels bus are: more, fewer e software pr ent testing, an s business sc oduced durin generic work ocesses’ (IEE uring the dev

ntal Develo

nt is the proc of short deve Rational Un ese models m others deve gression test on can be ca

ife Cycle M

several cha ity there is a ctives specifi ests for a giv n reviewing d

reorganized d e integration aser may per

nt Model

incremental

ies are relate d different ap

opment Mo

mmon type of s. r or different roduct. For e nd system in cenarios or u g developme k products in EE/IEC 1220 velopment of

opment M

cess of estab elopment cyc nified Process may be teste eloped previo ing is increas arried out on

Model (K2

racteristics o correspondi ic to that leve ven test level

documents a depending o of a Comme rform integra

s (K2)

developmen ed to softwar proaches to

odel) (K2)

f V-model us levels of dev xample, ther ntegration tes use cases, re

ent are often clude Capab 07). Verificat f the software

odels (K2

blishing requi cles. Exampl s (RUP) and ed at several ously, forms a singly import each increm

2)

of good testin ng testing ac el should begi as soon as dr n the nature ercial Off-The ation testing a t model, vali re developme testing.

ses four test

velopment an re may be co sting after sy equirements s the basis of bility Maturity ion and valid e work produ

)

irements, de es are: proto agile develo test levels d a growing pa tant on all ite ment.

ng: ctivity in during the rafts are ava

of the projec e-Shelf (COT at the system

20 minut

dation, ent activities levels, nd testing, omponent ystem testing specification f testing in on y Model Integ dation (and e ucts. signing, build otyping, Rap opment mode during each artial system erations after correspondi ilable in the ct or the syst TS) software m level (e.g.,

tes

. g. ns, ne or gration early ding id els. A , r the ing tem

(23)

Version 2 © Internationa integratio (function 2011 al Software Testing Q on to the infr nal and/or no Qualifications Board rastructure a on-functional, nd other sys , and user an Page 23 of tems, or sys nd/or operati 78 stem deploym onal testing) ment) and ac ). 31-Ma cceptance tes ar-2011 sting

(24)

2.2 Terms

Alpha te integratio test envi

Backgr

For each product( being tes and spec Testing a

2.2.1

Test bas o Com o Deta o Code Typical t o Com o Prog o Data o Data Compon verifies t testable. developm Compon such as structura specifica Typically developm testing u they are One app called a based on executin

Test Le

sting, beta te on, integratio ronment, tes

round

h of the test l s) being refe sted), typical cific approac a system’s c

Compon

sis: mponent requ ailed design e test objects: mponents grams a conversion abase modul nent testing (a the functionin . It may be do ment life cyc nent testing m resource-be al testing (e.g ation of the c y, componen ment environ usually involv found, witho proach to com test-first app n cycles of d g the compo

evels (K

esting, comp on testing, no st level, test-d evels, the fo erenced for d l defects and ches and res

onfiguration

ent Testin

uirements / migration p es also known a ng of, softwa one in isolati le and the sy may include t havior (e.g., g., decision c omponent, th t testing occ nment, such ves the progr out formally m mponent test proach or tes eveloping te onent tests co

K2)

ponent testing on-functional driven devel ollowing can b deriving test c d failures to b ponsibilities. data shall be

ng (K2)

programs as unit, modu are modules,

ion from the ystem. Stubs testing of fun searching fo coverage). Te

he software curs with acce

as a unit tes rammer who managing the ting is to pre st-driven deve est cases, the orrecting any g, driver, field l requiremen opment, use be identified cases (i.e., th be found, tes e considered ule or progra programs, o rest of the sy s, drivers and nctionality an or memory le est cases are design or the ess to the co

t framework wrote the co ese defects. pare and aut elopment. Th en building a y issues and d testing, fun nt, robustness er acceptance : the generic he test basis st harness re d during test am testing) s objects, class ystem, depe d simulators nd specific no eaks) or robu e derived fro e data mode ode being tes

or debuggin ode. Defects tomate test c his approach nd integratin iterating unt nctional requ s testing, stu e testing c objectives, t s), the test ob quirements a planning, earches for d ses, etc., tha

nding on the may be used on-functional ustness testin om work prod l.

sted and with g tool. In pr

are typically

cases before h is highly ite ng small piec til they pass.

40 minut

uirement, ub, system te

the work bject (i.e., wh

and tool supp

defects in, an t are separat e context of t d. l characterist ng, as well as ducts such as h the support actice, comp y fixed as soo e coding. This rative and is ces of code, a

tes

esting, hat is port, nd tely he tics, s s a t of a ponent on as s is s and

(25)

2.2.2

Test bas o Softw o Arch o Wor o Use Typical t o Subs o Data o Infra o Inter o Syst Integratio system, There m varying s 1. Com after 2. Syst hard orga Busi issue The grea compone Systema bottom-u or compo be increm Testing o testing a At each are integ the modu testing. B Ideally, t tests are order req 2011 al Software Testing Q

Integratio

sis:

ware and sys hitecture kflows cases test objects: systems abase implem astructure rfaces tem configura on testing te such as the ay be more t size as follow mponent integ r component tem integratio dware and so anization may ness proces es may be si ater the scop ent or system atic integratio up), functiona onents. In or mental rathe of specific no as well as fun stage of inte grating modu ules, not the Both function testers shoul e planned be quired for mo Qualifications Board

on Testing

stem design mentation ation and co sts interface operating sy than one lev ws: gration testin testing on testing te oftware and m y control only sses impleme ignificant. pe of integrat m, which may on strategies al tasks, tran rder to ease er than “big b on-functional nctional testin egration, teste ule A with mo functionality nal and struc d understand fore compon ost efficient t

g (K2)

nfiguration d s between c ystem, file sy vel of integrat ng tests the in sts the intera may be done y one side of ented as wor

tion, the mor y lead to incr may be bas nsaction proc fault isolation ang”. l characterist ng. ers concentr odule B they y of the indivi ctural approa d the archite nents or syste testing. Page 25 of data omponents, ystem and ha tion testing a nteractions b actions betwe e after system f the interfac rkflows may e difficult it b reased risk a sed on the sy cessing sequ n and detect tics (e.g., pe rate solely on are intereste idual module ches may be ecture and inf ems are buil

78 interactions ardware, and and it may be between softw een different m testing. In e. This migh involve a ser becomes to is and additiona ystem archite uences, or so t defects earl rformance) m n the integrat ed in testing e as that was e used. fluence integ t, those com with differen interfaces b e carried out ware compo t systems or this case, th ht be conside ries of system solate defect al time for tro ecture (such ome other as ly, integration may be includ tion itself. Fo the commun s done during gration plann mponents can 31-Ma nt parts of a between syst on test objec onents and is between e developing ered as a risk ms. Cross-pl ts to a specif oubleshooting as top-down spect of the s n should nor ded in integr or example, if nication betw g component ning. If integra n be built in th ar-2011 tems. cts of s done g k. atform fic g. n and system rmally ration f they ween t ation he

(26)

Test bas o Syst o Use o Func o Risk Typical t o Syst o Syst System t be clearl In system environm being fou System t processe interactio System t data qua requirem specifica decision based te respect t An indep

2.2.4

Test bas o User o Syst o Use o Busi o Risk Typical t o Busi o Ope o User o Form o Repo o Conf Accepta stakehol The goa specific acceptan sis:

tem and softw cases ctional specif k analysis rep test objects: tem, user an tem configura testing is con ly addressed m testing, the ment as muc und in testing testing may es, use case ons with the testing shou ality characte ments. System ation-based ( table may b echniques (w to a structura pendent test

Acceptan

sis: r requiremen tem requirem cases ness proces k analysis rep test objects: ness proces rational and r procedures ms orts figuration da nce testing is ders may be l in acceptan non-function nce testing. A ware require fication ports d operation m ation and co ncerned with d in the Mast e test environ h as possible g. include tests es, or other h operating sy ld investigate eristics. Teste m testing of f (black-box) te be created fo white-box) ma al element, s team often c

nce Testin

nts ments sses ports sses on fully maintenance s ata s often the re e involved as nce testing is al characteri Acceptance t ement specifi manuals nfiguration d h the behavio er and/or Lev nment shoul e in order to s based on ri igh level text ystem, and sy

e functional a ers also need functional re echniques fo r combinatio ay then be us such as menu carries out sy

ng (K2)

integrated sy e processes esponsibility s well. s to establish istics of the s testing may cation data or of a whole vel Test Plan d correspond minimize the sks and/or o t descriptions ystem resou and non-func d to deal with quirements s or the aspect ns of effects sed to asses u structure o ystem testing ystem of the custo h confidence system. Find assess the s system/prod n for that tes d to the final e risk of envi on requireme s or models rces. ctional requir h incomplete starts by usin t of the syste s described in ss the thorou or web page n g. mers or user in the system ding defects i system’s read

duct. The tes t level. target or pro ronment-spe nts specifica of system be rements of th e or undocum ng the most a em to be teste n business ru ghness of th navigation (s rs of a system m, parts of th s not the ma diness for de sting scope s oduction ecific failures ations, busine ehavior, he system, a mented appropriate ed. For exam ules. Structu he testing wit see Chapter m; other he system or ain focus in eployment an shall s not ess nd mple, a re-h 4). r nd

(27)

Version 2 © Internationa use, alth integratio Accepta o A CO o Acce o Acce Typical f User acc Typically Operatio The acce o Test o Disa o User o Main o Data o Perio Contrac Contract custom-d contract. to, such Alpha a Develop custome is perfor field-test Organiza testing fo 2011 al Software Testing Q hough it is no on test may c nce testing m OTS softwar eptance testi eptance testi forms of acce ceptance te y verifies the onal (accept eptance of th ting of backu aster recover r manageme ntenance tas a load and m odic checks ct and regula t acceptance developed so . Regulation as governme nd beta (or ers of marke ers in their ma med at the d ting, is perfor ations may u or systems th Qualifications Board ot necessarily come after th may occur at e product ma ing of the usa ing of a new eptance testi esting fitness for u tance) testin he system by up/restore ry ent sks migration task of security v ation accept e testing is pe oftware. Acc acceptance ent, legal or field) testing et, or COTS, arket before developing or rmed by cust use other term

hat are teste

y the final lev he acceptanc t various time ay be accept ability of a co functional en ing include th se of the sys ng y the system ks ulnerabilities tance testin erformed aga ceptance crite testing is pe safety regula g software ofte the software rganization’s tomers or po ms as well, s d before and Page 27 of vel of testing ce test for a es in the life tance tested omponent m nhancement he following: stem by busi administrato s ng ainst a contra eria should b erformed aga ations. en want to g e product is p s site but not otential custo such as facto d after being 78 . For examp system. cycle, for exa

when it is in ay be done d t may come b ness users. ors, including act’s accepta be defined wh ainst any regu

et feedback put up for sa by the deve omers at thei ory acceptanc moved to a le, a large-sc ample: nstalled or int during comp before system g: ance criteria hen the parti ulations that from potentia le commercia loping team. r own locatio ce testing an customer’s s 31-Ma cale system tegrated onent testing m testing for producin ies agree to t must be adh al or existing ally. Alpha te Beta testing ons. nd site accep site. ar-2011 g g the hered g esting g, or ptance

(28)

2.3 Terms

Black-bo maintain stress te

Backgr

A group on a spe A test typ o A fun o A no o The o Cha for u A model model or security or a plain

2.3.1

The func products be undoc Function testers) a tests for Specifica functiona behavior A type of detection interoper specified

2.3.2 Testing

Non-func testing, u testing o Non-func the tests varying s quality m

Test Ty

ox testing, co nability testing esting, structu

round

of test activi ecific reason pe is focused nction to be on-functional structure or nge related, unintended ch of the softw r menu struc threat mode n language s

Testing o

ctions that a s such as a re cumented. T nal tests are and their inte

components ation-based t ality of the so r of the softw f functional t n of threats, rability testin d component

Testing o

g) (K2)

ctional testin usability test of “how” the s ctional testin s required to scale, such a model such a

ypes (K2

ode coverage g, performan ural testing, u ties can be a or target for d on a partic performed by quality char architecture i.e., confirmi hanges (regr are may be d cture model),

ling), and fun specification)

of Functio

system, subs equirements The functions based on fun eroperability s may be bas techniques m oftware or sy ware (black-b esting, secu such as virus ng, evaluates ts or systems

of Non-fun

g includes, b ing, maintain system works g may be pe measure cha as response as the one de

2)

e, functional nce testing, p usability test aimed at veri testing. cular test obje

y the softwa acteristic, su

of the softwa ing that defe ression testin developed a non-function nctional testi ).

on (Functio

system or co s specification s are “what” t nctions and f with specific sed on a com may be used ystem (see C box testing). rity testing, in ses, from ma s the capabili s.

nctional S

but is not lim nability testin

s.

erformed at a aracteristics times for per efined in ‘Sof

testing, inter portability tes ting, white-bo

ifying the sof

ective, which re

uch as reliabi are or system ects have bee

ng) nd/or used in nal testing (e ng (e.g., a p

onal Testi

omponent are n, use cases the system d features (des c systems, an mponent spe to derive tes Chapter 4). Fu nvestigates t alicious outs ity of the soft

Software C

ited to, perfo ng, reliability t

all test levels of systems a rformance te ftware Engine roperability te sting, reliabili ox testing ftware system h could be an ility or usabil m en fixed (con n structural te e.g., performa rocess flow m

ing) (K2)

e to perform s, or a functio does. scribed in do nd may be pe cification). st conditions unctional tes the functions iders. Anothe tware produc

Characteris

ormance test testing and p . The term n and software esting. These eering – Soft esting, load t ity testing, se m (or a part o ny of the follo ity nfirmation tes esting (e.g., ance model, model, a stat may be des onal specifica ocuments or u erformed at a

s and test cas sting conside

s (e.g., a firew er type of fun ct to interact

stics (Non

ing, load tes portability tes on-functiona e that can be e tests can b tware Produ

40 minut

testing, ecurity testin of a system) owing:

sting) and loo

a control flow usability mo te transition cribed in wo ation, or they understood b all test levels

ses from the ers the extern

wall) relating nctional testi with one or

n-function

ting, stress sting. It is the al testing des quantified o e referenced ct Quality’ (IS

tes

g, based oking w odel model rk y may by the s (e.g., nal g to ng, more

al

e scribes on a d to a SO

(29)

2.3.3

Structura used afte through Coverag percenta to test th Chapter At all tes be used testing m Structura testing le

2.3.4

After a d defect ha defect) is Regress discover either in performe based on Tests sh testing. Regress structura regressio 2011 al Software Testing Q Non-functiona ack-box test d

Testing o

al (white-box er specificati assessment ge is the exte age of the ite hose items th 4. st levels, but to measure may be based al testing app evels (e.g., to

Testing R

defect is dete as been succ s a developm sion testing is r any defects the software ed when the n the risk of hould be repe sion testing m al testing. Re on testing is Qualifications Board al testing con design techn

of Softwar

x) testing may on-based te of coverage ent that a stru ems being co

hat were miss

especially in the code cov d on the arch proaches can o business m

Related to

ected and fixe cessfully rem ment activity, s the repeate s introduced o e being teste software, or not finding d eatable if the may be perfo egression tes a strong can nsiders the e niques to acc

re Structu

y be perform chniques, in e of a type of ucture has be overed. If cov sed to increa n component verage of ele hitecture of th n also be ap models or me

o Changes

ed, the softw moved. This i not a testing ed testing of or uncovered d, or in anoth its environm efects in soft ey are to be u rmed at all te st suites are r ndidate for au Page 29 of xternal beha complish that

ure/Archite

med at all test order to help structure. een exercise verage is not ase coverage t testing and ements, such he system, s plied at syste enu structure

s: Re-testi

ware should b is called con g activity. an already te d as a result her related o ment, is chan ftware that w used for conf

est levels, an run many tim utomation. 78 avior of the so t.

ecture (Str

t levels. Stru p measure th ed by a test s 100%, then e. Coverage component h as stateme such as a cal em, system i es).

ng and Re

be re-tested t firmation. De ested progra of the chang or unrelated s ged. The ext as working p firmation test

nd includes f mes and gene

oftware and

ructural T

ctural techni he thoroughn suite, expres more tests m techniques a integration te ents or decisi lling hierarch integration o

egression

to confirm th ebugging (loc

am, after mod ge(s). These software com tent of regres previously. ting and to a unctional, no erally evolve 31-Ma in most case

esting) (K

iques are be ness of testin sed as a may be desig are covered esting, tools ons. Structu hy. r acceptance

Testing (

hat the origina

cating and fix

dification, to defects may mponent. It is ssion testing ssist regress on-functional e slowly, so ar-2011 es

K2)

st ng gned in can ral e

K2)

al xing a y be s g is sion and