1. Certifi TesterC iedrFounddation Lev Sy n vel yllabuusReleasedR Ver rsion 201 11Intternatio onal Software Testing Qualif gfication Board ns r

2. International Certiffied Teste erSoftware Te esting Foundaation Level Sy yllabusQQualifications Board sCopyrigh Notice htThis doc cument may be copied in its entirety, or extracts made, if the s msource is ackknowledged.Copyrigh Notice In ht nternational Software Teesting Qualificcations Boar (hereinafte called ISTQB) rd erISTQB is a registered trademark of the Intern sdware Testing Qualifications Board,national Softw gCopyrigh 2011 the authors for the update 2011 (Thomas Mller (ch ht e rhair), Debra Friedenberg, andthe ISTQ WG Foun QB ndation Level)Copyrigh 2010 the authors for the update 2010 (Thomas Mller (chhte rhair), Armin BBeer, MartinKlonk, R Rahul Verma))Copyrigh 2007 the authors for the update 2007 (Thomas Mller (ch hterhair), Dorothy Graham, Debray D berg and Erik van Veenendaal)Friedenb kCopyrigh 2005, th authors (T ht he Thomas Mlle (chair), Re Black, Sig Eldh, Dorothy Graham,erex gridKlaus Ol lsen, Maaret Pyhjrvi, G Geoff Thompson and Erik van Veenenkndaal).All rights reserved. sThe auth hors hereby ttransfer the c copyright to t Internatiotheonal Softwar Testing Qure ualifications Board(ISTQB). The author (as current copyright holders) and ISTQB (as th future cop rst Ihe pyright holder)have agr reed to the foollowing condditions of usee:1) Any individual or training com rmpany may u this sylla use abus as the b basis for a tra aining course if the e authors and the ISTQB are acknowledge as the so edource and coopyright owners of the sy yllabus and provided tha any adverat rtisement of such a train ning course m mention the syllabu onlymaynus after submission for official accreditatio of the trarn onaining mater rials to an IISTQB recognized Natio onal Board.2) Any individual or group of inr ndividuals ma use this syllabus as t basis for articles, boo ays the oks, or othe derivative writings if th authors a erheand the ISTQB are acknowledged a the sourc and asce copy yright owners of the syllabus.s3) Any ISTQB-recoognized Natio onal Board m translate this syllabu and licens the syllab (or may e ussebusranslation) to other parties. its troVersion 22011 Page 2 of 78 7 31-Marr-2011 Internationa Software Testing Q al Qualifications Board 3. International Certiffied Teste er Software Te esting Foundaation Level Sy yllabus Q Qualifications BoardsRevision Histo oryVersionDate DRemarkssISTQB 22011 Effective 1-Ap Epr-2011 Certified Tester Foundation Level Syllabus lMaintena ance Release see Appe eendix E ReeleaseNotesISTQB 22010 Effective 30-M EMar-2010Certified Tester Foundation Level Syllabus lMaintena ance Release see Appe eendix E ReeleaseNotesISTQB 22007 01-May-2007 0 7Certified Tester Foundation Level Syllabus lMaintena ance ReleaseeISTQB 22005 01-July-2005 0Certified Tester Foundation Level Syllabus lASQF V2.2July-2003 JASQF Syyllabus Foundation Level Version 2.2Lehrplan Grundlagen des Softwa n nare-testensISEB V22.025-Feb-1999 2ISEB Sof ftware Testin Foundatio Syllabus V2.0 ng onV25 February 1999Version 22011 Page 3 of 78 731-Mar r-2011 Internationa Software Testing Q al Qualifications Board 4. International Certiffied Teste erSoftware Te esting Foundaation Level Sy yllabusQQualifications Board sTable of Conte entsAcknowledgements.. ........................................................................................... 7........................................Introducttion to this SSyllabus............................................................................... 8........................................ Purpo of this Dooseocument ............................................................................. 8........................................ The CCertified Test Foundatio Level in S teron Software Testing .............. ................................................... 8 Learnning Objective es/Cognitive Level of Knoowledge .......................... ................................................... 8 The EExamination ............................................................................................ 8........................................ Accreeditation ........ ........................................................................................... 8........................................ Level of Detail...... ........................................................................................... 9........................................ How tthis Syllabus is Organized ..................................................................... 9........................................1. Funndamentals o Testing (Kof K2)................ ................................................. 10........................................ 1.1 Why is Te esting Necessary (K2) ...................................................... 11........................................1.1.1 Software Systems CContext (K1) .......................................)................................................. 111.1.2 Causes of Software Defects (K2 .................................... se 2) ................................................. 111.1.3 Role of Testing in S fSoftware Dev velopment, Maintenance and Operations (K2) ............... 11M1.1.4 Testing and Quality (K2) ...........g y................................................. 11........................................1.1.5 How Much Testing is Enough? (K2) ................................ ................................................. 12 1.2 What is Testing? (K2) .................... ................................................. 13........................................ 1.3 Seven Testing Principples (K2) ....... ................................................. 14........................................ 1.4 Fundamental Test Proocess (K1) ... ................................................. 15........................................1.4 Test Planning and C4.1Control (K1) ........................................................................................ 151.4 Test An4.2nalysis and DDesign (K1) .................................................. 15........................................1.4 Test Im4.3mplementatio and Execu onution (K1)......................... ................................................. 161.4 Evaluating Exit Crit4.4 teria and Rep porting (K1) ..................... ................................................. 161.4 Test Cl4.5losure Activitties (K1) ....................................................... 16........................................ 1.5 The Psychhology of Testing (K2) .... ................................................. 18........................................ 1.6 Code of E Ethics ............................... ................................................. 20........................................2. Tessting Throug ghout the Sof ftware Life C Cycle (K2) ......................... ................................................. 21 2.1 Software Developmen Models (K2 ....................................nt2) ................................................. 222.1.1 V-mode (Sequentia Development Model) (K2) .............. el al ................................................. 222.1.2 Iterative e-incrementa Development Models (K2) .............al ( ................................................. 222.1.3 Testing within a Life Cycle Model (K2) ............................g e................................................. 22 2.2 Test Leve (K2) ............................els................................................. 24........................................2.2 Compo2.1 onent Testing (K2) ...........g................................................. 24........................................2.2 Integra2.2 ation Testing (K2) ............................................................. 25........................................2.2 System Testing (K2 .................2.3m2) ................................................. 26........................................2.2 Acceptance Testing (K2)...........2.4 g................................................. 26........................................ 2.3 Test Type (K2) .............................es ................................................. 28........................................2.3 Testing of Function (Functional Testing) (K2 .................3.1 gn 2)................................................. 282.3 Testing of Non-func3.2 g ctional Softw ware Characte eristics (Non n-functional T Testing) (K2) ......... 282.3 Testing of Software Structure/A3.3 g e Architecture (Structural Teesting) (K2) .............................. 292.3 Testing Related to Changes: Re3.4 g e-testing and Regression Testing (K2 ........................... 29 dn 2) 2.4 Maintenan Testing ( nce (K2) .............................................................. 30........................................3. Sta Techniqu (K2)...........................aticues................................................. 31........................................ 3.1 Static Tecchniques and the Test Prdrocess (K2) ....................................................................... 32 3.2 Review Process (K2) ...................................................................... 33........................................3.2 Activitie of a Form Review (K ...................................2.1es malK1) ................................................. 333.2 Roles a Respons2.2andsibilities (K1) ....................................... ) ................................................. 333.2 Types o Reviews (2.3of (K2) ............................................................... 34........................................3.2 Succes Factors fo Reviews (K ...................................2.4 ss orK2) ................................................. 35 3.3 Static Anaalysis by Too (K2) ........ols................................................. 36........................................4. Tes Design Te st echniques (K ................ K4) ................................................. 37........................................ 4.1 The Test Developmen Process (K ...................................nt K3) ................................................. 38 4.2 Categorie of Test Dees esign Techniqques (K2) ........................ ................................................. 39Version 22011 Page 4 of 78 7 31-Marr-2011 Internationa Software Testing Q al Qualifications Board 5. International Certiffied Teste erSoftware Te esting Foundaation Level Sy yllabusQQualifications Board s 4.3 Specificat tion-based or Black-box T rTechniques (K3) ............. ( ................................................. 404.3 Equivalence Partitio3.1 oning (K3) ... ................................................. 40........................................4.3 Bounda Value An3.2arynalysis (K3) ................................................... 40........................................4.3 Decisio Table Tes3.3 onsting (K3) ..... ................................................. 40........................................4.3 State T3.4 Transition Testing (K3) .... ................................................. 41........................................4.3 Use Ca Testing (3.5 ase (K2).............. ................................................. 41........................................ 4.4 Structure- -based or Wh hite-box Techniques (K4 .................. 4)................................................. 424.4 Statem4.1ment Testing a Coverag (K4) ............................ and ge................................................. 424.4 Decisio Testing an Coverage (K4) ...............................4.2 onnd e ................................................. 424.4 Other S4.3 Structure-bas Techniqu (K1) ..........................sed ues................................................. 42 4.5 Experienc ce-based Tec chniques (K2 .....................................2) ................................................. 43 4.6 Choosing Test Techni iques (K2)..................................................... 44........................................5. Tes Management (K3) .......................... st................................................. 45........................................ 5.1 Test Orga anization (K2 .................. 2)................................................. 47........................................5.1.1 Test Organization a Independ and dence (K2) ....................................................................... 475.1.2 Tasks o the Test L ofLeader and T Tester (K1) ........................................................................ 47 5.2 Test Planning and Esttimation (K3).......................................)................................................. 495.2 Test Planning (K2) ....................2.1................................................. 49........................................5.2 Test Planning Activ2.2 vities (K3) ...................................................... 49........................................5.2 Entry C2.3 Criteria (K2) ...................................................................... 49........................................5.2 Exit Criteria (K2)........................2.4................................................. 49........................................5.2 Test Es2.5stimation (K2 .................2) ................................................. 50........................................5.2 Test St2.6trategy, Test Approach (K ..................................t K2)................................................. 50 5.3 Test Prog gress Monitor ring and Con ntrol (K2) .......................................................................... 515.3 Test Pr3.1rogress Monitoring (K1) ................................................... 51........................................5.3 Test Re3.2eporting (K2).................................................................... 51........................................5.3 Test Co3.3ontrol (K2)........................................................................ 51........................................ 5.4 Configura ation Manageement (K2) ... ................................................. 52........................................ 5.5 Risk and T Testing (K2) .................... ................................................. 53........................................5.5 Project Risks (K2) .....................5.1t ................................................. 53........................................5.5 Produc Risks (K2) ....................5.2 ct ................................................. 53........................................ 5.6 Incident MManagement (K3) ............ ................................................. 55........................................6. Too Support fo Testing (K2 ol or 2)................. ................................................. 57........................................ 6.1 Types of T Test Tools (K ...............K2)................................................. 58........................................6.1.1 Tool Su upport for Teesting (K2) .................................................... 58........................................6.1.2 Test To Classifica oolation (K2) ..... ................................................. 58........................................6.1.3 Tool Su upport for Maanagement o Testing an Tests (K1) ............................................... 59 of nd )6.1.4 Tool Su upport for Sta Testing (K1) ................................ atic................................................. 596.1.5 Tool Su upport for Te Specificatest tion (K1) .......................... ................................................. 596.1.6 Tool Su upport for Te Execution and Loggin (K1) .........estnng ................................................. 606.1.7 Tool Su upport for Peerformance a Monitorin (K1)......... and ng................................................. 606.1.8 Tool Su upport for Sppecific Testin Needs (K1 ................. ng1)................................................. 60 6.2 Effective U of Tools Potential B Use s:Benefits and Risks (K2) ................................................... 626.2 Potential Benefits a Risks of Tool Suppor for Testing (for all tools (K2) ................... 622.1 andrts)6.2 Special Considerations for Som Types of Tools (K1) ....2.2 me T ................................................. 62 6.3 Introducin a Tool into an Organizngozation (K1) ....................... ................................................. 647. References ............................................................................................... 65........................................ Standdards ............ ......................................................................................... 65........................................ Bookss................... ......................................................................................... 65........................................8. Appendix A SSyllabus Background ........................................................ 67........................................ Histor of this Docry cument ............................ ................................................. 67........................................ Objecctives of the FFoundation C Certificate Qualification ...................... ................................................. 67 Objecctives of the IInternational Qualification (adapted frnrom ISTQB mmeeting at Soollentuna, Novem mber 2001)........................................................................................... 67........................................ Entry Requiremen for this Quntsualification .................................................... 67........................................Version 22011Page 5 of 78731-Marr-2011 Internationa Software Testing Q al Qualifications Board 6. International Certiffied Teste erSoftware Te esting Foundaation Level Sy yllabusQQualifications Board sBackgground and HHistory of the Foundation Certificate in Software T enTesting ..................................... 689.Appendix B LLearning Objeectives/Cogn nitive Level of Knowledge ............................................... 69o eLevel 1: Remember (K1) ............................ ................................................. 69 ........................................Level 2: Understand (K2) ............................................................................ 69 ........................................Level 3: Apply (K3 ..................................... 3) ................................................. 69 ........................................Level 4: Analyze ((K4) .................................................................................. 69 ........................................10.Appendix C Rules AppA plied to the IS STQB ................................................................................ 71Founddation Syllab ................................... bus................................................. 71 ........................................ 10. Genera Rules ........................... .1.1al ................................................. 71 ........................................ 10. Current Content ........................ .1.2 ................................................. 71 ........................................ 10. Learnin Objectives .................. .1.3ng s ................................................. 71 ........................................ 10. Overall Structure ....................... .1.4 l ................................................. 71 ........................................11.Appendix D Notice to TATraining Provviders .............................. ................................................. 7312.Appendix E Release Notes.............A ................................................. 74 ........................................Relea 2010 ...... ase......................................................................................... 74 ........................................Relea 2011 ...... ase......................................................................................... 74 ........................................13.Index .................................................................................................... 76 ........................................Version 22011Page 6 of 78731-Marr-2011 Internationa Software Testing Q al Qualifications Board 7. International Certiffied Teste er Software Te esting Foundaation Level Sy yllabus Q Qualifications BoardsAcknoowledgementsInternatio onal Softwar Testing Qure ualifications Board Working Group Fooundation Leevel (Edition 2011):Thomas Mller (chair), Debra Friedenberg. T core team thanks the review team (Dan Almog Them m g,Armin Be Rex Black, Julie Gar eer, rdiner, Judy McKay, Tuul Pkkne Eric Riou du Cosquier Hans laen,rSchaefer, Stephanie Ulrich, Erik van Veenendaal) and all National Booards for the suggestions forthe curre version o the syllabus.entofInternatio onal Softwar Testing Qu reualifications Board Working Group Fooundation Le evel (Edition 2010):Thomas Mller (chair), Rahul Verma, Martin K Klonk and Arrmin Beer. T core team thanks theThe mreview teeam (Rex Bla ack, Mette BBruhn-Pedersson, Debra Friedenberg, Klaus Olsen Judy McKaFn,ay,Tuula Pkknen, MMeile Posthum Hans Sc ma,chaefer, Stepphanie Ulrich, Pete William Erik vanms,Veenend daal) and all National Boa ards for their suggestions r s.Internatio ualifications Board Working Group Fo onal Softwar Testing Qureoundation Le evel (Edition 2007):Thomas Mller (chair), Dorothy G Graham, Deb Friedenberg, and Erik van Veenendaal. The corebra k cteam thaanks the revie team (Ha Schaefer Stephanie Ulrich, Meile Posthuma, Anders ewansr,ePettersson, and Won Kwon) and all the National Boards for their sugnildggestions.Internatio ualifications Board Working Group Fo onal Softwar Testing Qureevel (Edition 2005): oundation LeThomas Mller (chair), Rex Black Sigrid Eldh Dorothy Graham, Klau Olsen, Ma k, h,G usaaret Pyhjrrvi,Geoff Thhompson and Erik van Vedeenendaal an the review team and a National B ndw allBoards for theirsuggestions.Version 22011 Page 7 of 78 731-Mar r-2011 Internationa Software Testing Q al Qualifications Board 8. International Certiffied Teste er Software Te esting Foundaation Level Sy yllabus Q Qualifications BoardsIntrod duction to this Syllabus n sPurpo of this Documeose sentThis sylla abus forms t basis for the International Softwar Testing Qualification a the Founda there atationLevel. Th Internatio he onal Software Testing Qualifications Board (ISTQB provides it to the Natio e B B)onalBoards f them to accredit the trfor ders and to derive examination quest raining provid dtions in their locallanguage Training p e. providers will determine a appropriate teeaching meth hods and prooduce courseewareeditation. The syllabus w help candidates in their preparation for the exafor accre will amination.Information on the history and baackground of the syllabus can be foun in Append A.f snddixThe CCertified TTester Foundation Level in Software TestingeThe Foundation Leve qualificatio is aimed a anyone inv elonatvolved in softtware testing This includg. despeople in roles such as testers, te analysts, test enginee test cons nest, ers,sultants, test managers, usertacceptan testers a software developers. This Founda nceand ation Level qqualification i also approis opriatefor anyone who want a basic un tsnderstanding of software testing, such as project mh managers, qualitymanager software developmen managers, business an rs, ntnalysts, IT dir rectors and mmanagementconsultaants. Holders of the Foundation Certif ficate will be able to go on to a higher nr-level softwa aretesting qqualification.Learni Objec ing ctives/Co ognitive Level of Knowledge K eLearning objectives a indicated for each section in this syllabus and classified as follows: gare dsd so K1: rremembero K2: uunderstando K3: aapplyo K4: aanalyzeFurther ddetails and eexamples of llearning objeectives are given in Appeendix B.All terms listed under Terms jus below chap heading shall be re sst pter gs(K1), even if notemembered (explicitly mentioned in the learnin objectives yng s.The EExaminatio onThe Foundation Leve Certificate examination will be base on this sy el ned yllabus. Answwers toexaminaation question may require the use o material ba ns of ased on more than one section of thisessyllabus. All sections of the syllab are exam s busminable.The form of the exa matamination is multiple chooice.Exams m be taken as part of a accredited training coumayn an d urse or taken independen (e.g., at annntlyaexamina ation center o in a public exam). Com or mpletion of an accredited training coua durse is not a pre-requisite for the examem.Accred ditationAn ISTQ National BQBBoard may accredit training providers whose cour material f s rsefollows thissyllabus. Training pro oviders shou obtain acculdcreditation guidelines from the board or body thattperforms the accreditation. An ac sccredited couurse is recoggnized as con nforming to this syllabus, andis allowe to have an ISTQB exaedn amination as part of the course.Further gguidance for training prov viders is give in Append D.endixVersion 22011 Page 8 of 78 7 31-Marr-2011 Internationa Software Testing Q al Qualifications Board 9. International Certiffied Teste erSoftware Te esting Foundaation Level Sy yllabusQQualifications Board sLevel of DetailThe leve of detail in this syllabus allows interelsrnationally coonsistent teaching and exxamination. Inorder to achieve this goal, the syllabus consis of:stso General instructional objectiv describin the intentio of the Fouvesngonundation Levvelo A list of informati to teach, including a dion description, and referenc to additio aces onal sources ifrequuiredo Learrning objectiv for each knowledge aves area, describbing the cognnitive learning outcome andaminddset to be acchievedo A list of terms tha students matmust be able to recall and understand e d do A deescription of t key concthe cepts to teach, including sources such as accepte literature or s hed ostandardsThe syllaabus content is not a des t scription of th entire kno he owledge area of software testing; it ref a flectsthe level of detail to b covered in Foundation Level traini courses. be nn ingHow th Syllab is Or hisbus rganizedThere ar six major cre chapters. The top-level h heading for each chapter shows the hhighest level oflearning objectives th is covere within the chapter and specifies the time for the chapter. Fo hated e eorexamplee:2. Tes sting Thr roughout the Soft ftware Life Cycle (K2)115 minnutesThis heaading shows that Chapter 2 has learning objective of K1 (assres sumed when a higher level isshown) a K2 (but n K3), and it is intended to take 115 minutes to teach the material in the andnot d 5echapter. Within each chapter there are a num mber of sectioons. Each seection also ha the learning asobjective and the amesmount of time required. Se Subsections that do not hhave a time ggiven are includedwithin the time for the section.eVersion 22011 Page 9 of 78 7 31-Marr-2011 Internationa Software Testing Q al Qualifications Board 10. International Certiffied Teste er Software Te esting Foundaation Level Sy yllabus Q Qualifications Boards1. Fundammentals of Testting (K2 2)15 minu55 utesLearni Objec ing ctives for Fundamrmentals of TestingfThe obje ectives identify what you will be able t do followin the compltongletion of each module. h1.1 Wh is Testing Necess hysary? (K2)LO-1.1.1 1 Describe with examples, the way in which a defect in sof e,yftware can caause harm to a o person, t the enviro to onment or to a company (K2)(LO-1.1.2 2 Distinguish between the root cau of a defec and its effeuse ct ects (K2)LO-1.1.3 3 Give reaasons why testing is nece essary by givving example (K2)esLO-1.1.4 4 Describe why testing is part of qu eg uality assurance and give examples o how testinge of contribut to higher quality (K2) tesrLO-1.1.5 5 Explain a compare the terms e and eerror, defect, fault, failure and the core,rresponding terms mistake and bug, usi examples (K2) ing s1.2 Wh is Testing? (K2) hatLO-1.2.1 1 Recall th common o heobjectives of testing (K1) fLO-1.2.2 2 Provide examples for the objectiv of testing in different phases of th software lifeves g he cycle (K2 2)LO-1.2.3 3 Different tiate testing f from debugg ging (K2)1.3 Sev Testin Principvenngples (K2)LO-1.3.1 1 Explain t seven pr therinciples in teesting (K2)1.4 Funndamenta Test Pro al ocess (K1) )LO-1.4.1 1 Recall th five fundamental test a heactivities and respective tdtasks from planning to closure (K1)1.5 The Psychology of Tese sting (K2) )LO-1.5.1 1 Recall th psycholog hegical factors tthat influence the succes of testing ( e ss(K1)LO-1.5.2 2 Contrast the mindset of a tester a of a deve tt andeloper (K2)Version 22011 Page 10 of 78 31-Ma ar-2011 Internationa Software Testing Q al Qualifications Board 11. International Certiffied Teste er Software Te esting Foundaation Level Sy yllabus Q Qualifications Boards1.1Why is Testing Necessgsary (K22) 20 minuttesTermsBug, def fect, error, fa ailure, fault, mmistake, quallity, risk1.1.1Software Systems Context (e s (K1)Software systems ar an integral part of life, f erel from busines applications (e.g., ban ssnking) to conssumerproducts (e.g., cars). Most people have had a experienc with softwa that did n work as s . e ancearenotexpected Software t d.that does not work correc can lead to many protctly oblems, including loss ofmoney, t time or busin ness reputation, and coul even caus injury or deld seeath.1.1.2Causes o Softwar Defects (K2)ofresA human being can m n make an erro (mistake), which produ or uces a defect (fault, bug) in the progra amcode, or in a docume If a defec in code is executed, th system ma fail to do went. ctheay what it shoul do ld(or do soomething it shouldnt), ca ausing a failure. Defects in software, s systems or ddocuments may mresult in failures, but not all defec do so.ctsDefects occur because human be eings are fallible and beccause there is time presssure, complexxcode, co omplexity of infrastructure changing t e,technologies, and/or man system int nyteractions.Failures can be caus by envirosedonmental connditions as well. For example, radiatiw ion, magnetissm,electroni fields, and pollution can cause faults in firmwar or influenc the executicrecetion of softwa by arechanging the hardwa conditions.g are1.1.3 Role of TTesting in Software Developmment, Main ntenance aandOperattions (K2)systems and documentati can help to reduce th risk of problems occurringRigorous testing of ss ionheduring operation and contribute to the quality of the software system, if the defects found aredoseleased for operational uscorrected before the system is redse.Software testing may also be req e y quired to mee contractua or legal req et al quirements, o industry-specific orstandard ds.1.1.4Testing a and Qualit (K2)tyWith the help of testing, it is poss sible to meas sure the qual of software in terms o defects fou lityof und,for both f functional an non-functi ndional softwar requireme re ents and char racteristics (ee.g., reliabilit ty,usability, efficiency, m maintainability and portabbility). For more information on non-fuunctional tes stingsee Cha apter 2; for more informattion on software characte eristics see SSoftware Enggineering Software Product Qu euality (ISO 9126).Testing c give concannfidence in th quality of t software if it finds few or no defec A properhe thewcts.rlydesigned test that padasses reduce the overall level of risk in a system When testing does findeskm.ddefects, the quality o the softwar system inc ofrecreases whe those defeenects are fixed d.Lessons should be lesojects. By understanding the root causes of defecearned from previous pro ctsfound in other projec processe can be impcts, esproved, whic in turn shoch ould prevent those defect fromtsreoccurring and, as a consequennce, improve the quality of future systotems. This is an aspect of oquality assurance.Testing sshould be inttegrated as o of the quone uality assurance activities (i.e., alongss side develop pmentstandard training and defect an ds, nalysis).Version 22011 Page 11 of 78 31-Ma ar-2011 Internationa Software Testing Q al Qualifications Board 12. International Certiffied Teste erSoftware Te esting Foundaation Level Sy yllabusQQualifications Board s1.1.5How Muc Testing is Enoug chggh? (K2)Deciding how much t gtesting is eno ough should take accoun of the leve of risk, inclu ntel uding techniccal,safety, a business risks, and pand s project constr raints such as time and b a budget. Risk is discussed kdfurther in Chapter 5. nTesting sshould provid sufficient information t stakeholders to make informed decisions abou thede to utrelease o the softwa or system being teste for the next development step or hof are med, handover tocustomeers.Version 22011 Page 12 of 78 31-Ma ar-2011 Internationa Software Testing Q al Qualifications Board 13. International Certiffied Teste er Software Te esting Foundaation Level Sy yllabus Q Qualifications Boards1.2What is Testing? (K2) s 30 minuttesTermsDebugging, requiremment, review, test case, teesting, test objective oBackgr roundA common perceptio of testing i that it only consists of running tests i.e., execu onisy s,uting the softw ware.This is p of testing but not all o the testing activities.part g,ofgTest acti ivities exist bbefore and af test execfter cution. Thes activities in se nclude plann ning and conttrol,choosing test conditions, designing and execg cuting test cases, checkin results, ev ngvaluating exittreporting on the testing pcriteria, r process and system unde test, and fi ercompleting closureinalizing or cactivities after a test phase has b sbeen complet ted. Testing also includes reviewing ds documents(including source cod and condde) ducting static analysis. cBoth dynesting can be used as a means for acnamic testing and static te g chieving simmilar objectivees, rmation that c be used to improve both the systand will provide inforcanb tem being tes sted and the edevelopm ment and tessting process ses.Testing c have the following obcan ebjectives:o Finding defectso Gain ning confiden about the level of quance e alityo Prov viding information for deccision-makinggo Prev venting defecctsThe thouught process and activitie involved in designing tests early in the life cycle (verifying the s esntetest basis via test design) can he to prevent defects from being intro elp tmoduced into ccode. Review ofwsdocumen (e.g., reqntsquirements) a the ident and tification and resolution o issues also help to prevdof oventdefects aappearing in the code.Different viewpoints in testing tak different o tke objectives into account. F example, in developm o Formenttesting (e e.g., componnent, integrattion and systtem testing), the main obbjective may be to cause asmany fai ilures as pos ssible so that defects in th software are identified and can be fixed. Int he a deacceptan testing, t main obje ncetheective may b to confirm that the system works as expected, to begain connfidence that it has met th requiremehe ents. In some cases the memain objectiv of testing mayvebe to asssess the qua of the so alityoftware (with no intention of fixing defeects), to give information toe nstakeholders of the r of releasing the syste at a given time. Maint riskem n tenance testi often incl ing ludestesting th no new d hat defects have been introduuced during development of the chan dnges. Duringoperational testing, the main objeective may be to assess system chara s acteristics su as reliabuch bility oravailability.Debugging and testin are differe Dynamic testing can show failure that are cang ent. c es aused by deffects.Debugging is the devvelopment ac ctivity that finnds, analyzes and remov the cause of the failurves e re.Subsequuent re-testin by a tester ensures tha the fix doe indeed resngat es solve the failure. Theresponsi ibility for thes activities i usually tesse is sters test and developers debug. dsThe proc cess of testin and the teng esting activitie are explained in Section 1.4.esVersion 22011 Page 13 of 78 31-Ma ar-2011 Internationa Software Testing Q al Qualifications Board 14. International Certiffied Teste er Software Te esting Foundaation Level Sy yllabus Q Qualifications Boards1.3Seven Testing Principles (K2) ) 35 minuttesTermsExhaustive testingPrincipplesA numbe of testing per principles ha been sug aveggested over the past 40 years and offer general rguideline common f all testinges for g.Principle 1 Testing shows preesence of d defectsTesting c show tha defects are present, bu cannot pro that there are no defe canatutovee ects. Testing greduces the probability of undisco overed defec remaining in the softwcts gware but, eve if no defec are enctsfound, it is not a proo of correctnofness.Principle 2 Exhau ustive testing is imposssibleTesting eeverything (a combinatio of inputs and precon all onss nditions) is no feasible exot xcept for trivi ialcases. Innstead of exh haustive testalysis and priorities should be used to focus testing ting, risk anadoefforts.Principle 3 Early ttestingTo find dvities shall be started as early as posdefects early, testing activ ssible in the s software or system sdevelopmment life cycle, and shall be focused on defined objectives. oPrinciple 4 Defect clusteringtTesting eeffort shall be focused pre roportionally to the expec cted and later observed ddefect density of ymodules A small number of mod s.dules usually contains mo of the defyostfects discoveered during pre-prelease ttesting, or is responsible for most of t operation failures. the nalPrinciple 5 Pestic cide paradox xIf the sam tests are repeated ov and over again, event me ver tually the sam set of tes cases will no me stlonger fin any new d nd defects. To oovercome thi pesticide paradox, test cases nee to be reguised ularlyreviewed and revised and new a different tests need to be written t exercise d dd,ando to different parts ofsthe softwware or syste to find potentially mor defects. emrePrinciple 6 Testing is context dependentt tTesting i done differ is rently in diffeerent context For example, safety-critical softwa is testedts. aredifferentl from an e- ly -commerce s site.Principle 7 Absennce-of-errors fallacysFinding a fixing deand efects does n help if the system built is unusable and does n fulfill the usersnot eenotneeds an expectationd ons.Version 22011 Page 14 of 7831-Maar-2011 Internationa Software Testing Q al Qualifications Board 15. International Certiffied Teste er Software Te esting Foundaation Level Sy yllabus Q Qualifications Boards1.4Fundammental T Test Proocess (K K1) 35 minuttesTermsConfirmaation testing, re-testing, e criteria, incident, regr , exit ression testin test basis test condit ng, s, tion,erage, test da test execution, test log, test plan, test procedtest coveata, dure, test policy, test suite teste,summary report, testytwareBackgr roundThe mos visible part of testing is test executisttsion. But to be effective an efficient, t end test plans sh houldalso inclu time to b spent on p ude be planning the tests, designing test casses, preparin for executionngand eval luating resultts.The fund damental tes process cost onsists of the following ma activities: aino Test planning an control tndo Test analysis and design to Test implementa tation and exe ecutiono Evaluating exit ccriteria and reeportingo Test closure activities tAlthough logically seh equential, the activities in the process may overlap or take plac concurren e p cently.Tailoring these main activities witg thin the context of the system and the project is u eusually requir red.1.4.1Test Plan nning and Control ( d (K1)Test plannning is the aactivity of de efining the obbjectives of teesting and th specificatio of test ache on ctivitiesin order to meet the oobjectives an mission.ndTest con ntrol is the on ngoing activit of comparing actual prty rogress again the plan, and reportin the nstng ncluding deviations from the plan. It instatus, in nvolves takin actions ne ngecessary to mmeet the misssionand obje ectives of the project. In o eorder to contr testing, th testing activities shoul be monitor rol he ld redthrougho the projec Test planning takes in account the feedback from monito outct. nto k oring and conntrolactivities s.nning and coTest planontrol tasks a defined in Chapter 5 of this syllabaren obus.1.4.2Test Anaalysis and Design (K K1)Test anaalysis and deesign is the aactivity during which gene testing objectives are transformed intogeral e dtangible test conditio and test c ons cases.The test analysis and design acti divity has the following ma tasks: ajoro Reviiewing the te basis (suc as requireest ch ware integrity level1 (risk level), risk ements, softwy analysis reports, architecture design, inte e,erface specif fications)o Evaluating testabbility of the te basis and test objectsestd so Identifying and p prioritizing tes conditions based on anst nalysis of tes items, the specificationstn, behaavior and struucture of the software eo Desiigning and prioritizing hig level test c ghcaseso Identifying necesssary test data to support the test contnditions and test caseso Desiigning the tes environme setup and identifying any required infrastructu and tools st entdd ureo Crea ating bi-direcctional tracea ability betwee test basis and test cas en ses1The degr to which sof reeftware complies or must comply with a set of stakeholder-selesy sected software a and/or software--basedsystem cha aracteristics (e.g software comg., mplexity, risk asssessment, safe level, securit level, desired performance, etytyreliability, o cost) which a defined to re orareeflect the importa ance of the softtware to its stakkeholders.Version 22011Page 15 of 78 31-Maar-2011 Internationa Software Testing Q al Qualifications Board 16. International Certiffied Teste er Software Te esting Foundaation Level Sy yllabus Q Qualifications Boards1.4.3Test Impplementation and Exxecution (K1)Test imp plementation and executio is the activity where te procedur or scripts are specifie by onest ressedcombinin the test ca ngases in a par rticular order and includin any other information needed for testrng texecutio the enviro on, onment is set up and the tests are run t n.Test imp plementation and executio has the fo on ollowing majo tasks: oro Fina alizing, implemmenting and prioritizing ttest cases (inncluding the identification of test data na)o Deveeloping and prioritizing te procedure creating test data and optionally, preparing teestes, td,est harnnesses and wwriting autom mated test scrriptso Crea ating test suit from the test procedutes ures for efficient test execcutiono Verif fying that the test environ enment has be set up co een orrectlyo Verif fying and updating bi-direeability between the test basis and te cases ectional traceesto Execcuting test prrocedures either manuall or by using test execut ly g tion tools, ac ccording to thhe planned sequencceo Loggging the outccome of test execution an recording the identities and versions of the sofnds ftware unde test, test toerools and testtwareo Commparing actua results with expected ral hresultso Repoorting discrepancies as in ncidents and analyzing thdhem in order to establish their cause (e.g.,rh a deefect in the coode, in specified test data in the test document, o a mistake in the way th testa,or he was executed)o Repeeating test activities as a result of acttion taken for each discre epancy, for eexample, re- execcution of a te that previo est ously failed in order to coconfirmation testing), exeonfirm a fix (c ecution of a corrected tes and/or exestecution of tes in order to ensure tha defects have not been stst at intro oduced in uncchanged areas of the sofftware or that defect fixing did not unccover other defeects (regressi testing)ion1.4.4Evaluatin Exit Cr ngriteria and Reporting (K1) gEvaluatin exit criteria is the activ where te execution is assessed against the definedng vity est dobjective This shou be done f each test level (see Section 2.2).es. uldforSEvaluatin exit criteria has the following majo tasks:ng oro Checcking test log against th exit criteria specified in test plannin gshe anngo Asseessing if mor tests are n reneeded or if t exit criter specified should be chtheria hangedo Writi a test suming mmary repor for stakehortolders1.4.5Test Clos sure Activvities (K1)Test clossure activities collect data from comp a pleted test acctivities to consolidate expperience,testware facts and ne, numbers. Tes closure ac st ctivities occur at project mrmilestones su as when auchsoftware system is ree eleased, a te project is completed (o cancelled), a milestone has beenest orachieved or a mainted,enance relea has been completed. ase nVersion 22011 Page 16 of 7831-Maar-2011 Internationa Software Testing Q al Qualifications Board 17. International Certiffied Teste erSoftware Te esting Foundaation Level Sy yllabusQQualifications Board sTest clossure activities include the following m e major tasks:o Chec cking which planned deliverables hav been delivve veredo Clossing incident reports or raaising change records for any that reme rmain openo Docu umenting the acceptance of the systeeeemo Fina alizing and ar rchiving testw ware, the tes environmen and the te infrastruct stntest ture for later reuseo Hand ding over the testware to the mainteneo nance organiizationo Anal lyzing lesson learned to determine c ns ochanges neeeded for futur releases a projects re ando Usin the information gathere to improv test maturitynged veVersion 22011 Page 17 of 78 31-Ma ar-2011 Internationa Software Testing Q al Qualifications Board 18. International Certiffied Teste er Software Te esting Foundaation Level Sy yllabus Q Qualifications Boards1.5The Pssycholog of Tes gy sting (K2)25 minut tesTermsError gueessing, indeppendenceBackgr roundThe mind dset to be us while tessed sting and revviewing is diff ferent from th used whi developinghat ilesoftware With the rig mindset de.ghtdevelopers a able to te their own code, but se areesteparation of thistresponsi ibility to a tes is typically done to help focus eff and provide additiona benefits, su asster fort aluchan indeppendent view by trained a professio w andonal testing resources. In r ndependent ttesting may bebcarried o at any lev of testing.out velA certain degree of in n ndependenc (avoiding t author bias) often mace the akes the teste more effecer ctiveat finding defects and failures. Ind g d dependence is not, howeeever, a replaccement for fa amiliarity, annddevelope can efficiently find ma defects in their own code. Severa levels of in ers any cal ndependence canebe define as shown here from lo to high: ed nowo Test designed b the person(s) who wro the softw tsby ote ware under test (low level of independence)o Test designed b another person(s) (e.g from the development team) tsby g.,dto Test designed b a person(s) from a diff tsbyferent organi izational grou (e.g., an i upindependent testt team or test spem) ecialists (e.g. usability or performanc test specia ., r cealists)o Test designed b a person(s) from a diff tsbyferent organi ization or commpany (i.e., outsourcing or certification by an external bo ody)People a projects are driven by objectives. People tend to align the plans with the objectives setand y. d eirby manaagement and other stakeh holders, for e example, to find defects o to confirm that softwar form remeets its objectives. Therefore, it is important to clearly state the objes tectives of testing.Identifyin failures du nguring testing may be percceived as criticism agains the produc and agains thestct st esting is ofte seen as a destructive activity, even though it is very construauthor. A a result, te As en a n s uctivein the maanagement o product ris of sks. Looking for failures in a system rrequires curioosity, profess sionalpessimis a critical eye, attentio to detail, g sm,ongood commuunication with developme peers, and h entexperien on which to base erro guessing.nce orIf errors, defects or fa ailures are co ructive way, bad feelings between theommunicated in a constretesters a the analy andysts, designe and developers can be avoided. T ers bThis applies t defects fou toundduring reeviews as we as in testinell ng.The teste and test le er eader need g good interperrsonal skills to communic cate factual information about adefects, progress and risks in a c constructive wway. For the author of the software o document,ordefect innformation ca help them improve the skills. Defeanmeirects found and fixed duri testing will ingwsave time and money later, and r y reduce risks..Communnication probccur, particularly if testers are seen oblems may oconly as messengers ofunwante news abou defects. However, ther are severa ways to imed ut re almprove comm munication an ndrelationsships betwee testers and others:en dVersion 22011 Page 18 of 7831-Maar-2011 Internationa Software Testing Q al Qualifications Board 19. International Certiffied Teste erSoftware Te esting Foundaation Level Sy yllabusQQualifications Board so Start with collabo toration rather than battles remind everyone of th common goal of bettese he erquality systemso Commmunicate finndings on the product in a neutral, fac e ct-focused w without crway riticizing thepers who creason ated it, for example, write objective an factual inc ndcident reports and reviewswfindingso Try t understand how the ot tother person f feels and why they react as they doo Conf firm that the other person has unders n stood what yo have said and vice veou d ersaVersion 22011 Page 19 of 78 31-Ma ar-2011 Internationa Software Testing Q al Qualifications Board 20. International Certiffied Teste erSoftware Te esting Foundaation Level Sy yllabusQQualifications Board s1.6Code o Ethicsof s 10 minuttesInvolvemment in software testing e enables indiv viduals to learn confidential and privile eged informaation. Acode of eethics is necessary, amo other rea ong asons to ensu that the information is not put to ure sinapprop ecognizing th ACM and IEEE code of ethics for engineers, th ISTQB states thepriate use. Rehe d hefollowing code of ethics:goftware teste shall act consistently with the pub interestPUBLIC - Certified so ers blicCLIENT AND EMPLOOYER - Certtified softwar testers sha act in a m reall manner that is in the best interestssof their c client and em mployer, cons sistent with th public inte heerestPRODUC - Certified software teCT d esters shall eensure that th deliverables they prov he vide (on the products pand syst tems they tes meet the highest profe st)essional stanndards possibleJUDGME ENT- Certifie software t ed testers shall maintain inteegrity and ind dependence in their profe essionaljudgmenntMANAGEMENT - Ce ertified softwa test manarenagers and leeaders shall subscribe to and promote anethical aapproach to the managemment of softw ware testingPROFESSSION - Cer rtified softwar testers shall advance the integrity and reputatio of the proreon ofessionconsistent with the public interesttCOLLEAAGUES - Cerrtified softwa testers sh be fair to and supportarehall tive of their ccolleagues, andapromote cooperation with software developernrsSELF - C Certified softw ware testers shall participregarding the practice of their pate in lifelon learning r ng eprofessio and shall promote an ethical approon oach to the practice of the profession pnRefere ences1.1.5 Black, 2001, K Kaner, 20021.2 Beiz 1990, Bla zer, ack, 2001, M Myers, 19791.3 Beiz 1990, He zer,etzel, 1988, MMyers, 19791.4 Hetz 1988 zel,1.4.5 Black, 2001, C Craig, 20021.5 Blac 2001, Het ck,tzel, 1988Version 22011 Page 20 of 78 31-Ma ar-2011 Internationa Software Testing Q al Qualifications Board 21. International Certiffied Teste erSoftware Te esting Foundaation Level Sy yllabusQQualifications Board s2. TTesting Throug g ghout th Softwheware Lif fe1 minutes 115Cycle (K2)eLearni Objec ing ctives for Testing Througho the Srout Software L CycleLifeeThe obje ectives identify what you will be able t do followin the compltongletion of each module. h2.1 Sofftware Dev velopmen Models (nt (K2)LO-2.1.1 1 Explain t relationship between developmen test activit the nt, ties and work products in the n developmment life cyc by giving examples us cle, sing project a product types (K2) andLO-2.1.2 2 Recognize the fact th software developmen models mu be adapte to the conhatnt ustedntext of projec and produc characteris ct ctstics (K1)LO-2.1.3 3 Recall ch haracteristics of good tess sting that are applicable t any life cy e to ycle model (KK1)2.2 Tes Levels (st (K2)LO-2.2.1 1 Compare the differen levels of teentesting: major objectives, typical objec of testing,rcts , typical taargets of test ting (e.g., fun nctional or sttructural) and related wor products, people d rk who test types of det,efects and failures to be id dentified (K2 2)2.3 Tes Types (K2)stLO-2.3.1 1 Compare four softwa test types (functional, non-functional, structura and change ares,al ge- related) by example (K2)LO-2.3.2 2 Recognize that funct tional and str ructural tests occur at any test level (K1)sLO-2.3.3 3 Identify a describe non-functioand e onal test type based on n esnon-functional requireme ents (K2)LO-2.3.4 4 Identify a describe test types band e based on the analysis of a software sy e ystems struc cture or architeecture (K2)LO-2.3.5 5 Describe the purpose of confirmae eation testing and regression testing (KK2)2.4 Maintenance Testing (e (K2)LO-2.4.1 1 Compare maintenance testing (te eesting an existing system to testing a new applicationm) with resp pect to test ty ypes, triggers for testing and amount of testing (K K2)LO-2.4.2 2 Recognize indicators for mainten s nance testing (modificatio migration and retirement) gon, (K1)LO-2.4.3 3.Describe the role of r e regression te esting and immpact analysis in maintennance (K2)Version 22011 Page 21 of 78 31-Ma ar-2011 Internationa Software Testing Q al Qualifications Board 22. International Certiffied Teste er Software Te esting Foundaation Level Sy yllabus Q Qualifications Boards2.1Softwa Deveareelopmen Models (K2) nt 20 minut tesTermsCommer rcial Off-The--Shelf (COTS iterative-i S), incremental development model, validation,verification, V-modelBackgr roundTesting ddoes not exis in isolation test activiti are relate to softwar developme activities.st n;iesed reentDifferent developmen life cycle mt nt models need different approaches to testing.d2.1.1V-model (Sequential Develoopment Moodel) (K2)Although variants of the V-model exist, a com hl mmon type of V-model us four test levels, fsescorrespo onding to the four develop epment levelss.The four levels used in this syllab are: rbuso Com mponent (unit testingt)o Integgration testinngo Syst tem testingo Acce eptance testi ingIn practic a V-mode may have more, fewer or different levels of dev ce, elrvelopment an testing, nddependin on the pro ngoject and the software pr e roduct. For example, ther may be core omponentintegratio testing aft compone testing, an system in onter entnd ntegration tessting after sy ystem testing g.Software work produe ucts (such as business sc scenarios or use cases, reu equirements sspecification ns,design d documents an code) pro ndoduced during developme are often the basis of testing in on orent fnemore tes levels. Refstferences for ggeneric work products include Capabk bility Maturity Model Integygration(CMMI) o Software life cycle proor ocesses (IEEEE/IEC 1220 Verification and valid07).dation (and early etest design) can be ccarried out duuring the devvelopment of the software work produfeucts.2.1.2Iterative--incremen Develontal opment Models (K2)Iterative- -incremental developmen is the proc ntcess of estab irements, designing, buildblishing requi dingand testi a system in a series o short deve ingmofelopment cyccles. Examples are: proto otyping, RapidApplicati Developm ion ment (RAD), Rational Un nified Process (RUP) and agile develo s opment mode Aels.system t that is produc using the models m be teste at several test levels d cedese mayedduring eachiteration. An increme added to others deve .ent, eloped previoously, forms a growing paartial system,which sh hould also be tested. Regegression testing is increas singly import tant on all ite erations after therfirst one. Verification and validatio can be ca .on arried out on each incremment.2.1.3Testing w within a Life Cycle M Model (K2 2)In any lif cycle model, there are several characteristics of good testin feo ng:o For e every develo opment activi there is a corresponding testing ac ity ctivityo Each test level h test objec h has ctives specifi to that leve icelo The analysis and design of tedests for a giv test level should begi during the correspondivenin ingdeve elopment act tivityo Test ters should b involved in reviewing d bendocuments as soon as drarafts are available in thedeve elopment life cycleTest leve can be coels ombined or r reorganized ddepending on the nature of the projec or the syst ct temarchitectture. For exaample, for the integration of a Comme eercial Off-The e-Shelf (COT software TS)product into a system the purcham, aser may per rform integraation testing a the system level (e.g.,at mVersion 22011 Page 22 of 7831-Maar-2011 Internationa Software Testing Q al Qualifications Board 23. International Certiffied Teste erSoftware Te esting Foundaation Level Sy yllabusQQualifications Board sintegratio to the infr onrastructure and other systems, or sys stem deploym ment) and ac cceptance tes sting(function and/or nonal on-functional, and user an,nd/or operational testing)).Version 22011 Page 23 of 7831-Maar-2011 Internationa Software Testing Q al Qualifications Board 24. International Certiffied Teste erSoftware Te esting Foundaation Level Sy yllabusQQualifications Board s2.2Test Le evels (KK2) 40 minut tesTermsAlpha testing, beta te esting, compponent testing driver, field testing, fung,dnctional requ uirement,integratio integratio testing, no on, on on-functional requiremen robustness testing, stu system telnt, s ub, esting,test environment, tes level, test-d st driven development, use acceptance testing ereBackgr roundFor each of the test levels, the foh ollowing can b identified: the generic objectives, t workbe c theproduct(s) being refeerenced for dderiving test ccases (i.e., th test basis the test obhe s), bject (i.e., wh is hatbeing tessted), typical defects and failures to b found, tes harness requirements a tool suppl dbestand port,and spec approaccificches and responsibilities.Testing a systems configuration data shall be considered during test planning, ed2.2.1Component Testin (K2)ngTest bas sis:o Commponent requuirementso Deta ailed designo CodeeTypical ttest objects:o Commponentso Proggramso Data conversion / migration pa programso Dataabase modulesComponalso known a unit, modu or progra testing) searches for dnent testing (a as ule amdefects in, anndverifies t functionin of, softwa modules, programs, objects, class theng are o ses, etc., that are separattelytestable. It may be do in isolati from the rest of the sy .one ion ystem, depending on the context of theedevelopm ment life cycle and the syystem. Stubs drivers and simulators may be used s,d d.Componnent testing m include t may testing of funnctionality an specific no ndon-functional characteristl tics,such as resource-behavior (e.g., searching fo memory leor eaks) or robu ustness testin as well asng, sstructura testing (e.g decision cal g.,coverage). Te cases are derived fro work prod esteom ducts such as asspecificaation of the component, th software design or the data model. he eTypically component testing occy,curs with acce to the co being tesessode sted and with the support of ah tdevelopm ment environnment, such as a unit test framework or debugging tool. In practice, comp ponenttesting uusually involv the progr vesrammer who wrote the coode. Defects are typically fixed as soo asyonthey are found, witho formally m outmanaging the defects.eseOne app proach to com mponent test ting is to prepare and auttomate test ccases before coding. This is e scalled a test-first appproach or tesst-driven deve elopment. Th approach is highly iterative and ishis h sbased on cycles of developing te cases, the building and integratin small piec of code, and nesten ng ces aexecuting the compo onent tests co orrecting any issues and iterating unt they pass. ytilVersion 22011 Page 24 of 78 31-Ma ar-2011 Internationa Software Testing Q al Qualifications Board 25. International Certiffied Teste erSoftware Te esting Foundaation Level Sy yllabusQQualifications Board s2.2.2Integratio Testing (K2)ongTest bas sis:o Softwware and sysstem designo Arch hitectureo Workflowso Use casesTypical ttest objects:o Subssystemso Dataabase implem mentationo Infraastructureo Inter rfaceso Systtem configura ation and configuration ddataIntegratio testing tests interfaces between components, interactions with differen parts of a onntsystem, such as the operating sy ystem, file syystem and ha ardware, and interfaces b between syst tems.There may be more t than one lev of integratveltion testing and it may be carried out on test objec ofa e ctsvarying ssize as follow ws:1. Com mponent integ gration testin tests the inng nteractions between softwbware compoonents and is done safter component testingr2. Syst tem integratio testing tests the interaonactions betwe different systems or between een tharddware and so oftware and m be done after system testing. In this case, the developingmay e mgorgaanization may control only one side of the interface. This migh be consideyy fhtered as a risk k.Business processses impleme ented as worrkflows may involve a serries of system Cross-platformms.issue may be si es ignificant.The grea the scop of integrat ater petion, the more difficult it becomes to isb solate defect to a speciftsficcompone or system which may lead to incr entm,yreased risk and additiona time for troaaloubleshootingg.Systema integratio strategies may be bas on the syatic onsed ystem archite ecture (such as top-down andnbottom-u functiona tasks, tranup),al nsaction proccessing sequ uences, or so ome other asspect of the systemsor compo onents. In or rder to ease fault isolation and detect defects earl integration should nor n tly, n rmallybe incremmental rathe than big bang. erTesting o specific no of on-functional characterist (e.g., performance) m be includ in integrlticsmay ded rationtesting a well as funasnctional testinng.At each stage of inteegration, teste concentrersrate solely on the integratntion itself. Fo example, if they or fare integgrating modu A with mo ule odule B they are intereste in testing the communed nication betw weenthe modu ules, not the functionality of the indivi yidual module as that was done during componentes gttesting. B Both function and struc nal ctural approaches may be used.eIdeally, t testers should understand the architedecture and inffluence integgration plannning. If integra ationtests are planned before componenents or systeems are built, those com mponents can be built in thnheorder reqquired for mo efficient t ost testing.Version 22011 Page 25 of 78 31-Ma ar-2011 Internationa Software Testing Q al Qualifications Board 26. International Certiffied Teste er Software Te esting Foundaation Level Sy yllabus Q Qualifications Boards2.2.3System TTesting (K K2)Test bas sis:o Syst tem and softw ware requireement specificationo Use caseso Funcctional specif ficationo Risk analysis rep kportsTypical ttest objects:o Systtem, user and operation m manualso Systtem configura ation and configuration ddataSystem ttesting is con ncerned with the behavio of a whole system/prodh or duct. The tes sting scope shall sbe clearl addressed in the Master and/or Lev Test Plan for that test level.ly d velnnment should correspond to the final target or proIn system testing, the test environmedoductionenvironmment as much as possible in order to minimize the risk of environment-spee eecific failures not sbeing fou in testingundg.System t testing may include tests based on risks and/or on requirements specifica s o ations, busineessprocesse use case or other high level text descriptions or models of system be es,es, t sehavior,interactio with the operating sy ons ystem, and syystem resources.System t testing should investigate functional a non-funceand rements of th system, andctional requir hedata qua characteality eristics. Teste also need to deal with incomplete or undocumersdh ementedrequiremments. System testing of f mfunctional requirements starts by usin the most asng appropriatespecificaation-based ((black-box) teechniques fo the aspect of the syste to be teste For examort emed. mple, adecision table may b created for combinations of effects described in business rube s n ules. Structure-based teechniques (wwhite-box) ma then be us to asses the thoroughness of th testing withay sed ssherespect t a structura element, s toalsuch as menu structure or web page n u o navigation (s Chapter 4). seeAn indep pendent test team often c carries out syystem testingg.2.2.4Acceptan Testin (K2)ncengTest bas sis:o User requiremenr ntso Syst tem requiremmentso Use caseso Business proces sseso Risk analysis rep kportsTypical ttest objects:o Business processses on fully integrated sy ystemo Operational and maintenance processes eo User proceduresrso Form mso Repo ortso Conf figuration da ata esponsibility of the customers or user of a system otherAcceptance testing is often the res rsm;stakeholders may be involved as well. esThe goal in acceptan testing is to establish confidence in the system parts of th system ornce s hm,he rspecific non-functional characteri istics of the s system. Findding defects is not the ma focus in ainacceptan testing. A nce Acceptance ttesting may assess the systems readsdiness for de eployment anndVersion 22011 Page 26 of 7831-Maar-2011 Internationa Software Testing Q al Qualifications Board 27. International Certiffied Teste er Software Te esting Foundaation Level Sy yllabus Q Qualifications Boardsuse, althhough it is no necessarily the final lev of testing. For example, a large-sc ot yvel cale systemintegratio test may c on come after th acceptanc test for a system.he ceAcceptance testing m occur at various time in the life cycle, for exa maytesample:o A CO OTS software product ma be acceptay tance tested when it is innstalled or inttegratedo Acce eptance testi of the usa ing ability of a co omponent may be done dduring component testinggo Acce eptance testi of a new functional en ing nhancement may come b t before system testingmTypical fforms of acceeptance testi include th following:ingheUser accceptance teestingTypically verifies the fitness for use of the sysy stem by business users. onal (acceptOperatiotance) testinng eptance of th system by the system administrato includingThe acce he yors,g:o Test ting of backu up/restoreo Disaaster recoverryo User manageme r ento Main ntenance tasskso Data load and m amigration task kso Perioodic checks of security vulnerabilities sContrac and regula ct ation accept tance testinngContract acceptance testing is pet eerformed agaainst a contraacts acceptaance criteria for producingcustom-ddeveloped so oftware. Accceptance crite should be defined wh the parti agree to the eriabheniestcontract. Regulation acceptance testing is pe. erformed aga ainst any reguulations that must be adhheredto, such as governme legal or safety regula ent,ations.Alpha and beta (or field) testing gDevelopers of marke or COTS, software ofte want to get feedback from potentia or existing et, enal gcustome in their maers arket before the software product is put up for sale commerciae pally. Alpha teestingis performed at the d developing or rganizations site but not by the developing team. Beta testing ors g,field-test ting, is perfor rmed by cust tomers or po omers at their own locatiootential custoons.Organiza ations may u other term as well, susems such as facto acceptanc testing an site acceporyce ndptancetesting fo systems th are tested before and after being moved to a customers s or hat d site.Version 22011 Page 27 of 7831-Maar-2011 Internationa Software Testing Q al Qualifications Board 28. International Certiffied Teste er Software Te esting Foundaation Level Sy yllabus Q Qualifications Boards2.3Test Ty ypes (K22)40 minut tesTermsBlack-bo testing, co coverage functional testing, interoxodee, roperability teesting, load ttesting,maintainnability testing performan testing, p g,nceportability tessting, reliabili testing, se ityecurity testing,stress teesting, structu testing, u uralusability testting, white-bo testingoxBackgr roundA group of test activities can be aaimed at veriifying the sof ftware system (or a part o a system) based mofon a spe ecific reason or target for testing.A test typ is focused on a partic pe dcular test objeective, which could be an of the folloh ny owing:o A funnction to be performed by the softwareyo A noon-functional quality characteristic, su as reliabi or usability uch ilityo The structure or architecture of the softwa or systemare mo Change related, i.e., confirmi that defeingects have bee fixed (conennfirmation tes sting) and loookingfor uunintended ch hanges (regrression testinng)A model of the software may be d developed and/or used in structural ten esting (e.g., a control flow wmodel or menu struc r cture model), non-function testing (enale.g., performaance model, usability mo odelsecurity threat modeling), and funmodel, a stat transition model nctional testing (e.g., a process flow m teor a plain language s nspecification) ).2.3.1Testing o Functio (Functio ofon onal Testi ing) (K2)The func ctions that a system, subssystem or co omponent are to perform may be described in workeproducts such as a re s equirements specification use cases or a functio s n,s, onal specifica ation, or they mayybe undoccumented. T functions are what t system does.Thes the dFunction tests are based on funnalnctions and ffeatures (desscribed in doocuments or uunderstood by the btesters) a their inte anderoperability with specific systems, an may be pec nd erformed at a test levels (e.g., all stests for components may be bas on a comssedmponent specification).Specificaation-based ttechniques m be used to derive tes conditions and test cas from themay stssesfunctiona of the soality oftware or syystem (see C Chapter 4). Fuunctional tessting conside the externersnalbehavior of the softwr ware (black-b testing).boxA type of functional testing, security testing, infnvestigates the functions (e.g., a firewt s wall) relating to gdetection of threats, such as virusn ses, from ma alicious outsiders. Anothe type of funernctional testing,interoperrability testin evaluates the capabili of the softng,s itytware produc to interact with one or morectspecified component or systemsdts s.2.3.2 Testing o Non-funofnctional S Software CharacterisC stics (Non n-functionalTesting (K2)g)Non-func ctional testing includes, b is not limited to, perfo butormance testing, load testing, stresstesting, u usability testing, maintain nability testin reliability testing and p ng, t portability tes sting. It is theetesting o how the sofsystem works s.Non-func ctional testing may be pe erformed at a test levels. The term non-functiona testing des all al scribesthe tests required to measure chas aracteristics of systems and software that can be quantified on a a eovarying sscale, such a response times for perasrformance te esting. These tests can be referenced to a edquality mmodel such a the one deas efined in Sofftware Engineeering Softtware Product Quality (IS SOVersion 22011 Page 28 of 7831-Maar-2011 Internationa Software Testing Q al Qualifications Board 29. International Certiffied Teste er Software Te esting Foundaation Level Sy yllabus Q Qualifications Boards9126). N Non-functiona testing conal nsiders the external beha avior of the so oftware and in most caseesuses bla ack-box test ddesign techn niques to acc complish that t.2.3.3Testing o Softwar Structu ofreure/Archite ecture (Str ructural Testing) (KK2)Structura (white-box testing may be perform at all test levels. Structural technial x) ymed tiques are bestused afte specification-based techniques, in order to help measure th thoroughner pheness of testin ngthrough assessment of coverage of a type of structure. eCoverag is the exte that a stru geentucture has be exercise by a test s een ed suite, expressed as apercenta of the ite age ems being coverage is not 100%, then more tests m be desigovered. If cov maygnedto test th hose items th were miss to increa coverage Coverage techniques a covered in hat sed ase e.areChapter 4.At all tes levels, but especially in component testing and component integration te stnt esting, tools canbe used to measure the code covverage of eleements, such as stateme hents or decisions. Structuraltesting m be based on the arch maydhitecture of th system, such as a cal hes lling hierarchhy.Structura testing app alproaches can also be applied at syste system inem,integration or acceptanceetesting le evels (e.g., to business m omodels or me structure enues).2.3.4Testing R Related to Changes Re-testing and Reo s:egression Testing (K2)After a ddefect is dete ected and fixe the softwed,ware should be re-tested t confirm th the originab to hat aldefect ha been succ as cessfully remmoved. This i called confirmation. Deis ebugging (loccating and fix xing adefect) is a developm s ment activity, not a testing activity.gRegress sion testing is the repeate testing of an already tes ed ested progra after modam, dification, todiscover any defects introduced o uncovered as a result of the chang r sor dge(s). These defects may beyeither in the software being tested, or in anoth related or unrelated seherosoftware commponent. It issperforme when the software, or its environm ed ment, is changed. The exttent of regresssion testing isgbased on the risk of not finding defects in softn ftware that was working ppreviously.Tests shhould be repeeatable if the are to be u eyused for conf firmation testting and to assist regress siontesting.Regress sion testing m be performed at all te levels, an includes functional, no mayestndon-functional andstructura testing. Real egression tes suites are r many tim and gene st runmes erally evolve slowly, so eregressio testing is a strong can onndidate for auutomation.Version 22011 Page 29 of 7831-Maar-2011 Internationa Software Testing Q al Qualifications Board 30. International Certiffied Teste er Software Te esting Foundaation Level Sy yllabus Q Qualifications Boards2.4Maintenance T Testing ( (K2) 15 minut tesTermsImpact a analysis, maintenance tes stingBackgr roundOnce deeployed, a sooftware syste is often in service for years or decades. During this time the em n y gsystem, its configura ment are often corrected, changed or extended. Thation data, or its environm n heplanning of releases in advance i crucial for successful maintenance testing. A distinction has to be gismesmade be etween plann releases and hot fixe Maintenan testing is done on an existingned es. nce s noperational system, a is triggered by modif andgration, or retirement of th software or fications, mighesystem.Modifica ations include planned enenhancement cchanges (e.g release-bag., ased), correcctive andemergen changes, and change of environ ncyesnment, such as planned oa stem or databaseoperating sysupgrades, planned upgrade of Co ommercial-OOff-The-Shelf software, or patches to correct newlyf rexposed or discovere vulnerabilities of the o dedoperating sysstem.Maintena ance testing for migration (e.g., from one platform to another) should inclu operationnm ude naltests of t new environment as w as of the changed so thewell eoftware. Migration testing (conversion g ntesting) i also neede when data from anoth applicatio will be mig ised aher ongrated into th system be heeingmaintainned.Maintenaance testing for the retireement of a syystem may in esting of data migration ornclude the teaarchiving if long dataga-retention peeriods are required.In additio to testing what has be changed, maintenanc testing inconeen ce cludes regression testing togparts of t system that have not been changthe t ged. The sco of mainte ope enance testin is related to the ngtrisk of th change, th size of the existing sys hehe e stem and to the size of th change. DtheDepending on thenchanges maintenanc testing may be done a any or all test levels an for any or all test types. s, ceattndrDeterminning how the existing sys estem may be affected by changes is c called impact analysis, an ist ndused to h help decide hhow much re egression tessting to do. The impact analysis may be used to Tdetermin the regres nession test suiite.Maintenacations are out of date or missing, or testers with ance testing can be diffic if specificcultordomain k knowledge a not availaare able.Refere ences2.1.3 CM MMI, Craig, 22002, Hetzel 1988, IEEE 12207l,E2.2 Hetz 1988 zel,2.2.4 Co opeland, 200 Myers, 1904,9792.3.1 BeBlack, 2001, Copeland, 2 eizer, 1990, B 20042.3.2 Black, 2001, IS 9126SO2.3.3 Be eizer, 1990, CCopeland, 20004, Hetzel, 19882.3.4 He etzel, 1988, IIEEE STD 82 29-19982.4 Blac 2001, Cra 2002, He ck,aig, etzel, 1988, IIEEE STD 8229-1998Version 22011 Page 30 of 7831-Maar-2011 Internationa Software Testing Q al Qualifications Board 31. International Certiffied Teste er Software Te esting Foundaation Level Sy yllabus Q Qualifications Boards3. Static T STechniques (K2 2) 6 minut60tesLearni Objec ing ctives for Static Ter echniquesThe obje ectives identify what you will be able t do followin the compltongletion of each module. h3.1 Sta Techniques and the Test Process (K2)atic d(LO-3.1.1 1 Recognize software work produc that can be examined by the differ ctsb rent static techniqu (K1) uesLO-3.1.2 2 Describe the importa eance and valu of consideue ering static te echniques fo the assessorsment of softwa work products (K2) areLO-3.1.3 3 Explain t differenc between sthecestatic and dynnamic techniques, considdering objecttives, types of defects to be identified, a the role of these teche andhniques with the softwa lifehin are cycle (K22)3.2 Revview Proccess (K2)LO-3.2.1 1 Recall th activities, roles and responsibilities of a typical formal revie (K1) he s ewLO-3.2.2 2 Explain t differenc between different type of reviews informal re the cesess:eview, techniical walkthrough and inspection (K2) review, wLO-3.2.3 3 Explain t factors fo successful performanc of reviews (K2) theorce s3.3 Sta Analys by Too (K2)atic sisolsLO-3.3.1 1 Recall tyypical defects and errors identified by static analys and comp sy sispare them too reviews and dynamic testing (K1) cLO-3.3.2 2 Describe using exame, mples, the ty ypical benefits of static annalysis (K2)LO-3.3.3 3 List typic code and design defecalects that may be identified by static any dnalysis tools (K1)Version 22011Page 31 of 78 31-Maar-2011 Internationa Software Testing Q al Qualifications Board 32. International Certiffied Teste erSoftware Te esting Foundaation Level Sy yllabusQQualifications Board s3.1 Static T Techniques and the Tes Proced stess15 minuttes(K2)TermsDynamic testing, stat testingc ticBackgr roundUnlike dyynamic testin which req ng, quires the ex xecution of sooftware, static testing tecchniques rely onythe manu examinat ual tion (reviews and autom s) mated analysi (static anaisalysis) of the code or otheerproject ddocumentatio without the execution of the code.onReviews are a way o testing soft s of tware work p products (including code) and can be performed well)wbefore dynamic test eexecution. D Defects deteceviews early in the life cy cted during re ycle (e.g., deffectsfound in requirement are often much cheap to remove than those detected by running test onts)pere y tsthe exec cuting code.A review could be do entirely a a manual activity, but there is also tool support The mainwoneas t.manual a activity is to e work product and make coexamine a womments about it. Any sooftware workkproduct c be reviewed, includin requireme can ng ents specifica ations, desig specifications, code, te gn estplans, te specifications, test casest ipts, user guides or web pages. ses, test scriBenefits of reviews in nclude early defect detec ction and cor rrection, deveelopment pro oductivityimprovem ments, reduc developm ced ment timescaales, reduced testing cos and time, lid stifetime costreduction fewer def ns, fects and improved comm munication. Reviews can find omissio R n ons, for exammple,in require ements, whic are unlike to be foun in dynamic testing. chely ndReviews static analy and dynas, ysis amic testing have the same objective identifying defects. Th eg heyare complementary; the different techniques can find diffe erent types o defects effe of ectively andefficiently. Compared to dynamic testing, stat technique find causes of failures (defects) rather d c ticesthan the failures them mselves.Typical ddefects that a easier to find in reviews than in dynamic testin include: d areng deviations froomstandard requireme defects, dds,entdesign defec insufficie maintaina cts,ent ability and inc correct interfa acespecificaations.Version 22011 Page 32 of 78 31-Ma ar-2011 Internationa Software Testing Q al Qualifications Board 33. International Certiffied Teste er Software Te esting Foundaation Level Sy yllabus Q Qualifications Boards3.2Review Proces (K2)wss 25 minut tesTermsEntry criteria, formal review, infor rmal review, inspection, metric, modemerator, peer rreview, review wer,scribe, te echnical review, walkthro oughBackgr roundThe diffeerent types o reviews vary from inform characterized by no written instrofmal,oructions forreviewer to systematic, charactrs,terized by tea participatamtion, docume ented results of the review and s w,documennted proceduures for condducting the reeview. The foormality of a review proce is related toessdfactors ssuch as the mmaturity of the developme process, any legal or regulatory reent equirements or thesneed for an audit trairil.The way a review is carried out d ydepends on t agreed objectives of t review (e thethee.g., find defe ects,gain und derstanding, educate testters and new team memb w bers, or discuussion and d decision byconsenssus).3.2.1Activities of a Form Revie (K1)s mal ewA typical formal revie has the folew ollowing main activities:n1. Plannning D Defining the review criterria S Selecting the personnele A Allocating ro oles D Defining the entry and ex criteria for more forma review type (e.g., insp xitr alespections) S Selecting whhich parts of documents t reviewto C Checking en criteria (f more form review types) ntry formal2. Kickk-off D Distributing ddocuments E Explaining th objectives process an document to the participantshes, nd ts3. Indiv vidual preparration P Preparing for the review meeting by rreviewing the document(s)e N Noting potenntial defects, questions an commentndts4. Exammination/evaaluation/recorrding of resu (review meeting) ultsm D Discussing o logging, with documented results or minutes (fo more form review typ oro ormal pes) N Noting defec making re cts,ecommenda ations regarding handling the defects, making dec cisions about the de a efects E Examining/e evaluating and recording issues during any physic meetings or tracking any g cal a group electro gonic communnications5. Rewwork F Fixing defect found (typtspically done b the author by r) R Recording updated status of defects (in formal reviews)6. Follo ow-up C Checking tha defects ha been addatavedressed G Gathering metrics C Checking on exit criteria (for more for nrmal review types) t3.2.2Roles an Responnd nsibilities (K1)A typical formal revie will includ the roles blewde below:o Manager: decide on the exe esecution of revviews, allocaates time in p project sched dules anddete ermines if the review obje e ectives have been met.Version 22011 Page 33 of 7831-Maar-2011 Internationa Software Testing Q al Qualifications Board 34. International Certiffied Teste erSoftware Te esting Foundaation Level Sy yllabusQQualifications Board so Moderator: the p person who leeads the review of the do ocument or s of documeset ents, includin ngplanning the revi iew, running the meeting, and followinng-up after th meeting. If necessary the he y,moderator may mmediate betw ween the various points of view and is often the pe o serson upon whom wthe ssuccess of th review res he sts.o Auth the writer or person w chief reshor:withsponsibility fo the documorment(s) to be reviewed.o Revi iewers: indiv viduals with a specific technical or bus siness backgground (also called check kers orinspeectors) who, after the necessary prepparation, idenntify and desscribe finding (e.g., defe gs ects) inthe pproduct unde review. Re er eviewers shoould be chose to represe different perspectives anden entsroles in the revie process, a should ta part in any review mesew andake eetings.o Scrib (or recordbe der): docume ents all the isssues, probleems and open points that were identif t fieddurin the meetinngng.Looking at software pproducts or rrelated work products fro different pomperspectives and usingchecklist can make reviews mor effective a efficient. For example a checklist based on varioustsre and e,t vperspecttives such as user, maints tainer, tester or operation or a chec rns, cklist of typica requirements alproblems may help to uncover prs o reviously unddetected issuues.3.2.3Types of Reviews (K2)fA single software prooduct or relat work pro ted oduct may be the subject of more than one review Ifenw.more tha one type o review is uan of used, the ord may vary For example, an inform review ma be dery. mal aycarried o before a touttechnical revview, or an in nspection ma be carried out on a reqay quirementsspecificaation before a walkthroug with customers. The main characte gh meristics, optio and purp onsposesof comm review ty monypes are:Informal Reviewo No foormal processso May take the form of pair pro mogramming o a technical lead revieworwing designs and codeo Resu may be d ultsdocumentedo Varie in usefuln es ness dependi on the re ingeviewerso Main purpose: in nnexpensive w to get sowayome benefitroughWalkthro Mee eting led by a authoro May take the form of scenarios, dry runs, peer group participationm, no Open-ended ses ssions O Optional pre-meeting pre eparation of r reviewers O Optional preparation of a review repo including list of findingort gso Optioonal scribe (who is not th author)heo May vary in prac ctice from qui informal to very formaitealo Main purposes: learning, gaining undersn standing, find ding defectsTechnic Review calo Docuumented, deefined defect--detection pr rocess that inncludes peer and technirs ical experts withw optio onal manageement particippationo May be performe as a peer review witho managemed outment participationo Idea led by trained modera (not the a allyator author)o Pre-meeting prep paration by r reviewerso Optio onal use of cchecklistso Prep paration of a review repor which inclurt udes the list of findings, t verdict whether thethe softw ware product meets its re t equirements and, where appropriate, recommendations relate to a ed findingso May vary in pracctice from qui informal to very formaite alo Main purposes: discussing, making decis nsions, evaluaating alternat tives, finding defects, solg lving technical problem and checmscking conformmance to spe ecifications, pplans, regula ations, and standardsVersion 22011 Page 34 of 78 31-Ma ar-2011 Internationa Software Testing Q al Qualifications Board 35. International Certiffied Teste erSoftware Te esting Foundaation Level Sy yllabusQQualifications Board sInspecti iono Led by trained m moderator (no the author)oto Usua conducte as a peer examination ally edno Defin roles nedo Incluudes metrics gatheringo Form process bmalbased on rules and checcklistso Spec cified entry a exit criter for accepand ria ptance of the software pro oducto Pre-meeting prep parationo Inspection report including lis of findings tsto Form follow-up process (wi optional pmal p ith process improovement com mponents)o Optioonal readero Main purpose: fin nnding defectssWalkthrooughs, technical reviews and inspectiions can be performed wp within a peer ggroup,i.e., colleeagues at the same organizational lev This type of review is called a pe review.e vel.eseer3.2.4Success Factors f Review (K2) s forwsSuccess factors for r s reviews include:o Each review has clear predef h s fined objectivveso The right people for the revie objectives are involvedew s do Test ters are value reviewers who contribedsbute to the reeview and als learn abou the producsoutct whic enables th chhem to prepa tests earlierareo Defe ects found ar welcomed and express objectiveresed elyo Peop issues an psychologple ndgical aspects are dealt with (e.g., mak sking it a positive experien fornce the a author)o The review is conducted in an atmospher of trust; th outcome w not be us for therehewill sed evaluation of the participants eso Reviiew techniqu are applie that are s ues ed suitable to acbjectives and to the type andchieve the oba level of software work produc and reviects ewerso Checcklists or role are used if appropriate to increase effectivenes of defect identificationese ess no Trainning is given in review techniques, esspecially the more formal techniques such asl inspeectiono Management sup pports a goo review prood ocess (e.g., by incorporatb ting adequate time for reveview vities in proje schedules activ ect s)o Ther is an emphasis on lear rerning and proocess improv vementVersion 22011 Page 35 of 78 31-Ma ar-20