Your SlideShare is downloading. ×
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Istqb ctfl syll 2011
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Istqb ctfl syll 2011

768

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
768
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Certifi Tester C ied r Found dation Lev Sy n vel yllabu us Released R Ver rsion 201 11Int ternatio onal Software Testing Qualif g fication Board ns r
  • 2. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board sCopyrigh Notice htThis doc cument may be copied in its entirety, or extracts made, if the s m source is ack knowledged.Copyrigh Notice © In ht nternational Software Teesting Qualific cations Boar (hereinafte called ISTQB®) rd erISTQB is a registered trademark of the Intern s d ware Testing Qualifications Board, national Softw gCopyrigh © 2011 the authors for the update 2011 (Thomas Müller (ch ht e r hair), Debra Friedenberg, andthe ISTQ WG Foun QB ndation Level)Copyrigh © 2010 the authors for the update 2010 (Thomas Müller (ch ht e r hair), Armin B Beer, MartinKlonk, R Rahul Verma) )Copyrigh © 2007 the authors for the update 2007 (Thomas Müller (ch ht e r hair), Dorothy Graham, Debra y D berg and Erik van Veenendaal)Friedenb kCopyrigh © 2005, th authors (T ht he Thomas Mülle (chair), Re Black, Sig Eldh, Dorothy Graham, er ex gridKlaus Ol lsen, Maaret Pyhäjärvi, G Geoff Thompson and Erik van Veenen k ndaal).All rights reserved. sThe auth hors hereby ttransfer the c copyright to t Internatio the onal Softwar Testing Qu re ualifications Board(ISTQB). The author (as current copyright holders) and ISTQB (as th future cop rs t I he pyright holder)have agr reed to the fo ollowing condditions of use e:1) Any individual or training com r mpany 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 ed ource and coopyright owners of the sy yllabus and provided tha any adver at rtisement of such a train ning course m mention the syllabu only may n us after submission for official accreditatio of the tra r n on aining mater rials to an IISTQB recognized Natio onal Board.2) Any individual or group of in r ndividuals ma use this syllabus as t basis for articles, boo ay s the oks, or othe derivative writings if th authors a er he and the ISTQB are acknowledged a the sourc and as ce copy yright owners of the syllabus. s3) Any ISTQB-reco ognized Natio onal Board m translate this syllabu and licens the syllab (or may e us se bus ranslation) to other parties. its tr oVersion 2 2011 Page 2 of 78 7 31-Mar r-2011© Internationa Software Testing Q al Qualifications Board
  • 3. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board sRevision Histo oryVersion Date D Remarks sISTQB 2 2011 Effective 1-Ap E pr-2011 Certified Tester Foundation Level Syllabus l Maintena ance Release – see Appe e endix E – Reelease NotesISTQB 2 2010 Effective 30-M E Mar-2010 Certified Tester Foundation Level Syllabus l Maintena ance Release – see Appe e endix E – Reelease NotesISTQB 2 2007 01-May-2007 0 7 Certified Tester Foundation Level Syllabus l Maintena ance ReleaseeISTQB 2 2005 01-July-2005 0 Certified Tester Foundation Level Syllabus lASQF V2.2 July-2003 J ASQF Sy yllabus Foundation Level Version 2.2 “Lehrplan Grundlagen des Softwa n n are-testens“ISEB V2 2.0 25-Feb-1999 2 ISEB Sof ftware Testin Foundatio Syllabus V2.0 ng on V 25 February 1999Version 2 2011 Page 3 of 78 7 31-Mar r-2011© Internationa Software Testing Q al Qualifications Board
  • 4. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board sTable of Conte entsAcknowledgements.. ........................................ ................................................... 7  ........................................Introducttion to this SSyllabus............................ ................................................... 8  ........................................ Purpo of this Do ose ocument .......................... ................................................... 8  ........................................ The CCertified Test Foundatio Level in S ter on Software Testing .............. ................................................... 8  Learnning Objective es/Cognitive Level of Kno owledge .......................... ................................................... 8  The EExamination . ........................................ ................................................... 8  ........................................ Accreeditation ........ ........................................ ................................................... 8  ........................................ Level of Detail...... ........................................ ................................................... 9  ........................................ How tthis Syllabus is Organized .................. ................................................... 9  ........................................1.  Fun ndamentals o Testing (K of K2)................ ................................................. 10  ........................................ 1.1  Why is Te esting Necessary (K2) ..... ................................................. 11  ........................................ 1.1.1  Software Systems C Context (K1) ....................................... ) ................................................. 11  1.1.2  Causes of Software Defects (K2 .................................... s e 2) ................................................. 11  1.1.3  Role of Testing in S f Software Dev velopment, Maintenance and Operations (K2) ............... 11  M 1.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 Princip ples (K2) ....... ................................................. 14  ........................................ 1.4  Fundamental Test Pro ocess (K1) ... ................................................. 15  ........................................ 1.4   Test Planning and C 4.1 Control (K1) ....................................... ................................................. 15  1.4   Test An 4.2 nalysis and D Design (K1) . ................................................. 15  ........................................ 1.4   Test Im 4.3 mplementatio and Execu on ution (K1)......................... ................................................. 16  1.4   Evaluating Exit Crit 4.4 teria and Rep porting (K1) ..................... ................................................. 16  1.4   Test Cl 4.5 losure Activit ties (K1) ...... ................................................. 16  ........................................ 1.5  The Psych hology of Testing (K2) .... ................................................. 18  ........................................ 1.6  Code of E Ethics ............................... ................................................. 20  ........................................2.  Tes sting Throug ghout the Sof ftware Life C Cycle (K2) ......................... ................................................. 21  2.1  Software Developmen Models (K2 .................................... nt 2) ................................................. 22  2.1.1  V-mode (Sequentia Development Model) (K2) .............. el al ................................................. 22  2.1.2  Iterative e-incrementa Development Models (K2) ............. al ( ................................................. 22  2.1.3  Testing within a Life Cycle Model (K2) ............................ g e ................................................. 22  2.2  Test Leve (K2) ............................ els ................................................. 24  ........................................ 2.2   Compo 2.1 onent Testing (K2) ........... g ................................................. 24  ........................................ 2.2   Integra 2.2 ation Testing (K2) ............ ................................................. 25  ........................................ 2.2   System Testing (K2 ................. 2.3 m 2) ................................................. 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 g n 2) ................................................. 28  2.3   Testing of Non-func 3.2 g ctional Softw ware Characte eristics (Non n-functional T Testing) (K2) ......... 28  2.3   Testing of Software Structure/A 3.3 g e Architecture (Structural Te esting) (K2) .............................. 29  2.3   Testing Related to Changes: Re 3.4 g e-testing and Regression Testing (K2 ........................... 29  d n 2) 2.4  Maintenan Testing ( nce (K2) ............. ................................................. 30  ........................................3.  Sta Techniqu (K2)........................... atic ues ................................................. 31  ........................................ 3.1  Static Tec chniques and the Test Pr d rocess (K2) ...................... ................................................. 32  3.2  Review Process (K2) ..................... ................................................. 33  ........................................ 3.2   Activitie of a Form Review (K ................................... 2.1 es mal K1) ................................................. 33  3.2   Roles a Respons 2.2 and sibilities (K1) ....................................... ) ................................................. 33  3.2   Types o Reviews ( 2.3 of (K2) .............. ................................................. 34  ........................................ 3.2   Succes Factors fo Reviews (K ................................... 2.4 ss or K2) ................................................. 35  3.3  Static Ana alysis 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 De es esign Techniq ques (K2) ........................ ................................................. 39 Version 2 2011 Page 4 of 78 7 31-Mar r-2011© Internationa Software Testing Q al Qualifications Board
  • 5. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s 4.3  Specificat tion-based or Black-box T r Techniques (K3) ............. ( ................................................. 40  4.3   Equivalence Partitio 3.1 oning (K3) ... ................................................. 40  ........................................ 4.3   Bounda Value An 3.2 ary nalysis (K3) .. ................................................. 40  ........................................ 4.3   Decisio Table Tes 3.3 on sting (K3) ..... ................................................. 40  ........................................ 4.3   State T 3.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) ................................................. 42  4.4   Statem 4.1 ment Testing a Coverag (K4) ............................ and ge ................................................. 42  4.4   Decisio Testing an Coverage (K4) ............................... 4.2 on nd e ................................................. 42  4.4   Other S 4.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) ...................... ................................................. 47  5.1.2  Tasks o the Test L of Leader and T Tester (K1) ....................... ................................................. 47  5.2  Test Planning and Est timation (K3)....................................... ) ................................................. 49  5.2   Test Planning (K2) .................... 2.1 ................................................. 49  ........................................ 5.2   Test Planning Activ 2.2 vities (K3) ..... ................................................. 49  ........................................ 5.2   Entry C 2.3 Criteria (K2) ..................... ................................................. 49  ........................................ 5.2   Exit Criteria (K2)........................ 2.4 ................................................. 49  ........................................ 5.2   Test Es 2.5 stimation (K2 ................. 2) ................................................. 50  ........................................ 5.2   Test St 2.6 trategy, Test Approach (K .................................. t K2) ................................................. 50  5.3  Test Prog gress Monitor ring and Con ntrol (K2) ......................... ................................................. 51  5.3   Test Pr 3.1 rogress Monitoring (K1) .. ................................................. 51  ........................................ 5.3   Test Re 3.2 eporting (K2)................... ................................................. 51  ........................................ 5.3   Test Co 3.3 ontrol (K2)....................... ................................................. 51  ........................................ 5.4  Configura ation Manage ement (K2) ... ................................................. 52  ........................................ 5.5  Risk and T Testing (K2) .................... ................................................. 53  ........................................ 5.5   Project Risks (K2) ..................... 5.1 t ................................................. 53  ........................................ 5.5   Produc Risks (K2) .................... 5.2 ct ................................................. 53  ........................................ 5.6  Incident M Management (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 Te esting (K2) ... ................................................. 58  ........................................ 6.1.2  Test To Classifica ool ation (K2) ..... ................................................. 58  ........................................ 6.1.3  Tool Su upport for Ma anagement o Testing an Tests (K1) ............................................... 59  of nd ) 6.1.4  Tool Su upport for Sta Testing (K1) ................................ atic ................................................. 59  6.1.5  Tool Su upport for Te Specificat est tion (K1) .......................... ................................................. 59  6.1.6  Tool Su upport for Te Execution and Loggin (K1) ......... est n ng ................................................. 60  6.1.7  Tool Su upport for Pe erformance a Monitorin (K1)......... and ng ................................................. 60  6.1.8  Tool Su upport for Sp pecific Testin Needs (K1 ................. ng 1) ................................................. 60  6.2  Effective U of Tools Potential B Use s: Benefits and Risks (K2) .. ................................................. 62  6.2   Potential Benefits a Risks of Tool Suppor for Testing (for all tools (K2) ................... 62  2.1 and rt s) 6.2   Special Considerations for Som Types of Tools (K1) .... 2.2 me T ................................................. 62  6.3  Introducin a Tool into an Organiz ng o zation (K1) ....................... ................................................. 64 7.  References ...... ........................................ ................................................. 65  ........................................ Standdards ............ ........................................ ................................................. 65  ........................................ Bookss................... ........................................ ................................................. 65  ........................................8.  Appendix A – S Syllabus Background ....... ................................................. 67  ........................................ Histor of this Doc ry cument ............................ ................................................. 67  ........................................ Objecctives of the F Foundation C Certificate Qualification ...................... ................................................. 67  Objecctives of the I International Qualification (adapted frn rom ISTQB m meeting at So ollentuna, Novem mber 2001).. ........................................ ................................................. 67  ........................................ Entry Requiremen for this Qu nts ualification ... ................................................. 67  ........................................Version 2 2011 Page 5 of 78 7 31-Mar r-2011© Internationa Software Testing Q al Qualifications Board
  • 6. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s Backgground and H History of the Foundation Certificate in Software T e n Testing ..................................... 68 9.  Appendix B – L Learning Obje ectives/Cogn nitive Level of Knowledge ............................................... 69  o e Level 1: Remember (K1) ............................ ................................................. 69  ........................................ Level 2: Understand (K2) ........................... ................................................. 69  ........................................ Level 3: Apply (K3 ..................................... 3) ................................................. 69  ........................................ Level 4: Analyze ( (K4) ................................. ................................................. 69  ........................................10.  Appendix C – Rules App A plied to the IS STQB ............................... ................................................. 71  Founddation Syllab ................................... bus ................................................. 71  ........................................ 10.   Genera Rules ........................... .1.1 al ................................................. 71  ........................................ 10.   Current Content ........................ .1.2 ................................................. 71  ........................................ 10.   Learnin Objectives .................. .1.3 ng s ................................................. 71  ........................................ 10.   Overall Structure ....................... .1.4 l ................................................. 71  ........................................11.  Appendix D – Notice to T A Training Prov viders .............................. ................................................. 73 12.  Appendix E – Release Notes............. A ................................................. 74  ........................................ Relea 2010 ...... ase ........................................ ................................................. 74  ........................................ Relea 2011 ...... ase ........................................ ................................................. 74  ........................................13.  Index ........... ........................................ ................................................. 76  ........................................Version 2 2011 Page 6 of 78 7 31-Mar r-2011© Internationa Software Testing Q al Qualifications Board
  • 7. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board sAckno owledgementsInternatio onal Softwar Testing Qu re ualifications Board Working Group Fooundation Leevel (Edition 2011):Thomas Müller (chair), Debra Friedenberg. T core team thanks the review team (Dan Almog The m m g,Armin Be Rex Black, Julie Gar eer, rdiner, Judy McKay, Tuul Pääkköne Eric Riou du Cosquier Hans la en, rSchaefer, Stephanie Ulrich, Erik van Veenendaal) and all National Booards for the suggestions forthe curre version o the syllabus. ent ofInternatio onal Softwar Testing Qu re ualifications Board Working Group Fo oundation Le evel (Edition 2010):Thomas Müller (chair), Rahul Verma, Martin K Klonk and Arrmin Beer. T core team thanks the The mreview te eam (Rex Bla ack, Mette B Bruhn-Peders son, Debra Friedenberg, Klaus Olsen Judy McKa F n, ay,Tuula Päääkkönen, MMeile Posthum Hans Sc ma, chaefer, Step phanie Ulrich, Pete William Erik van ms,Veenend daal) and all National Boa ards for their suggestions r s.Internatio ualifications Board Working Group Fo onal Softwar Testing Qu re oundation Le evel (Edition 2007):Thomas Müller (chair), Dorothy G Graham, Deb Friedenberg, and Erik van Veenendaal. The core bra k cteam thaanks the revie team (Ha Schaefer Stephanie Ulrich, Meile Posthuma, Anders ew ans r, ePettersson, and Won Kwon) and all the National Boards for their sug nil d ggestions.Internatio ualifications Board Working Group Fo onal Softwar Testing Qu re evel (Edition 2005): oundation LeThomas Müller (chair), Rex Black Sigrid Eldh Dorothy Graham, Klau Olsen, Ma k, h, G us aaret Pyhäjärrvi,Geoff Thhompson and Erik van Ve d eenendaal an the review team and a National B nd w all Boards for theirsuggestions.Version 2 2011 Page 7 of 78 7 31-Mar r-2011© Internationa Software Testing Q al Qualifications Board
  • 8. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board sIntrod duction to this Syllabus n sPurpo of this Docume ose s entThis sylla abus forms t basis for the International Softwar Testing Qualification a the Founda the re at ationLevel. Th Internatio he onal Software Testing Qualifications Board (ISTQB provides it to the Natio e B B) onalBoards f them to accredit the tr for ders and to derive examination quest raining provid d tions in their locallanguage Training p e. providers will determine a appropriate te eaching meth hods and prooduce course eware editation. 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 s nd dixThe C Certified T Tester Foundation Level in Software Testing eThe Foundation Leve qualificatio is aimed a anyone inv el on at volved in softtware testing This includ g. despeople in roles such as testers, te analysts, test enginee test cons n est , ers, sultants, test managers, user tacceptan testers a software developers. This Founda nce and ation Level q qualification i also appro is opriatefor anyone who want a basic un ts nderstanding of software testing, such as project m h managers, qualitymanager software developmen managers, business an rs, nt nalysts, IT dir rectors and mmanagementconsultaants. Holders of the Foundation Certif ficate will be able to go on to a higher n r-level softwa aretesting q qualification.Learni Objec ing ctives/Co ognitive Level of Knowledge K eLearning objectives a indicated for each section in this syllabus and classified as follows: g are d s d so K1: rremembero K2: uunderstando K3: aapplyo K4: aanalyzeFurther d details and e examples of l learning obje ectives are given in Appe endix B.All terms listed under “Terms” jus below chap heading shall be re s st pter gs (K1), even if not emembered (explicitly mentioned in the learnin objectives y ng s.The E Examinatio onThe Foundation Leve Certificate examination will be base on this sy el n ed yllabus. Answ wers toexaminaation question may require the use o material ba ns of ased on more than one section of this e ssyllabus. All sections of the syllab are exam s bus minable.The form of the exa mat amination is multiple cho oice.Exams m be taken as part of a accredited training cou may n an d urse or taken independen (e.g., at an n ntly aexamina ation center o in a public exam). Com or mpletion of an accredited training cou a d urse is not a pre-requisite for the exam e m.Accred ditationAn ISTQ National B QB Board may accredit training providers whose cour material f s rse follows thissyllabus. Training pro oviders shou obtain acc uld creditation guidelines from the board or body that tperforms the accreditation. An ac s ccredited cou urse is recoggnized as con nforming to this syllabus, andis allowe to have an ISTQB exa ed n amination as part of the course.Further g guidance for training prov viders is give in Append D. en dixVersion 2 2011 Page 8 of 78 7 31-Mar r-2011© Internationa Software Testing Q al Qualifications Board
  • 9. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board sLevel of DetailThe leve of detail in this syllabus allows inter el s rnationally co onsistent teaching and ex xamination. Inorder to achieve this goal, the syllabus consis of: stso General instructional objectiv describin the intentio of the Fou ves ng on undation Lev velo A list of informati to teach, including a d ion description, and referenc to additio a ces onal sources if requuiredo Lear rning objectiv for each knowledge a ves area, describ bing the cognnitive learning outcome and a minddset to be acchievedo A list of terms tha students m at must be able to recall and understand e d do A de escription of t key conc the cepts to teach, including sources such as accepte literature or s h ed o standardsThe sylla abus 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 n n ingHow th Syllab is Or his bus rganizedThere ar six major c re 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 hat ed e e orexamplee:2. Tes sting Thr roughout the Sof t ftware Life Cycle (K2) 115 min nutesThis heaading shows that Chapter 2 has learning objective of K1 (ass r es 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 and not d 5 echapter. Within each chapter there are a num mber of sectio ons. Each seection also ha the learning asobjective and the am es mount of time required. S e Subsections that do not h have a time ggiven are includedwithin the time for the section. eVersion 2 2011 Page 9 of 78 7 31-Mar r-2011© Internationa Software Testing Q al Qualifications Board
  • 10. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s1. Fundam mentals of Test ting (K2 2) 15 minu 55 utesLearni Objec ing ctives for Fundam r mentals of Testing fThe obje ectives identify what you will be able t do followin the compl to ng letion of each module. h1.1 Wh is Testing Necess hy sary? (K2)LO-1.1.1 1 Describe with examples, the way in which a defect in sof e, y ftware can ca ause 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 effe use ct ects (K2)LO-1.1.3 3 Give rea asons why testing is nece essary by givving example (K2) esLO-1.1.4 4 Describe why testing is part of qu e g uality assurance and give examples o how testing e of contribut to higher quality (K2) tes rLO-1.1.5 5 Explain a compare the terms e and e error, defect, fault, failure and the cor e, rresponding terms mistake and bug, usi examples (K2) ing s1.2 Wh is Testing? (K2) hatLO-1.2.1 1 Recall th common o he objectives of testing (K1) fLO-1.2.2 2 Provide examples for the objectiv of testing in different phases of th software life ves g he cycle (K2 2)LO-1.2.3 3 Different tiate testing f from debugg ging (K2)1.3 Sev Testin Princip ven ng ples (K2)LO-1.3.1 1 Explain t seven pr the rinciples in te esting (K2)1.4 Fun ndamenta Test Pro al ocess (K1) )LO-1.4.1 1 Recall th five fundamental test a he activities and respective t d tasks from planning to closure (K1)1.5 The Psychology of Tes e sting (K2) )LO-1.5.1 1 Recall th psycholog he gical 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 t t and eloper (K2)Version 2 2011 Page 10 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 11. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s1.1 Why is Testing Necess g sary (K2 2) 20 minut tesTermsBug, def fect, error, fa ailure, fault, m mistake, qual lity, risk1.1.1 Software Systems Context ( e s (K1)Software systems ar an integral part of life, f e re l from busines applications (e.g., ban ss nking) to cons sumerproducts (e.g., cars). Most people have had a experienc with softwa that did n work as s . e an ce are notexpected Software t d. that does not work correc can lead to many pro t ctly oblems, including loss ofmoney, t time or busin ness reputation, and coul even caus injury or de ld se eath.1.1.2 Causes o Softwar Defects (K2) of re sA 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 w ent. ct he ay what it shoul do ld(or do soomething it shouldn’t), 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 bec cause there is time press sure, complexxcode, co omplexity of infrastructure changing t e, technologies, and/or man system int ny teractions.Failures can be caus by enviro sed onmental connditions as well. For example, radiati w ion, magnetissm,electroni fields, and pollution can cause faults in firmwar or influenc the execut ic re ce tion of softwa by arechanging the hardwa conditions. g are1.1.3 Role of TTesting in Software Developm ment, Main ntenance a andOperattions (K2) systems and documentati can help to reduce th risk of problems occurringRigorous testing of s s ion heduring operation and contribute to the quality of the software system, if the defects found are d o s eleased for operational uscorrected before the system is re d se.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.4 Testing 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 lity of und,for both f functional an non-functi nd ional softwar requireme re ents and char racteristics (e e.g., reliabilit ty,usability, efficiency, m maintainability and portabbility). For more information on non-fu unctional tes stingsee Cha apter 2; for more informat tion on software characte eristics see ‘S Software Eng gineering –Software Product Qu e uality’ (ISO 9126).Testing c give con can nfidence in th quality of t software if it finds few or no defec A proper he the w cts. rlydesigned test that pa d asses reduce the overall level of risk in a system When testing does find es k m. ddefects, the quality o the softwar system inc of re creases whe those defe en ects are fixed d.Lessons should be le s ojects. By understanding the root causes of defec earned from previous pro ctsfound in other projec processe can be imp cts, es proved, whic in turn sho ch ould prevent those defect from tsreoccurring and, as a consequennce, improve the quality of future syst o tems. This is an aspect of oquality assurance.Testing s should be int tegrated as o of the qu one uality assurance activities (i.e., alongs s side develop pmentstandard training and defect an ds, nalysis).Version 2 2011 Page 11 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 12. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s1.1.5 How Muc Testing is Enoug ch g gh? (K2)Deciding how much t g testing is eno ough should take accoun of the leve of risk, inclu nt el uding technic cal,safety, a business risks, and p and s project constr raints such as time and b a budget. Risk is discussed k dfurther in Chapter 5. nTesting s should provid sufficient information t stakeholders to make informed decisions abou the de to utrelease o the softwa or system being teste for the next development step or h of are m ed, handover tocustomeers.Version 2 2011 Page 12 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 13. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s1.2 What is Testing? (K2) s 30 minut tesTermsDebugging, requirem ment, review, test case, te esting, test objective oBackgr roundA common perceptio of testing i that it only consists of running tests i.e., execu on is y s, uting the softw ware.This is p of testing but not all o the testing activities. part g, of gTest acti ivities exist b before and af test exec fter cution. Thes activities in se nclude plann ning and conttrol,choosing test conditions, designing and exec g cuting test cases, checkin results, ev ng valuating exit t reporting on the testing pcriteria, r process and system unde test, and fi er completing closure inalizing or cactivities after a test phase has b s been complet ted. Testing also includes reviewing d s documents(including source cod and cond de) ducting static analysis. cBoth dyn esting can be used as a means for ac namic testing and static te g chieving sim milar objective es, rmation that c be used to improve both the systand will provide infor can b tem being tes sted and the edevelopm ment and tessting process ses.Testing c have the following ob can e bjectives:o Finding defectso Gain ning confiden about the level of qua nce e alityo Prov viding information for dec cision-making go Prev venting defecctsThe thouught process and activitie involved in designing tests early in the life cycle (verifying the s es n t etest basis via test design) can he to prevent defects from being intro elp t m oduced into ccode. Review of wsdocumen (e.g., req nts quirements) a the ident and tification and resolution o issues also help to prev d of o ventdefects a appearing in the code.Different viewpoints in testing tak different o t ke objectives into account. F example, in developm o For menttesting (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. In t he a d eacceptan testing, t main obje nce the ective may b to confirm that the system works as expected, to begain connfidence that it has met th requireme he ents. In some cases the m e main objectiv of testing may vebe to asssess the qua of the so ality oftware (with no intention of fixing defeects), to give information to e nstakeholders of the r of releasing the syste at a given time. Maint risk em n tenance testi often incl ing ludestesting th no new d hat defects have been introdu uced during development of the chan d nges. Duringoperational testing, the main objeective may be to assess system chara s acteristics su as reliab uch bility oravailability.Debugging and testin are differe Dynamic testing can show failure that are ca ng ent. c es aused by def fects.Debugging is the dev velopment ac ctivity that fin nds, analyzes and remov the cause of the failur ves e re.Subsequuent re-testin by a tester ensures tha the fix doe indeed res ng at es solve the failure. Theresponsi ibility for thes activities i usually tes se is sters test and developers debug. d sThe proc cess of testin and the te ng esting activitie are explained in Section 1.4. esVersion 2 2011 Page 13 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 14. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s1.3 Seven Testing Principles (K2) ) 35 minut tesTermsExhaustive testingPrincip plesA numbe of testing p er principles ha been sug ave ggested over the past 40 years and offer general rguideline common f all testing es for g.Principle 1 – Testing shows pre esence of d defectsTesting c show tha defects are present, bu cannot pro that there are no defe can at ut ove e ects. Testing greduces the probability of undisco overed defec remaining in the softw cts g ware but, eve if no defec are en ctsfound, it is not a proo of correctn of ness.Principle 2 – Exhau ustive testing is imposs sibleTesting eeverything (a combinatio of inputs and precon all ons s nditions) is no feasible ex ot xcept for trivi ialcases. Innstead of exh haustive test alysis and priorities should be used to focus testing ting, risk ana d oefforts.Principle 3 – Early ttestingTo find d vities shall be started as early as pos defects early, testing activ ssible in the s software or system sdevelopmment life cycle, and shall be focused on defined objectives. oPrinciple 4 – Defect clustering tTesting e effort shall be focused pr e roportionally to the expec cted and later observed ddefect density of ymodules A small number of mod s. dules usually contains mo of the def y ost fects discove ered during pre- prelease t testing, 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 o overcome thi “pesticide paradox”, test cases nee to be regu is ed ularlyreviewed and revised and new a different tests need to be written t exercise d d d, and o to different parts of sthe softwware or syste to find potentially mor defects. em rePrinciple 6 – Testing is context dependent t tTesting i done differ is rently in diffe erent context For example, safety-critical softwa is tested ts. aredifferentl from an e- ly -commerce s site.Principle 7 – Absen nce-of-errors fallacy sFinding a fixing de and efects does n help if the system built is unusable and does n fulfill the users’ not e e notneeds an expectatio nd ons.Version 2 2011 Page 14 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 15. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s1.4 Fundam mental T Test Pro ocess (K K1) 35 minut tesTermsConfirmaation 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 cove ata, dure, test policy, test suite test e,summary report, test y twareBackgr roundThe mos visible part of testing is test executi st t s ion. But to be effective an efficient, t e nd test plans sh houldalso inclu time to b spent on p ude be planning the tests, designing test casses, preparin for execution ngand eval luating result ts.The fund damental tes process co st onsists of the following ma activities: aino Test planning an control t ndo Test analysis and design to Test implementa t ation and exe ecutiono Evaluating exit c criteria and re eportingo Test closure activities tAlthough logically se h equential, the activities in the process may overlap or take plac concurren e p ce ntly.Tailoring these main activities wit g thin the context of the system and the project is u e usually requir red.1.4.1 Test Plan nning and Control ( d (K1)Test plannning is the a activity of de efining the ob bjectives of te esting and th specificatio of test ac he on ctivitiesin order to meet the oobjectives an mission. ndTest con ntrol is the on ngoing activit of comparing actual pr ty rogress again the plan, and reportin the nst ng ncluding deviations from the plan. It instatus, in nvolves takin actions ne ng ecessary to mmeet the misssionand obje ectives of the project. In o e order to contr testing, th testing activities shoul be monitor rol he ld redthrougho the projec Test planning takes in account the feedback from monito out ct. nto k oring and con ntrolactivities s. nning and coTest plan ontrol tasks a defined in Chapter 5 of this syllab are n o bus.1.4.2 Test Ana alysis and Design (K K1)Test anaalysis and deesign is the a activity during which gene testing objectives are transformed into g eral e dtangible test conditio and test c ons cases.The test analysis and design acti d ivity has the following ma tasks: ajoro Revi iewing the te basis (suc as require est ch ware integrity level1 (risk level), risk ements, softw y analysis reports, architecture design, inte e, erface specif fications)o Evaluating testab bility of the te basis and test objects est d so Identifying and p prioritizing tes conditions based on an st nalysis of tes items, the specification st n, behaavior and struucture of the software eo Desi igning and prioritizing hig level test c gh caseso Identifying neces ssary test data to support the test con t nditions and test caseso Desi igning the tes environme setup and identifying any required infrastructu and tools st ent d d ureo Crea ating bi-direc ctional tracea ability betwee test basis and test cas en ses1 The degr to which sof ree ftware complies or must comply with a set of stakeholder-sele s y s ected software a and/or software- -basedsystem cha aracteristics (e.g software com g., mplexity, risk as ssessment, safe level, securit level, desired performance, ety tyreliability, o cost) which a defined to re or are eflect the importa ance of the soft tware to its stak keholders.Version 2 2011 Page 15 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 16. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s1.4.3 Test Imp plementation and Ex xecution (K1)Test imp plementation and executio is the activity where te procedur or scripts are specifie by on est res s edcombinin the test ca ng ases in a par rticular order and includin any other information needed for test r ng 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 n a)o Deve eloping and prioritizing te procedure creating test data and optionally, preparing te est es, t d, est harnnesses and w writing autom mated test scr riptso Crea ating test suit from the test procedu tes ures for efficient test execcutiono Verif fying that the test environ e nment has be set up co een orrectlyo Verif fying and updating bi-dire eability between the test basis and te cases ectional trace esto Exec cuting test prrocedures either manuall or by using test execut ly g tion tools, ac ccording to th he planned sequenc ceo Logg ging the outccome of test execution an recording the identities and versions of the sof nd s ftware unde test, test to er ools and testtwareo Com mparing actua results with expected r al h resultso Repo orting discrepancies as in ncidents and analyzing th d hem in order to establish their cause (e.g., r h a deefect in the coode, in specified test data in the test document, o a mistake in the way th test a, or he was executed)o Repe eating 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 co confirmation testing), exe onfirm a fix (c ecution of a corrected tes and/or exe st ecution of tes in order to ensure tha defects have not been sts t at intro oduced in unc changed areas of the sof ftware or that defect fixing did not unc cover other defeects (regressi testing) ion1.4.4 Evaluatin Exit Cr ng riteria and Reporting (K1) gEvaluatin exit criteria is the activ where te execution is assessed against the defined ng vity est dobjective This shou be done f each test level (see Section 2.2). es. uld for SEvaluatin exit criteria has the following majo tasks: ng oro Chec cking test log against th exit criteria specified in test plannin gs he a n ngo Asse essing if mor tests are n re needed or if t exit criter specified should be ch the ria hangedo Writi a test sum ing mmary repor for stakeho rt olders1.4.5 Test Clos sure Activ vities (K1)Test clos sure activities collect data from comp a pleted test acctivities to consolidate exp perience,testware facts and n e, numbers. Tes closure ac st ctivities occur at project m r milestones su as when a uchsoftware system is re e eleased, a te project is completed (o cancelled), a milestone has been est orachieved or a mainte d, enance relea has been completed. ase nVersion 2 2011 Page 16 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 17. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board sTest clos sure activities include the following m e major tasks:o Chec cking which planned deliverables hav been deliv ve veredo Clos sing incident reports or raaising change records for any that rem e r main openo Docu umenting the acceptance of the syste e e emo Fina alizing and ar rchiving testw ware, the tes environmen and the te infrastruct st nt est ture for later reuseo Hand ding over the testware to the mainten e o nance organi izationo Anal lyzing lesson learned to determine c ns o changes nee eded for futur releases a projects re ando Usin the information gathere to improv test maturity ng ed veVersion 2 2011 Page 17 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 18. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s1.5 The Ps sycholog of Tes gy sting (K2) 25 minut tesTermsError gue essing, indep pendenceBackgr roundThe mind dset to be us while tes sed sting and revviewing is diff ferent from th used whi developing hat ilesoftware With the rig mindset d e. ght developers a able to te their own code, but se are est eparation of this tresponsi ibility to a tes is typically done to help focus eff and provide additiona benefits, su as ster fort al uchan indeppendent view by trained a professio w and onal testing resources. In r ndependent t testing may be bcarried o at any lev of testing. out velA certain degree of in n ndependenc (avoiding t author bias) often ma ce the akes the teste more effec er ctiveat finding defects and failures. Ind g d dependence is not, howe e ever, a replaccement for fa amiliarity, an nddevelope can efficiently find ma defects in their own code. Severa levels of in ers any c al ndependence can ebe define as shown here from lo to high: ed n owo Test designed b the person(s) who wro the softw ts by ote ware under test (low level of independence)o Test designed b another person(s) (e.g from the development team) ts by g., d to Test designed b a person(s) from a diff ts by ferent organi izational grou (e.g., an i up independent test t team or test spe m) ecialists (e.g. usability or performanc test specia ., r ce alists)o Test designed b a person(s) from a diff ts by ferent 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 set and y . d eirby manaagement and other stakeh holders, for e example, to find defects o to confirm that softwar f or m remeets its objectives. Therefore, it is important to clearly state the obje s t ectives of testing.Identifyin failures du ng uring testing may be percceived as criticism agains the produc and agains the st ct 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 curio osity, profess sionalpessimis a critical eye, attentio to detail, g sm, on good commu unication 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 the ommunicated in a constr etesters a the analy and ysts, designe and developers can be avoided. T ers b This applies t defects fou to undduring reeviews as we as in testin ell 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 w way. For the author of the software o document, ordefect in nformation ca help them improve the skills. Defe an m eir ects found and fixed duri testing will ing wsave time and money later, and r y reduce risks..Commun nication prob ccur, particularly if testers are seen o blems may oc only as messengers ofunwante news abou defects. However, ther are severa ways to im ed ut re al mprove comm munication an ndrelations ships betwee testers and others: en dVersion 2 2011 Page 18 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 19. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board so Start with collabo t oration rather than battles – remind everyone of th common goal of bette s e he er quality systemso Commmunicate fin ndings on the product in a neutral, fac e ct-focused w without cr way riticizing the pers who crea son ated it, for example, write objective an factual inc nd cident reports and review s w findingso Try t understand how the ot to ther 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 ve ou d ersaVersion 2 2011 Page 19 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 20. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s1.6 Code o Ethics of s 10 minut tesInvolvemment in software testing e enables indiv viduals to learn confidential and privile eged informa ation. Acode of e ethics 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 the priate use. Re he d hefollowing code of ethics: g oftware teste shall act consistently with the pub interestPUBLIC - Certified so ers blicCLIENT AND EMPLO OYER - Certtified softwar testers sha act in a m re all manner that is in the best interests sof their c client and em mployer, cons sistent with th public inte he erestPRODUC - Certified software te CT d esters shall e ensure 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 inte egrity and ind dependence in their profe essionaljudgmen ntMANAGEMENT - Ce ertified softwa test man are nagers and leeaders shall subscribe to and promote anethical a approach to the managem ment of softw ware testingPROFES SSION - Cer rtified softwar testers shall advance the integrity and reputatio of the pro re on ofessionconsistent with the public interest tCOLLEAAGUES - Cer rtified softwa testers sh be fair to and support are hall tive of their c colleagues, and apromote cooperation with software developer n rsSELF - C Certified softw ware testers shall particip regarding the practice of their pate in lifelon learning r ng eprofessio and shall promote an ethical appro on oach to the practice of the profession p nRefere 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, M Myers, 19791.4 Hetz 1988 zel,1.4.5 Black, 2001, C Craig, 20021.5 Blac 2001, Het ck, tzel, 1988Version 2 2011 Page 20 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 21. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s2. TTesting Throug g ghout th Softw he ware Lif fe 1 minutes 115Cycle (K2) eLearni Objec ing ctives for Testing Througho the S r out Software L Cycle Life eThe obje ectives identify what you will be able t do followin the compl to ng letion of each module. h2.1 Sof ftware 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 con hat nt ust ed ntext of projec and produc characteris ct ct stics (K1)LO-2.1.3 3 Recall ch haracteristics of good tes s sting that are applicable t any life cy e to ycle model (K K1)2.2 Tes Levels ( st (K2)LO-2.2.1 1 Compare the differen levels of te e nt esting: major objectives, typical objec of testing, r cts , typical ta argets of test ting (e.g., fun nctional or st tructural) and related wor products, people d rk who test types of de t, 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 chang e are s , 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-functio and e onal test type based on n es non-functional requireme ents (K2)LO-2.3.4 4 Identify a describe test types b and e based on the analysis of a software sy e ystem’s struc cture or archite ecture (K2)LO-2.3.5 5 Describe the purpose of confirma e e ation testing and regression testing (KK2)2.4 Maintenance Testing ( e (K2)LO-2.4.1 1 Compare maintenance testing (te e esting an existing system to testing a new application m) 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) g on, (K1)LO-2.4.3 3. Describe the role of r e regression te esting and immpact analysis in maintennance (K2)Version 2 2011 Page 21 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 22. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s2.1 Softwa Deve are elopmen Models (K2) nt 20 minut tesTermsCommer rcial Off-The- -Shelf (COTS iterative-i S), incremental development model, validation,verification, V-modelBackgr roundTesting d does not exis in isolation test activiti are relate to softwar developme activities. st n; ies ed re entDifferent developmen life cycle m t nt models need different approaches to testing. d2.1.1 V-model (Sequential Develo opment Mo odel) (K2)Although variants of the V-model exist, a com h l mmon type of V-model us four test levels, f sescorrespo onding to the four develop e pment levelss.The four levels used in this syllab are: r buso Com mponent (unit testing t)o Integgration testin ngo Syst tem testingo Acce eptance testi ingIn practic a V-mode may have more, fewer or different levels of dev ce, el r velopment an testing, nddependin on the pro ng oject and the software pr e roduct. For example, ther may be co re omponentintegratio testing aft compone testing, an system in on ter ent nd ntegration tes sting after sy ystem testing g.Software work produ e ucts (such as business sc s cenarios or use cases, re u equirements s specification ns,design d documents an code) pro nd oduced during developme are often the basis of testing in on or ent f nemore tes levels. Ref st ferences for ggeneric work products include Capab k bility Maturity Model Integ y gration(CMMI) o ‘Software life cycle pro or ocesses’ (IEEEE/IEC 1220 Verification and valid 07). dation (and early etest design) can be c carried out duuring the dev velopment of the software work produ f e ucts.2.1.2 Iterative- -incremen Develo ntal opment Models (K2)Iterative- -incremental developmen is the proc nt cess of estab irements, designing, build blishing requi dingand testi a system in a series o short deve ing m of elopment cyc cles. 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 ced ese may ed during eachiteration. An increme added to others deve . ent, eloped previoously, forms a growing pa artial system,which sh hould also be tested. Reg e gression testing is increas singly import tant on all ite erations after the rfirst one. Verification and validatio can be ca . on arried out on each incremment.2.1.3 Testing w within a Life Cycle M Model (K2 2)In any lif cycle model, there are several characteristics of good testin fe o 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 ic elo The analysis and design of te d ests for a giv test level should begi during the correspondi ven in ing deve elopment act tivityo Test ters should b involved in reviewing d be n documents as soon as dr a rafts are available in the deve elopment life cycleTest leve can be co els ombined or r reorganized ddepending on the nature of the projec or the syst ct temarchitect ture. For exa ample, for the integration of a Comme e ercial Off-The e-Shelf (COT software TS)product into a system the purcha m, aser may per rform integra ation testing a the system level (e.g., at mVersion 2 2011 Page 22 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 23. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board sintegratio to the infr on rastructure and other systems, or sys stem deploym ment) and ac cceptance tes sting(function and/or no nal on-functional, and user an , nd/or operational testing) ).Version 2 2011 Page 23 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 24. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s2.2 Test Le evels (K K2) 40 minut tesTermsAlpha testing, beta te esting, compponent testing driver, field testing, fun g, d nctional requ uirement,integratio integratio testing, no on, on on-functional requiremen robustness testing, stu system te l nt, s ub, esting,test environment, tes level, test-d st driven development, use acceptance testing er eBackgr roundFor each of the test levels, the fo h ollowing can b identified: the generic objectives, t work be c theproduct(s) being refeerenced for dderiving test c cases (i.e., th test basis the test ob he s), bject (i.e., wh is hatbeing tes sted), typical defects and failures to b found, tes harness requirements a tool supp l d be st and port,and spec approac cific ches and responsibilities.Testing a system’s configuration data shall be considered during test planning, e d2.2.1 Component Testin (K2) ngTest bas sis:o Com mponent requuirementso Deta ailed designo Code eTypical t test objects:o Com mponentso Prog gramso Data conversion / migration p a programso Data abase modulesCompon also known a unit, modu or progra testing) searches for d nent testing (a as ule am defects in, an ndverifies t functionin of, softwa modules, programs, objects, class the ng 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 the edevelopm ment life cycle and the sy ystem. Stubs drivers and simulators may be used s, d d.Compon nent testing m include t may testing of fun nctionality an specific no nd on-functional characterist l tics,such as resource-behavior (e.g., searching fo memory le or eaks) or robu ustness testin as well as ng, sstructura testing (e.g decision c al g., coverage). Te cases are derived fro work prod est e om ducts such as a sspecifica ation of the component, th software design or the data model. he eTypically component testing occ y, curs with acce to the co being tes ess ode sted and with the support of a h tdevelopm ment environnment, such as a unit test framework or debugging tool. In practice, comp ponenttesting u usually involv the progr ves rammer who wrote the co ode. Defects are typically fixed as soo as y onthey are found, witho formally m out managing the defects. eseOne app proach to com mponent test ting is to prepare and aut tomate test c cases before coding. This is e scalled a test-first app proach or tes st-driven deve elopment. Th approach is highly iterative and is his h sbased on cycles of developing te cases, the building and integratin small piec of code, and n est en ng ces aexecuting the compo onent tests co orrecting any issues and iterating unt they pass. y tilVersion 2 2011 Page 24 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 25. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s2.2.2 Integratio Testing (K2) on gTest bas sis:o Softwware and sys stem designo Arch hitectureo Workflowso Use casesTypical t test objects:o Subs systemso Data abase implem mentationo Infraastructureo Inter rfaceso Syst tem configura ation and configuration d dataIntegratio testing tests interfaces between components, interactions with differen parts of a on ntsystem, such as the operating sy ystem, file sy ystem and ha ardware, and interfaces b between syst tems.There may be more t than one lev of integrat vel tion testing and it may be carried out on test objec of a e ctsvarying s size as follow ws:1. Com mponent integ gration testin tests the in ng nteractions between softw b ware compo onents and is done s after component testing r2. Syst tem integratio testing tests the intera on actions betwe different systems or between een t harddware and so oftware and m be done after system testing. In this case, the developing may e m g orgaanization may control only one side of the interface. This migh be conside y y f ht ered as a risk k. Business proces sses impleme ented as worrkflows may involve a ser ries of system Cross-platform ms. issue may be si es ignificant.The grea the scop of integrat ater pe tion, the more difficult it becomes to is b solate defect to a specif ts ficcompone or system which may lead to incr ent m, y reased risk and additiona time for tro a al oubleshootingg.Systema integratio strategies may be bas on the sy atic on sed ystem archite ecture (such as top-down and nbottom-u functiona tasks, tran up), al nsaction proc cessing sequ uences, or so ome other asspect of the system sor compo onents. In or rder to ease fault isolation and detect defects earl integration should nor n t ly, n rmallybe increm mental rathe than “big bang”. erTesting o specific no of on-functional characterist (e.g., performance) m be includ in integr l tics may ded rationtesting a well as fun as nctional testin ng.At each stage of inteegration, teste concentr ers rate solely on the integrat n tion itself. Fo example, if they or fare integ grating modu A with mo ule odule B they are intereste in testing the commun ed nication betw weenthe modu ules, not the functionality of the indivi y idual module as that was done during component e s g ttesting. B Both function and struc nal ctural approaches may be used. eIdeally, t testers should understand the archite d ecture and inf fluence integ gration plann ning. If integra ationtests are planned before compon e nents or syste ems are built, those com mponents can be built in th n heorder reqquired for mo efficient t ost testing.Version 2 2011 Page 25 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 26. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s2.2.3 System T Testing (K K2)Test bas sis:o Syst tem and softw ware require ement specificationo Use caseso Func ctional specif ficationo Risk analysis rep k portsTypical t test objects:o Syst tem, user and operation m manualso Syst tem configura ation and configuration d dataSystem ttesting is con ncerned with the behavio of a whole system/prod h or duct. The tes sting scope shall sbe clearl addressed in the Master and/or Lev Test Plan for that test level. ly d vel n nment should correspond to the final target or proIn system testing, the test environ m e d oductionenvironmment as much as possible in order to minimize the risk of environment-spe e e ecific failures not sbeing fou in testing und g.System t testing may include tests based on risks and/or on requirements specifica s o ations, busine essprocesse use case or other high level text descriptions or models of system be es, es, t s ehavior,interactio with the operating sy ons ystem, and syystem resources.System t testing should investigate functional a non-func e and rements of th system, and ctional requir hedata qua characte ality eristics. Teste also need to deal with incomplete or undocum ers d h e mentedrequiremments. System testing of f m functional requirements starts by usin the most a s ng appropriatespecifica ation-based ((black-box) te echniques fo the aspect of the syste to be teste For exam or t em ed. mple, adecision table may b created for combinations of effects described in business ru be s n ules. Structure-based teechniques (wwhite-box) ma then be us to asses the thoroughness of th testing with ay sed ss herespect t a structura element, s to al such as menu structure or web page n u o navigation (s Chapter 4). seeAn indep pendent test team often c carries out sy ystem testing g.2.2.4 Acceptan Testin (K2) nce ngTest bas sis:o User requiremen r ntso Syst tem requirem mentso Use caseso Business proces sseso Risk analysis rep k portsTypical t test objects:o Business proces sses on fully integrated sy ystemo Operational and maintenance processes eo User procedures r so Form mso Repo ortso Conf figuration da ata esponsibility of the customers or user of a system otherAcceptance testing is often the re s rs m;stakeholders may be involved as well. e sThe goal in acceptan testing is to establish confidence in the system parts of th system or nce s h m, he rspecific non-functional characteri istics of the s system. Find ding defects is not the ma focus in ainacceptan testing. A nce Acceptance ttesting may assess the system’s read s diness for de eployment an ndVersion 2 2011 Page 26 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 27. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board suse, alth hough it is no necessarily the final lev of testing. For example, a large-sc ot y vel 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 may t es ample:o A CO OTS software product ma be accept ay tance tested when it is in nstalled or int tegratedo Acce eptance testi of the usa ing ability of a co omponent may be done d during component testing go Acce eptance testi of a new functional en ing nhancement may come b t before system testing mTypical f forms of acce eptance testi include th following: ing heUser accceptance te estingTypically verifies the fitness for use of the sys y stem by business users. onal (acceptOperatio tance) testin ng eptance of th system by the system administrato includingThe acce he y ors, g:o Test ting of backu up/restoreo Disaaster recoverryo User manageme r ento Main ntenance tasskso Data load and m a migration task kso Perioodic checks of security vulnerabilities sContrac and regula ct ation accept tance testin ngContract acceptance testing is pe t e erformed agaainst a contra act’s accepta ance criteria for producingcustom-ddeveloped so oftware. Acc ceptance crite should be defined wh the parti agree to the eria b hen ies tcontract. Regulation acceptance testing is pe . erformed aga ainst any regu ulations 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, en al gcustome in their ma ers arket before the software product is put up for sale commercia e p ally. Alpha te estingis performed at the d developing or rganization’s site but not by the developing team. Beta testing or s g,field-test ting, is perfor rmed by cust tomers or po omers at their own locatio otential custo ons.Organiza ations may u other term as well, s use ms such as facto acceptanc testing an site accep ory ce nd ptancetesting fo systems th are tested before and after being moved to a customer’s s or hat d site.Version 2 2011 Page 27 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 28. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s2.3 Test Ty ypes (K2 2) 40 minut tesTermsBlack-bo testing, co coverage functional testing, inter ox ode e, roperability teesting, load t testing,maintainnability testing performan testing, p g, nce portability tes sting, reliabili testing, se ity ecurity testing,stress te esting, structu testing, u ural usability test ting, white-bo testing oxBackgr roundA group of test activities can be a aimed at veri ifying the sof ftware system (or a part o a system) based m ofon a spe ecific reason or target for testing.A test typ is focused on a partic pe d cular test objeective, which could be an of the follo h ny owing:o A fun nction to be performed by the software yo A no on-functional quality characteristic, su as reliabi or usability uch ilityo The structure or architecture of the softwa or system are mo Change related, i.e., confirmi that defe ing ects have bee fixed (con en nfirmation tes sting) and loo oking for u unintended ch hanges (regrression testinng)A model of the software may be d developed and/or used in structural te n esting (e.g., a control flow wmodel or menu struc r cture model), non-function testing (e nal e.g., performa ance model, usability mo odelsecurity threat modeling), and fun model, a stat transition model nctional testing (e.g., a process flow m teor a plain language s n specification) ).2.3.1 Testing o Functio (Functio of on onal Testi ing) (K2)The func ctions that a system, subs system or co omponent are to perform may be described in work eproducts such as a re s equirements specification use cases or a functio s n, s, onal specifica ation, or they may ybe undoccumented. T functions are “what” t system does. The s the dFunction tests are based on fun nal nctions and ffeatures (des scribed in do ocuments or uunderstood by the btesters) a their inte and eroperability with specific systems, an may be pe c nd erformed at a test levels (e.g., all stests for components may be bas on a com s sed mponent specification).Specifica ation-based ttechniques m be used to derive tes conditions and test cas from the may st s sesfunctiona of the so ality oftware or sy ystem (see C Chapter 4). Fu unctional tes sting conside the extern ers nalbehavior of the softw r ware (black-b testing). boxA type of functional testing, security testing, in f nvestigates the functions (e.g., a firew t s wall) relating to gdetection of threats, such as virus n ses, from ma alicious outsiders. Anothe type of fun er nctional testing,interoper rability testin evaluates the capabili of the soft ng, s ity tware produc to interact with one or more ctspecified component or systems d ts s.2.3.2 Testing o Non-fun of nctional S Software Characteris C stics (Non n-functionalTesting (K2) g)Non-func ctional testing includes, b is not limited to, perfo but ormance testing, load testing, stresstesting, u usability testing, maintain nability testin reliability testing and p ng, t portability tes sting. It is the etesting o “how” the s of system 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 cha s aracteristics of systems and software that can be quantified on a a e ovarying s scale, such a response times for per as rformance te esting. These tests can be referenced to a e dquality m model such a the one de as efined in ‘Sofftware Engineeering – Soft tware Product Quality’ (IS SOVersion 2 2011 Page 28 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 29. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s9126). N Non-functiona testing con al nsiders the external beha avior of the so oftware and in most case esuses bla ack-box test d design techn niques to acc complish that t.2.3.3 Testing o Softwar Structu of re ure/Archite ecture (Str ructural Testing) (K K2)Structura (white-box testing may be perform at all test levels. Structural techni al x) y med t iques are bestused afte specification-based techniques, in order to help measure th thoroughn er p he ness of testin ngthrough assessment of coverage of a type of structure. eCoverag is the exte that a stru ge ent ucture has be exercise by a test s een ed suite, expressed as apercenta of the ite age ems being co verage is not 100%, then more tests m be desig overed. If cov may gnedto 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 st n t esting, tools canbe used to measure the code cov verage of eleements, such as stateme h ents or decisions. Structuraltesting m be based on the arch may d hitecture of th system, such as a cal he s lling hierarch hy.Structura testing app al proaches can also be applied at syste system i n em, integration or acceptance etesting le evels (e.g., to business m o models or me structure enu es).2.3.4 Testing R Related to Changes Re-testing and Re o s: egression Testing (K2)After a d defect is dete ected and fixe the softw ed, ware should be re-tested t confirm th the origina b to hat aldefect ha been succ as cessfully rem moved. This i called confirmation. De is 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 te s ed ested progra after mod am, dification, todiscover any defects introduced o uncovered as a result of the chang r s or d ge(s). These defects may be yeither in the software being tested, or in anoth related or unrelated s e her o software commponent. It is sperforme when the software, or its environm ed ment, is changed. The exttent of regres ssion testing is gbased on the risk of not finding defects in soft n ftware that was working p previously.Tests shhould be repe eatable if the are to be u ey used for conf firmation test ting and to assist regress siontesting.Regress sion testing m be performed at all te levels, an includes functional, no may est nd on-functional andstructura testing. Re al egression tes suites are r many tim and gene st run mes erally evolve slowly, so eregressio testing is a strong can on ndidate for au utomation.Version 2 2011 Page 29 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 30. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s2.4 Maintenance 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. Th ation data, or its environm n heplanning of releases in advance i crucial for successful maintenance testing. A distinction has to be g is m e smade be etween plann releases and hot fixe Maintenan testing is done on an existing ned es. nce s noperational system, a is triggered by modif and gration, or retirement of th software or fications, mig hesystem.Modifica ations include planned en e nhancement c changes (e.g release-ba g., ased), correcctive andemergen changes, and change of environ ncy es nment, such as planned o a stem or database operating sysupgrades, planned upgrade of Co ommercial-OOff-The-Shelf software, or patches to correct newly f rexposed or discovere vulnerabilities of the o d ed operating sys stem.Maintena ance testing for migration (e.g., from one platform to another) should inclu operation n m ude naltests of t new environment as w as of the changed so the well e oftware. Migration testing (conversion g ntesting) i also neede when data from anoth applicatio will be mig is ed a her on grated into th system be he eingmaintainned.Maintenaance testing for the retire ement of a syystem may in esting of data migration or nclude the te aarchiving if long data g a-retention pe eriods are required.In additio to testing what has be changed, maintenanc testing inc on een ce cludes regression testing to gparts of t system that have not been chang the t ged. The sco of mainte ope enance testin is related to the ng trisk of th change, th size of the existing sys he he e stem and to the size of th change. D t he Depending on the nchanges maintenanc testing may be done a any or all test levels an for any or all test types. s, ce at t nd rDetermin ning how the existing sys e stem may be affected by changes is c called impact analysis, an is t ndused to h help decide h how much re egression tes sting to do. The impact analysis may be used to Tdetermin the regres ne ssion test sui ite.Maintena cations are out of date or missing, or testers with ance testing can be diffic if specific cult o rdomain k knowledge a not availa are able.Refere ences2.1.3 CM MMI, Craig, 22002, Hetzel 1988, IEEE 12207 l, E2.2 Hetz 1988 zel,2.2.4 Co opeland, 200 Myers, 19 04, 9792.3.1 Be Black, 2001, Copeland, 2 eizer, 1990, B 20042.3.2 Black, 2001, IS 9126 SO2.3.3 Be eizer, 1990, C Copeland, 20004, Hetzel, 19882.3.4 He etzel, 1988, I IEEE STD 82 29-19982.4 Blac 2001, Cra 2002, He ck, aig, etzel, 1988, I IEEE STD 82 29-1998Version 2 2011 Page 30 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 31. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s3. Static T S Techniques (K2 2) 6 minut 60 tesLearni Objec ing ctives for Static Te r echniquesThe obje ectives identify what you will be able t do followin the compl to ng letion 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 cts b rent static techniqu (K1) uesLO-3.1.2 2 Describe the importa e ance and valu of conside ue ering static te echniques fo the assess or sment of softwa work products (K2) areLO-3.1.3 3 Explain t differenc between s the ce static and dyn namic techniques, consid dering object tives, types of defects to be identified, a the role of these tech e and hniques with the softwa life hin are cycle (K22)3.2 Rev view Proc cess (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 ces es s: eview, techni ical walkthrough and inspection (K2) review, wLO-3.2.3 3 Explain t factors fo successful performanc of reviews (K2) the or ce s3.3 Sta Analys by Too (K2) atic sis olsLO-3.3.1 1 Recall tyypical defects and errors identified by static analys and comp s y sis pare them too reviews and dynamic testing (K1) cLO-3.3.2 2 Describe using exam e, mples, the ty ypical benefits of static an nalysis (K2)LO-3.3.3 3 List typic code and design defe cal ects that may be identified by static an y d nalysis tools (K1)Version 2 2011 Page 31 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 32. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s3.1 Static T Techniques and the Tes Proce d st ess 15 minut tes(K2)TermsDynamic testing, stat testing c ticBackgr roundUnlike dyynamic testin which req ng, quires the ex xecution of so oftware, static testing tec chniques rely on ythe manu examinat ual tion (reviews and autom s) mated analysi (static ana is alysis) of the code or othe erproject d documentatio 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 e execution. D Defects detec eviews early in the life cy cted during re ycle (e.g., def fectsfound in requirement are often much cheap to remove than those detected by running test on ts) per e y tsthe exec cuting code.A review could be do entirely a a manual activity, but there is also tool support The main w one as t.manual a activity is to e work product and make co examine a w omments about it. Any sooftware workkproduct c be reviewed, includin requireme can ng ents specifica ations, desig specifications, code, te gn estplans, te specifications, test cas est ipts, user guides or web pages. ses, test scriBenefits of reviews in nclude early defect detec ction and cor rrection, deve elopment pro oductivityimprovem ments, reduc developm ced ment timescaales, reduced testing cos and time, li d st ifetime 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. ch ely ndReviews static analy and dyna s, ysis amic testing have the same objective – identifying defects. Th e g 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 tic esthan the failures them mselves.Typical d defects that a easier to find in reviews than in dynamic testin include: d are ng deviations fro omstandard requireme defects, d ds, ent design defec insufficie maintaina cts, ent ability and inc correct interfa acespecifica ations.Version 2 2011 Page 32 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 33. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s3.2 Review Proces (K2) w ss 25 minut tesTermsEntry criteria, formal review, infor rmal review, inspection, metric, mode m erator, peer r review, review wer,scribe, te echnical review, walkthro oughBackgr roundThe diffe erent types o reviews vary from inform characterized by no written instr of mal, o ructions forreviewer to systematic, charact rs, terized by tea participat am tion, docume ented results of the review and s w,documen nted proceduures for condducting the reeview. The fo ormality of a review proce is related to ess dfactors s such as the mmaturity of the developme process, any legal or regulatory re ent equirements or the sneed for an audit trai r il.The way a review is carried out d y depends on t agreed objectives of t review (e the the e.g., find defe ects,gain und derstanding, educate testters and new team memb w bers, or discu ussion and d decision byconsenssus).3.2.1 Activities of a Form Revie (K1) s mal ewA typical formal revie has the fo l ew ollowing main activities: n1. Plan nning • D Defining the review criterria • S Selecting the personnel e • A Allocating ro oles • D Defining the entry and ex criteria for more forma review type (e.g., insp xit r al es pections) • S Selecting whhich parts of documents t review to • C Checking en criteria (f more form review types) ntry for mal2. Kick k-off • D Distributing d documents • E Explaining th objectives process an document to the participants he s, nd ts3. Indiv vidual preparration • P Preparing for the review meeting by r reviewing the document(s) e • N Noting potenntial defects, questions an comment nd ts4. Exammination/evaaluation/recorrding of resu (review meeting) ults m • D Discussing o logging, with documented results or minutes (fo more form review typ or o or mal 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 g onic commun nications5. Rewwork • F Fixing defect found (typ ts pically 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 add at ave dressed • G Gathering metrics • C Checking on exit criteria (for more for n rmal review types) t3.2.2 Roles an Respon nd nsibilities (K1)A typical formal revie will includ the roles b l ew de below:o Manager: decide on the exe es ecution of rev views, alloca ates time in p project sched dules and dete ermines if the review obje e ectives have been met.Version 2 2011 Page 33 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 34. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board so Moderator: the p person who leeads the review of the do ocument or s of docume set ents, includin ng planning the revi iew, running the meeting, and followin ng-up after th meeting. If necessary the he y, moderator may m mediate betw ween the various points of view and is often the pe o s erson upon whom w the s success of th review res he sts.o Auth the writer or person w chief res hor: with sponsibility fo the docum or ment(s) to be reviewed.o Revi iewers: indiv viduals with a specific technical or bus siness backgground (also called check kers or inspeectors) who, after the necessary prep paration, idenntify and des scribe finding (e.g., defe gs ects) in the p product unde review. Re er eviewers sho ould be chose to represe different perspectives and en ent s roles in the revie process, a should ta part in any review me s ew and ake eetings.o Scrib (or record be der): docume ents all the is ssues, probleems and open points that were identif t fied durin the meetin ng ng.Looking at software p products or r related work products fro different p om perspectives and usingchecklist can make reviews mor effective a efficient. For example a checklist based on various ts re and e, t vperspecttives such as user, maint s tainer, tester or operation or a chec r ns, cklist of typica requirements alproblems may help to uncover pr s o reviously unddetected issuues.3.2.3 Types of Reviews (K2) fA single software prooduct or relat work pro ted oduct may be the subject of more than one review If e n w.more tha one type o review is u an of used, the ord may vary For example, an inform review ma be der y. mal aycarried o before a t out technical revview, or an in nspection ma be carried out on a req ay quirementsspecifica ation before a walkthroug with customers. The main characte gh m eristics, optio and purp ons posesof comm review ty mon ypes are:Informal Reviewo No foormal proces sso May take the form of pair pro m ogramming o a technical lead review or wing designs and codeo Resu may be d ults documentedo Varie in usefuln es ness dependi on the re ing eviewerso Main purpose: in n nexpensive w to get so way ome benefit roughWalkthro Mee eting led by a authoro May take the form of scenarios, dry runs, peer group participation m , no Open-ended ses ssions • O Optional pre-meeting pre eparation of r reviewers • O Optional preparation of a review repo including list of finding ort gso Optioonal scribe (who is not th author) heo May vary in prac ctice from qui informal to very forma ite alo Main purposes: learning, gaining unders n standing, find ding defectsTechnic Review calo Docu umented, deefined defect--detection pr rocess that in ncludes peer and techni rs ical experts with w optio onal manage ement particippationo May be performe as a peer review witho managem ed out ment participationo Idea led by trained modera (not the a ally ator author)o Pre-meeting prep paration by r reviewerso Optio onal use of c checklistso Prep paration of a review repor which inclu rt udes the list of findings, t verdict whether the the softw ware product meets its re t equirements and, where appropriate, recommendations relate to a ed findingso May vary in prac ctice from qui informal to very forma ite alo Main purposes: discussing, making decis n sions, evalua ating alternat tives, finding defects, sol g lving technical problem and chec ms cking conformmance to spe ecifications, p plans, regula ations, and standardsVersion 2 2011 Page 34 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 35. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board sInspecti iono Led by trained m moderator (no the author) oto Usua conducte as a peer examination ally ed no Defin roles nedo Incluudes metrics gatheringo Form process b mal based on rules and checcklistso Spec cified entry a exit criter for accep and ria ptance of the software pro oducto Pre-meeting prep parationo Inspection report including lis of findings t sto Form follow-up process (wi optional p mal p ith process improovement com mponents)o Optioonal readero Main purpose: fin n nding defects sWalkthro oughs, technical reviews and inspecti ions can be performed w p within a peer g group,i.e., colle eagues at the same organizational lev This type of review is called a “pe review”. e vel. e s eer3.2.4 Success Factors f Review (K2) s for wsSuccess factors for r s reviews include:o Each review has clear predef h s fined objectiv veso The right people for the revie objectives are involved ew s do Test ters are value reviewers who contrib ed s bute to the re eview and als learn abou the produc so ut ct whic enables th ch hem to prepa tests earlier areo Defe ects found ar welcomed and express objective re sed elyo Peop issues an psycholog ple nd gical aspects are dealt with (e.g., mak s king it a positive experien for nce the a author)o The review is conducted in an atmospher of trust; th outcome w not be us for the re he will sed evaluation of the participants e so Revi iew techniqu are applie that are s ues ed suitable to ac bjectives and to the type and chieve the ob a level of software work produc and revie cts ewerso Chec cklists or role are used if appropriate to increase effectivenes of defect identification es e e ss no Trainning is given in review techniques, es specially the more formal techniques such as l inspeectiono Management sup pports a goo review pro od ocess (e.g., by incorporat b ting adequate time for rev e view vities in proje schedules activ ect s)o Ther is an emphasis on lear re rning and proocess improv vementVersion 2 2011 Page 35 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 36. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s3.3 Static A Analysis by Too (K2) s ols 20 minut tesTermsCompiler, complexity control flow data flow, static analys y, w, sisBackgr roundThe obje ective of stati analysis is to find defects in softwa source co and softw ic s are ode ware models s.Static annalysis is per rformed witho actually e out executing the software be e eing examine by the too ed ol;dynamic testing does execute the software co c s e ode. Static analysis can l locate defect that are ha to ts ardfind in dyynamic testin As with re ng. eviews, static analysis fin defects r c nds rather than fa ailures. Static canalysis tools analyz program c ze code (e.g., coontrol flow an data flow) as well as g nd ), generated ou utputsuch as HTML and X XML.The valu of static an ue nalysis is:o Early detection o defects prior to test exe y of ecutiono Early warning ab y bout suspicio aspects o the code or design by t calculatio of metrics such ous of o the on s, as a high comple exity measur reo Identification of d defects not e easily found b dynamic testing by to Dete ecting dependencies and inconsistenc cies in softw ware models s such as links so Impr roved mainta ainability of c code and des signo Prev vention of defects, if lesso are learn in develo ons ned opmentTypical d defects discoovered by sta analysis tools include atic e:o Refe erencing a vaariable with a undefined value an do Inconsistent interfaces betwe modules and compon een s nentso Varia ables that ar not used o are improp re or perly declared do Unre eachable (deead) codeo Miss oneous logic (potentially infinite loops) sing and erroo Overly complicat construct ted tso Prog gramming sta andards violaationso Secu urity vulnerabbilitieso Synt violations of code and software m tax s d modelsStatic an nalysis tools are typically used by dev velopers (che ecking against predefined rules or dprogramming standa ards) before a during component an integration testing or w and nd when checking-incode to cconfiguration manageme tools, and by designers during sof n ent d ftware modelling. Staticanalysis tools may produce a larg number o warning me ge of essages, which need to b well-mana be agedto allow the most effe ective use of the tool. fCompilers may offer some suppo for static a ort analysis, incl luding the ca alculation of m metrics.Refere ences3.2 IEEE 1028 E3.2.2 Gi 1993, van Veenendaa 2004 ilb, n al,3.2.4 Gi 1993, IEE 1028 ilb, EE3.3 van Veenendaal 2004 l,Version 2 2011 Page 36 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 37. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s4. Test De T esign Te echniqu (K4) ues ) 28 minu 85 utesLearni Objec ing ctives for Test Des r sign Tech hniquesThe obje ectives identify what you will be able t do followin the compl to ng letion of each module. h4.1 The Test Dev e velopment Process (K3) tLO-4.1.1 1 Differenttiate between a test desig specificat n gn tion, test case specificatio and test on procedure specificati (K2) ionLO-4.1.2 2 Compare the terms t e test condition test case and test proc n, a cedure (K2)LO-4.1.3 3 Evaluate the quality of test cases in terms of clear traceab e s bility to the re equirements and s expected results (K2 d 2)LO-4.1.4 4 Translate test cases into a well-s e structured tes procedure specification at a level of st n o detail rel levant to the knowledge o the testers (K3) of s4.2 Cat tegories o Test Des of sign Tech hniques (K K2)LO-4.2.1 1 Recall reeasons that b both specification-based (black-box) a structure and e-based (white- box) test design tech t hniques are uuseful and lis the commo technique for each (K st on es K1)LO-4.2.2 2 Explain t characteristics, comm the monalities, an difference between s nd es specification- -based testing, s structure-bas testing a experienc sed and ce-based tes sting (K2)4.3 Spe ecification n-based or Black-bo Techniques (K3) oxLO-4.3.1 1 Write tes cases from given softw st m ware models using equiva alence partiti ioning, bound dary value annalysis, decis sion tables an state transition diagra nd ams/tables (KK3)LO-4.3.2 2 Explain t main pur the rpose of each of the four testing techn h niques, what level and ty of t ype testing c could use the technique, a how cov e and verage may b measured (K2) be dLO-4.3.3 3 Explain t concept of use case testing and its benefits (K the K2)4.4 Str ructure-ba ased or Wh hite-box T Techniques (K4)LO-4.4.1 1 Describe the concep and value o code cove e pt of erage (K2)LO-4.4.2 2 Explain t concepts of statemen and decision coverage and give re the s nt e, easons why these t concepts can also be used at tes levels othe than component testing (e.g., on s e st er g business procedures at system le s s evel) (K2)LO-4.4.3 3 Write tes cases from given contr flows usin statement and decision test design st m rol ng t n techniqu (K3) uesLO-4.4.4 4 Assess s statement an decision c nd coverage for completenes with respe to defined exit ss ect d criteria. ( (K4)4.5 Exp perience-b based Tec chniques ( (K2)LO-4.5.1 1 Recall re easons for w writing test ca ases based on intuition, e o experience an knowledg nd ge about coommon defec (K1) ctsLO-4.5.2 2 Compare experience e e-based tech hniques with specification n-based testin technique (K2) ng es4.6 Cho oosing Te Techni est iques (K2) )LO-4.6.1 1 Classify test design t techniques a according to their fitness t a given co t to ontext, for the test e basis, re espective moodels and sof ftware characcteristics (K2 2)Version 2 2011 Page 37 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 38. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s4.1 The Te Deve est elopmen Proces (K3) nt ss 15 minut tesTermsTest cas specificatio test desig test exec se on, gn, cution schedule, test proc cedure speci ification, test tscript, tra aceabilityBackgr roundThe test developmen process de nt escribed in th section ca be done in different w his an ways, from ve eryinformal with little or no documen ntation, to very formal (as it is describ below). T level of s bed Theformality depends on the context of the testin including the maturity of testing an development y n t ng, ndprocesse time cons es, straints, safe or regulat ety tory requirem ments, and th people inv he volved.During te analysis, the test basis document est tation is analyzed in orde to determin what to te er ne est,i.e., to id dentify the tes conditions A test cond st s. dition is defin as an item or event th could be ned hatverified b one or mo test case (e.g., a fun by ore es nction, transaaction, quality characteris or structu stic uralelement) ).Establishhing traceability from test conditions b t back to the specifications and require s s ements enabblesboth effe ective impact analysis wh requirem t hen ments change and determ e, mining requir rements coveeragefor a set of tests. Dur ring test analysis the deta ailed test approach is implemented to select the test o tdesign teechniques to use based o among o o on, other consideerations, the identified risks (see Chapter 5for more on risk analysis).During te design th test cases and test dat are create and specif est he s ta ed fied. A test c case consists of a sset of inp values, e put execution preeconditions, e expected res sults and exe ecution postc conditions, de efinedto cover a certain tes objective(s or test con st s) ndition(s). The ‘Standard for Software TestDocume entation’ (IEE STD 829-1998) descri EE ibes the cont tent of test design specifi ications(containi test cond ing ditions) and test case spe ecifications.Expected results sho d ould be produ uced as part of the specification of a test case and include outputs,changes to data and states, and any other co s onsequences of the test. If expected r s results have notbeen def fined, then a plausible, but erroneous result may be interpret as the co s, y ted orrect one.Expected results sho d ould ideally b defined pr to test ex be rior xecution.During te implemen est ntation the te cases are developed, implemente prioritized and organiz in est e ed, d zedthe test p procedure sp pecification (IEEE STD 829-1998). Th test proce he edure specifies the sequeenceof action for the exe ns ecution of a ttest. If tests a run using a test execution tool, the sequence of are gactions is specified in a test scrip (which is an automated test procedure). n pt dThe vario test proc ous cedures and automated t ently formed into a test test scripts are subsequeexecutio schedule t on that defines t order in w the which the various test pro ocedures, an possibly ndautomate test script are execu ed ts, uted. The test execution schedule will take into account suchfactors a regression tests, prioritization, and technical an logical dependencies. as n ndVersion 2 2011 Page 38 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 39. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s4.2 Catego ories of T Test Design Tec chnique es 15 minut tes(K2)TermsBlack-bo test design technique, experience- ox n -based test design techni d ique, test des sign techniqu ue,white-bo test design technique ox nBackgr roundThe purp pose of a tes design tech st hnique is to i identify test conditions, te cases, an test data. c est nd assic distinction to denote test techniqIt is a cla e ques as blacck-box or whiite-box. Blacck-box test de esigntechniqu (also called specificat ues tion-based te echniques) are a way to d a derive and select testcondition test cases, or test dat based on an analysis of the test ba documentation. This ns, ta o asis sincludes both functio onal and non- -functional te esting. Black k-box testing, by definition, does not use uany infor rmation rega arding the inte ernal structure of the com mponent or ssystem to be tested. Whit te-boxtest design technique (also calle structural or structure- es ed -based technniques) are b based on ananalysis of the struct ture of the co omponent or system. Black-box and w white-box tes sting may als be socombine with exper ed rience-based techniques to leverage the experien of develo d nce opers, testers and susers to determine w what should b tested. beSome techniques fall clearly into a single cate egory; others have eleme s ents of more than onecategory y.This sylla abus refers t specificatio to on-based tes design tec st chniques as bblack-box tec chniques and dstructure e-based test design technniques as whhite-box techniques. In ad ddition exper rience-based test ddesign teechniques ar covered. reCommon characteris n stics of specification-base test design techniques include: ed so Models, either fo ormal or infor rmal, are use for the spe ed ecification of the problem to be solved the f m d, softw ware or its co omponentso Test cases can b derived sy t be ystematically from these models yCommon characteris n stics of struct ture-based te design te est echniques incclude:o Infor rmation abou how the so ut oftware is constructed is used to deriv the test ca ve ases (e.g., code c and detailed des sign informatiion)o The extent of covverage of the software ca be measu e an ured for exist ting test case and furthe test es, er case can be derived system es matically to in ncrease coveerageCommon characteris n stics of experrience-based test design techniques include: do The knowledge a experien of people are used to derive the t and nce e o test caseso The knowledge o testers, de of evelopers, us sers and othe stakeholde about the software, it er ers e ts usag and its en ge nvironment is one source of informatio s ono Knowwledge abou likely defec and their distribution is another so ut cts i ource of infor rmationVersion 2 2011 Page 39 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 40. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s4.3 Specification-b based or Black-b r box 1 minu 150 utesTechn niques ( (K3)TermsBoundar value analysis, decisio table testin equivalen partitioni ry on ng, nce ing, state transition testin use ng,case tes sting4.3.1 Equivale ence Partit tioning (K K3)In equivaalence partitiioning, inputs to the softw s ware or syste are divide into group that are em ed psexpected to exhibit s d similar behavvior, so they a likely to be processed in the same way. are b dEquivale ence partition (or classes can be fou for both valid data, i.e., values that should be ns s) und eaccepted and invalid data, i.e., va d alues that shhould be rejected. Partitio can also be identified for ons doutputs, internal valuues, time-rela ated values ( (e.g., before or after an e event) and for interfaceparameters (e.g., inte egrated commponents bein tested during integrati testing). T ng ion Tests can be edesigned to cover all valid and in d l nvalid partitions. Equivale ence partition ning is applic cable at all levels oftesting.Equivale ence partition ning can be uused to achie input and output cove eve d erage goals. It can be ap ppliedto human input, input via interfac to a syste or interfa paramete in integra ces em, ace ers ation testing.4.3.2 Boundar Value A ry Analysis (K K3)Behavior at the edge of each equ r e uivalence partition is mor likely to be incorrect th behavior within re e hanthe partit tion, so boun ndaries are a area wher testing is likely to yield defects. The maximum and an re eminimum values of a partition are its boundar values. A boundary va m e ry b alue for a vali partition is a id s undary value the bounda of an inva partition is an invalid boundary vavalid bou e; ary alid alue. Tests can be cdesigned to cover bo valid and invalid boun d oth ndary values. When desig gning test ca ases, a test fooreach bou undary value is chosen. eBoundar value analysis can be applied at all test levels. It is relatively easy to apply and its defect- ryfinding c capability is h high. Detailed specificatio are helpf in determi d ons ful ining the inte erestingboundar ries.This techhnique is ofte considere as an exte en ed ension of equ uivalence partitioning or o other black-b boxtest design technique It can be used on equ es. uivalence cla asses for use input on sc er creen as well as,for exam mple, on time ranges (e.g., time out, tr ransactional speed requirements) or t table ranges (e.g., stable size is 256*2566).4.3.3 Decision Table Testing (K3) n )Decision tables are a good way t capture sy n to ystem require ements that ccontain logic conditions and cal s,to documment internal system design. They ma be used to record com ay o mplex business rules that atsystem is to impleme When cr ent. reating decision tables, th specificati is analyz he ion zed, and cond ditionsand actio of the sy ons entified. The input conditions and actions are mos often stated in ystem are ide stsuch a w that they must be true or false (Boolean). The decision tab contains the triggering way y e blecondition often com ns, mbinations of true and false for all inp conditions and the res f put s, sulting action for nseach com mbination of conditions. E Each column of the table corresponds to a busine rule that n e essdefines a unique com mbination of conditions an which res in the exe nd sult ecution of the actionsassociated with that rule. The cov dard commonly used with decision table testing is to verage stand h shave at lleast one tes per column in the table which typic st n e, cally involves covering all combination of s l nstriggering conditions. g .Version 2 2011 Page 40 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 41. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board sThe strength of decis sion table tes sting is that it creates com t mbinations o conditions that otherwis of semight no have been exercised during testing It may be applied to all situations w ot g. a when the actio of on ware depends on several logical decisthe softw sions.4.3.4 State Tra ansition Te esting (K3 3)A system may exhibi a different response de m it epending on current cond ditions or previous history (its ystate). In this case, th aspect of the system can be show with a sta transition diagram. It allows n hat f wn ate athe teste to view the software in terms of its states, trans er e sitions betwee states, the inputs or events en ethat trigg state cha ger anges (transit tions) and the actions whhich may result from thos transitions The se s.states of the system or object und test are s f der separate, ide entifiable and finite in num d mber.A state table shows t relationship between the states and inputs, an can highli the a nd ight possibletransition that are in ns nvalid.Tests ca be designe to cover a typical sequ an ed uence of states, to cover every state, to exercise every r ,transition to exercise specific seq n, e quences of t transitions or to test invalid transitions r s.State tra ansition testin is much used within th embedded software in ng he d ndustry and technicalautomation in genera However, the techniqu is also suitable for mo al. ue odeling a bus siness objecthaving sspecific states or testing s s screen-dialog flows (e. for Intern applicatio or busine gue .g., net ons essscenarioos).4.3.5 Use Case Testing (K2) eTests ca be derived from use ca an d ases. A use c case describ interactio between actors (user or bes ons rssystems), which prodduce a result of value to a system use or the cus t er stomer. Use c cases may bebdescribe at the abst ed tract level (business use case, technoology-free, bbusiness proc cess level) or at othe syste level (sys em stem use cas on the sys se stem function nality level). Each use ca has asepreconditions which need to be m for the us case to work successf met se w fully. Each use caseterminate with postc es conditions which are the observable results and final state of t system after r the a case has bee completed A use cas usually has a mainstrethe use c en d. se eam (i.e., most likely) sce enarioand alter rnative scena arios.Use case describe t “process flows” throu a system based on its actual likely use, so the test es the s ugh m s ecases deerived from u cases are most usefu in uncover use ul ring defects in the proces flows durin ss ngreal-worl use of the system. Use cases are v ld e very useful fo designing acceptance tests with orcustomeer/user participation. They also help u y uncover integgration defects caused by the interact y tionand inter rference of d different components, which individua component testing wou not see. al t uldDesignin test cases from use ca ng s ases may be combined with other spe w ecification-ba ased testtechniqu ues.Version 2 2011 Page 41 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 42. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s4.4 Structu ure-base or Wh ed hite-box 60 minut tesTechn niques (K4)TermsCode co overage, deci ision coverag statemen coverage, structure-ba ge, nt ased testingBackgr roundStructure e-based or wwhite-box testing is based on an ident d tified structur of the soft re tware or thesystem, as seen in th following examples: heo Com mponent level: the structu of a softw ure ware component, i.e., stattements, deccisions, branc ches or ev distinct p ven pathso Integ gration level: the structure may be a c tree (a diagram in wh call hich modules call other s modules)o Syst tem level: the structure m be a men structure, business pr e may nu rocess or web page strucctureIn this se ection, three code-related structural te design te d est echniques for code cover rage, based on ostatemen branches and decisio nts, ons, are disc cussed. For decision test d ting, a contro flow diagra ol ammay be u used to visuaalize the alte ernatives for e each decisio on.4.4.1 Statemen Testing and Cove nt g erage (K4)In compoonent testing statement coverage is the assessm g, ment of the pe ercentage of executable fstatemen that have been exerc nts e cised by a tes case suite. The statem st echnique derives ment testing te atements, normally to increase statemtest case to execute specific sta es e ment coverag ge.Statement coverage is determine by the num ed mber of exec cutable statements cover by (desig red gnedor execu uted) test cas divided b the numbe of all exec ses by er ments in the code under test. cutable statem4.4.2 Decision Testing a Cover n and rage (K4)Decision coverage, r n related to braanch testing, is the asses ssment of the percentage of decision e eoutcome (e.g., the T es True and Fal options o an IF statement) that ha been ex lse of ave xercised by a testcase suite. The decission testing t technique deerives test ca ases to execu specific d ute decision outccomes.Branche originate fr es rom decision points in the code and show the tran n e s nsfer of contr to differen rol ntlocations in the code s e.Decision coverage is determined by the numb of all dec n s d ber cision outcom covered by (designe or mes edexecuted test cases divided by t number o all possible decision ou d) s the of e utcomes in th code under hetest.Decision testing is a form of cont flow testin as it follow a specific flow of cont through the n trol ng ws c trol tdecision points. Deciision coverag is stronge than statem ge er ment coverag 100% de ge; ecision cover rageguarante 100% sta ees atement cove erage, but no vice versa ot a.4.4.3 Other Structure-ba ased Tech hniques (K K1)There ar stronger le re evels of struc ctural covera beyond decision cove age d erage, for ex xample, cond ditioncoverage and multiple condition c e coverage.The conc cept of coverage can also be applied at other test levels For example, at the integration dlevel the percentage of modules, components or classes that have be exercised by a test ca s een d asesuite cou be expres uld ssed as moddule, componnent or class coverage.Tool sup pport is usefu for the stru ul uctural testing of code. gVersion 2 2011 Page 42 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 43. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s4.5 Experie ence-ba ased Tec chniques (K2) s 30 minut tesTermsExploratory testing, ( (fault) attackBackgr roundExperiennce-based teesting is where tests are d derived from the tester’s skill and intu uition and the eirexperien with similar applicatio and technologies. Wh used to a nce ons hen augment sys stematictechniquues, these tec chniques can be useful in identifying special tests not easily c n n s captured by formal ftechniquues, especially when applied after mo formal ap ore pproaches. However, this technique may myield wid degrees of effectiveness, depending on the tester experienc dely varying d rs’ ce.A commonly used ex xperience-ba ased techniqu is error gu ue uessing. Gen nerally tester anticipate rsdefects b based on exp perience. A sstructured ap pproach to th error gues he ssing techniq is to queenumera a list of possible defects and to de ate esign tests th attack the defects. This systematic hat eseapproach is called fa attack. Th ault hese defect and failure lists can be built based on experience n e,available defect and failure data, and from co e ommon know wledge about why softwar fails. t reExploratory testing is concurrent test design, test executio test loggi and learn s on, ing ning, based on a otest char containin test object rter ng tives, and ca arried out within time-box xes. It is an a approach that ismost use where th eful here are few or inadequat specificati te ions and sev vere time pre essure, or in order oto augme or complement other more forma testing. It can serve as a check on the test proc ent r, al c s cess,to help e ensure that th most serio defects a found. he ous areVersion 2 2011 Page 43 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 44. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s4.6 Choosi Test Techniques (K ing t K2) 15 minut tesTermsNo specific terms.Backgr roundThe choice of which test techniqu to use de ues epends on a number of fa actors, includ ding the type of esystem, regulatory st tandards, customer or co quirements, level of risk, type of risk, test ontractual reqobjective documenta e, ation availab knowledg of the test ble, ge ters, time and budget, de d evelopment li ifecycle, us case models and prev se vious experie ence with types of defects found. sSome techniques are more applicable to cert e tain situations and test levels; others are applicab to bleall test le evels.When cr reating test c cases, testers generally u a combin s use nation of test techniques including pro ocess,rule and data-driven techniques t ensure adequate cove to erage of the o object under test.Refere ences4.1 Crai 2002, Het ig, tzel, 1988, IE EEE STD 829-19984.2 Beiz 1990, Co zer, opeland, 200 044.3.1 Co opeland, 200 Myers, 19 04, 9794.3.2 Co opeland, 200 Myers, 19 04, 9794.3.3 Be eizer, 1990, C Copeland, 20 0044.3.4 Be eizer, 1990, C Copeland, 20 0044.3.5 Co opeland, 200044.4.3 Be eizer, 1990, C Copeland, 20 0044.5 Kaner, 20024.6 Beiz 1990, Co zer, opeland, 200 04Version 2 2011 Page 44 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 45. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s5. Test Ma T anagem ment (K3 3) 17 minu 70 utesLearni Objec ing ctives for Test Managemen r ntThe obje ectives identify what you will be able t do followin the compl to ng letion of each module. h5.1 Tes Organiz st zation (K2)LO-5.1.1 1 Recognize the impor rtance of indeependent tessting (K1)LO-5.1.2 2 Explain t benefits and drawbac of indepe the cks endent testin within an o ng organization (K2)LO-5.1.3 3 Recognize the differe team members to be considered for the creation of a test team ent (K1)LO-5.1.4 4 Recall th tasks of a typical test l he leader and te ester (K1)5.2 Tes Planning and Est st timation (K K3)LO-5.2.1 1 Recognize the differe levels an objectives of test plann ent nd ning (K1)LO-5.2.2 2 Summar rize the purpose and content of the te plan, test design spec est cification and test d procedure document according to the ‘Stand ts dard for Softwware Test Documentatio on’ (IEEE St 829-1998) (K2) td )LO-5.2.3 3 Differenttiate between conceptual different te approach n lly est hes, such as analytical, model- m based, mmethodical, p process/stand dard complia dynamic/heuristic, co ant, onsultative and regressioon-averse (K K2)LO-5.2.4 4 Differenttiate between the subject of test planning for a sy n t ystem and sccheduling tes st executio (K2) onLO-5.2.5 5 Write a ttest execution schedule f a given se of test cas for et ses, considerring prioritiza ation, and techhnical and log gical dependdencies (K3)LO-5.2.6 6 List test preparation and executio activities that should b considered during test on t be t planning (K1) gLO-5.2.7 7 Recall tyypical factors that influenc the effort related to testing (K1) s ceLO-5.2.8 8 Differenttiate between two concep n ptually differe estimatio approache the metric ent on es: cs- based ap pproach and the expert-b d based approa (K2) achLO-5.2.9 9 Recognize/justify ade equate entry and exit crit y teria for spec test leve and group of cific els ps test case (e.g., for integration te es esting, accep ptance testing or test case for usability g es testing) ( (K2)5.3 Tes Progres Monitor st ss ring and C Control (K K2)LO-5.3.1 1 Recall co ommon metr used for monitoring test preparation and exec rics cution (K1)LO-5.3.2 2 Explain a compare test metrics for test rep and e s porting and te control (e est e.g., defects found f and fixed and tests p d, passed and ffailed) relate to purpose and use (K ed e K2)LO-5.3.3 3 Summar rize the purpose and content of the te summary report document accord est y ding to the ‘Stan ndard for Sof Documentatio (IEEE Std 829-1998) (K2) ftware Test D on’5.4 Configuratio Manage on ement (K2)LO-5.4.1 1 Summar rize how configuration ma anagement supports test s ting (K2)5.5 Ris and Tes sk sting (K2)LO-5.5.1 1 Describe a risk as a possible pro e oblem that wo ould threaten the achieve n ement of one or e more sta akeholders’ p project objectives (K2)LO-5.5.2 2 Rememb that the level of risk is determined by likelihoo (of happen ber s d od ning) and impact (harm re esulting if it does happen) (K1) )LO-5.5.3 3 Distinguish between the project a product risks (K2) andLO-5.5.4 4 Recognize typical product and pr roject risks (K K1)LO-5.5.5 5 Describe using exam e, mples, how r analysis and risk man risk nagement may be used for test f planning (K2) gVersion 2 2011 Page 45 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 46. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s5.6 Inc cident Man nagement (K3)LO-5.6.1 1 Recognize the conte of an incid ent dent report according to t ‘Standard for Softwar a the d re Test Doccumentation’ (IEEE Std 8 ’ 829-1998) (KK1)LO-5.6.2 2 Write an incident rep covering the observa port ation of a failu during te ure esting. (K3)Version 2 2011 Page 46 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 47. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s5.1 Test Organizat tion (K2) 30 minut tesTermsTester, test leader, te manager est r5.1.1 Test Org ganization and Indep pendence (K2) eThe effectiveness of finding defects by testing and review can be imp g ws proved by ussing independenttesters. O Options for in ndependenc include the following: ce eo No in ndependent testers; deve elopers test t their own coddeo Inde ependent test ters within th developme teams he ento Inde ependent test team or gro within the organizatio reporting to project management or t oup e on, o execcutive manag gemento Inde ependent test ters from the business or e rganization or user comm o munityo Inde ependent test specialists f specific te types suc as usability testers, se t for est ch ecurity tester or rs certification teste (who cert a softwar product ag ers tify re gainst standa ards and regu ulations)o Inde ependent test ters outsourc or extern to the org ced nal ganizationFor large complex o safety critic projects, it is usually best to have multiple leve of testing, with e, or cal b els vels done by independent testers. Development ssome or all of the lev staff may part ticipate in tes sting,especially at the lowe levels, but their lack of objectivity often limits th effectiveness. The er t f o heirindepend dent testers may have th authority to require and define test processes a rules, bu he o d and uttesters s should take o such process-related r on roles only in the presence of a clear m e management tmandate to do so. eThe benefits of indep pendence incclude:o Indeependent test ters see othe and differe defects, and are unbiased er ent ao An inndependent tester can ve erify assumpptions people made during specificatio and e on imple ementation o the system of mDrawbac include: ckso Isola ation from the developme team (if tr e ent reated as tot tally independent)o Deve elopers may lose a sense of respons e sibility for qua alityo Indeependent tes bottleneck or blamed for d sters may be seen as a b delays in rele easeTesting ttasks may be done by pe e eople in a specific testing role, or may be done by someone in g y y nanother role, such as a project m s manager, qua manager developer, business an domain ex ality r, nd xpert, cture or IT operations.infrastruc5.1.2 Tasks of the Test Leader an Tester (K1) f nd (In this sy yllabus two te positions are covered test leader and tester. The activities and tasks est s d, rperforme by people in these two roles depen on the pro ed e o nd oject and prooduct contex the people in the xt, eroles, an the organization. ndSometim the test leader is called a test ma mes anager or tes coordinator The role of the test leader st r. fmay be pperformed by a project m y manager, a de evelopment manager, a q quality assur rance manag or gerthe mana arger projects two positio may exist: test leader and test ager of a tes group. In la st ons rmanager Typically th test leade plans, mon r. he er nitors and co ontrols the testing activitie and tasks as es sdefined i Section 1.4. inTypical t test leader ta asks may inc clude:o Coordinate the te strategy a plan with project managers and o est and h otherso Write or review a test strateg for the pro e gy oject, and tes policy for th organizati st he ionVersion 2 2011 Page 47 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 48. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board so Cont tribute the te esting perspe ective to othe project act er tivities, such as integratio planning ono Plan the tests – c n considering t context a understa the and anding the test objectives and risks – s incluuding selectin test appro ng oaches, estim mating the tim effort and cost of testing, acquirin me, ng resoources, defini test levels, cycles, an planning in ing nd ncident managemento Initia the specif ate fication, prep paration, imp plementation and execution of tests, m monitor the te est results and chec the exit criteria cko Adap planning b pt based on tes results and progress (sometimes do st d ocumented in status repo n orts) and take any act tion necessary to compen nsate for pro oblemso Set u adequate configuratio managem up e on ment of testwa for tracea are abilityo Introoduce suitabl metrics for measuring test progress and evalua le r s ating the qua of the tes ality sting and the producto Deci what sho ide ould be autom mated, to what degree, and howo Sele tools to su ect upport testing and organi any traini in tool us for testers g ize ing se so Deci about the implementa ide e ation of the te environm est mento Write test summary reports b e based on the information gathered du e uring testingTypical t tester tasks m include: mayo Revi iew and cont tribute to test plans to Anal lyze, review and assess user requirements, specifications and models for testability d ro Crea test spec ate cificationso Set u the test environment ( up (often coordinating with system administration and network s management)o Prep pare and acqquire test datao Implement tests on all test levels, execute and log the tests, evalu e e uate the resu and docu ults ument the d deviations fro expected results om do Use test adminis stration or ma anagement tools and test monitoring tools as requuiredo Auto omate tests (may be supp developer or a test autom ported by a d mation expertt)o Mea asure performmance of com mponents and systems (if applicable) fo Revi iew tests devveloped by o othersPeople w work on test analysis test design specific test types or te automatio may be who s, n, est onspecialis in these ro sts oles. Depend ding on the t test level and the risks re d product and the elated to the pproject, d ople may take over the role of tester, keeping som degree of independence. different peo e k meTypically testers at th componen and integr y he nt ration level would be developers, test w ters at theacceptan test leve would be business expe and use and teste for operat nce el erts ers, ers tional accept tancetesting w would be ope erators.Version 2 2011 Page 48 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 49. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s5.2 Test Pl lanning and Est timation (K3) 40 minut tesTermsTest app proach, test s strategy5.2.1 Test Plan nning (K2) )This secction covers t purpose o test planning within de the of evelopment a impleme and entation proje ects, maintenance activities. Planning may be documenand for m e y nted in a master test plan and in sepa n aratetest plan for test lev ns vels such as system testin and acceptance testin The outlin of a test- ng ng. neplanning document is covered by the ‘Standa for Softwa Test Doc g s y ard are cumentation’ (IEEE Std 829- 81998).Planning is influence by the test policy of the organizatio the scope of testing, o g ed t e on, e objectives, risks,constrain criticality testability a the avail nts, y, and lability of res sources. As the project an test plann nd ningprogress more inform s, mation becomes availabl and more detail can be included in the plan. le e nTest plan nning is a co ontinuous act tivity and is p performed in all life cycle processes a activities and s.Feedbac from test a ck activities is u used to recog gnize changin risks so th planning can be adjusted. ng hat5.2.2 Test Plan nning Activities (K3 3)Test plan nning activities for an ent system o part of a sy tire or ystem may in nclude:o Dete ermining the scope and ri isks and iden ntifying the objectives of testing oo Defin ning the overall approach of testing, i h including the definition of the test leve and entry and e f els y exit ccriteriao Integ grating and ccoordinating the testing a activities into the software life cycle ac e ctivities (acquisition, supply, developm ment, operat tion and maintenance)o Mak king decisions about what to test, wha roles will perform the te activities, how the tes s t at p est , st activvities should be done, and how the te results wil be evaluate est ll edo Sche eduling test a analysis and design activ vitieso Sche eduling test i implementati ion, executio and evalua on ationo Assigning resour rces for the d different activvities defineddo Defin ning the amo ount, level of detail, struc f cture and tem mplates for th test docum he mentationo Sele ecting metrics for monitor s ring and cont trolling test preparation a execution defect reso p and n, olution and risk issueso Setti the level of detail for test procedu ing ures in order to provide en nough informmation to sup pport reprooducible test preparation and executi t n ion5.2.3 Entry Criteria (K2) )Entry criteria define w when to start testing such as at the beginning of a test level or when a set of t h ttests is r ready for exe ecution.Typically entry criteria may cover the following: y ro Test environmen availability and readine t nt esso Test tool readine in the tes environment t ess sto Test table code av vailabilityo Test data availab t bility5.2.4 Exit Crite (K2) eriaExit crite define wh to stop t eria hen testing such as at the end of a test lev or when a set of tests has d vel sachieved specific goa d al.Version 2 2011 Page 49 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 50. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board sTypically exit criteria may cover t following: y theo Thor roughness m measures, such as covera of code, functionality or risk age yo Estim mates of defe density o reliability m ect or measureso Cost to Resi idual risks, such as defec not fixed or lack of tes coverage i certain are cts st in easo Sche edules such as those bas on time t market sed to5.2.5 Test Esti imation (K K2)Two app proaches for the estimatio of test effo are: on orto The metrics-base approach estimating the testing effort based o metrics of former or si ed h: e on f imilar ects or based on typical v proje d valueso The expert-based approach: estimating the tasks bas on estimates made b the owner of the sed by tasks or by experts sOnce the test effort is estimated, resources c be identif e s can fied and a sc chedule can b drawn up be p.The testing effort ma depend on a number o factors, inc ay n of cluding:o Characteristics o the produc the quality of the speci of ct: y ification and other inform mation used fo test or models (i.e., the test basis), t size of th product, th complexit of the prob the he he ty blem domain, the requuirements for reliability an security, a the requi r nd and irements for documentati iono Characteristics o the development proce of ess: the stabi of the org ility ganization, to ools used, te est proccess, skills of the people i f involved, and time pressure do The outcome of t testing: the n number of de efects and th amount of rework requ he f uired5.2.6 Test Stra ategy, Tes Approac (K2) st chThe test approach is the impleme entation of th test strategy for a spec project. The test app he cific proachis define and refined in the test plans and te designs. It typically inc ed d est cludes the deecisions mad debased on the (test) p n project’s goal and risk ass l sessment. It is the startin point for planning the test ng tprocess, for selecting the test des , g sign techniqu and test types to be applied, and for defining the ues dentry and exit criteria d a. ected approa depends on the conte and may consider risk hazards a safety,The sele ach ext ks, andavailable resources a skills, the technology the nature of the system (e.g., cust e and y, tom built vs.COTS), ttest objective and regu es, ulations.Typical aapproaches i include:o Anal lytical approaaches, such as risk-base testing where testing is directed to areas of gre ed s eatest risko Model-based app proaches, su as stocha uch astic testing using statist tical informat tion about faiilure rates (such as re s eliability grow models) o usage (such as operat wth or tional profiless)o Meth hodical appro oaches, such as failure-b h based (includ ding error guessing and f fault attacks), expe erience-base checklist- ed, -based, and q quality charaacteristic-bas sedo Proc cess- or standard-complia approach ant hes, such as those specif fied by indus stry-specific standards or the various agile methodolo e ogieso Dyna amic and heuristic approaches, such as explorato testing w ory where testing is more reac ctive to even than pre-planned, and where exec nts d cution and ev valuation are concurrent tasks eo Cons proaches, such as those in which test coverage is driven primarily by the advice sultative app t s a and guidance of technology a and/or business domain experts outs side the test t teamo Regression-aver approach rse hes, such as those that in nclude reuse of existing test material, extensive automation of func ctional regres ssion tests, and standard test suites a dDifferent approaches may be com t s example, a risk-based dynamic appro mbined, for e oach.Version 2 2011 Page 50 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 51. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s5.3 Test Pr rogress Monitor ring and Control 20 minut tes(K2)TermsDefect density, failur rate, test c re control, test m monitoring, te summary report est y5.3.1 Test Progress Mon nitoring (K K1)The purp pose of test mmonitoring is to provide f s feedback and visibility ab d bout test activvities. Inform mationto be mo onitored may be collected manually or automatica and may be used to m y d ally measure exit tcriteria, s such as cove erage. Metric may also b used to assess progre against t planned cs be ess theschedule and budget Common t e t. test metrics include:o Perc centage of wo done in t ork test case preeparation (or percentage of planned te cases est preppared)o Perc centage of wo done in t ork test environmment preparaationo Test case execution (e.g., nu t umber of test cases run/n run, and t t not test cases pa assed/failed) )o Defe informatio (e.g., defe density, d ect on ect defects found and fixed, f d failure rate, a re-test re and esults)o Test coverage of requiremen risks or c t f nts, codeo Subj jective confiddence of test ters in the pr roducto Date of test mile es estoneso Test ting costs, including the c cost compare to the ben ed nefit of finding the next de efect or to run the next test t5.3.2 Test Rep porting (K2 2)Test reporting is concerned with summarizing information about the te g n esting endea avor, includin ng:o Wha happened during a per at riod of testing such as da g, ates when ex criteria we met xit ereo Anal lyzed informaation and me etrics to supp recommendations an decisions about future port nd e actio ons, such as an assessm ment of defects remaining the econom benefit of continued g, mic f testing, outstandding risks, and the level o confidence in the tested software of e dThe outline of a test summary rep is given in ‘Standard for Software Test Docum port d e mentation’ (IEEEStd 829- -1998).Metrics s should be co ollected durin and at the end of a tes level in ord to assess ng st der s:o The adequacy of the test objectives for th test level f hato The adequacy of the test app f proaches tak keno The effectivenes of the testi with resp ss ing pect to the ob bjectives5.3.3 Test Con ntrol (K2)Test con ntrol describe any guidin or correcti actions ta es ng ive aken as a res of inform sult mation and metrics mgathered and reporte Actions m cover an test activit and may a d ed. may ny ty affect any oth software life hercycle act tivity or task. .Example of test con es ntrol actions include:o Mak king decisions based on in s nformation fr rom test mon nitoringo Re-pprioritizing tests when an identified ris occurs (e.g., software delivered lat sk te)o Changing the tes schedule d to availa st due ability or unav nment vailability of a test environo Setti an entry criterion requ ing uiring fixes to have been re-tested (confirmation t o tested) by a deve eloper before accepting them into a b e buildVersion 2 2011 Page 51 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 52. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s5.4 Configu uration M Manage ement (K K2) 10 minut tesTermsConfigur ration manag gement, vers sion controlBackgr roundThe purp pose of configuration management is to establish and maintain the integrit of the prod ty ducts(compon nents, data a documen and ntation) of the software or system thro e r ough the proj ject and prod ductlife cycle e.For testing, configura ation manageement may involve ensur ring the following:o All items of testw ntified, versio controlled, tracked for changes, related to each other ware are iden on h and related to deevelopment it tems (test obbjects) so tha traceability can be maintained at y throuughout the te process esto All iddentified doc cuments and software item are refere ms enced unambiguously in test docuumentationFor the t tester, config guration management hel to unique identify (a to reprod lps ely and duce) the tes steditem, tes documents the tests and the test h st s, harness(es).During te planning, the configur est , ration manag gement procedures and i infrastructure (tools) shou be e uldchosen, documented and implem d mented.Version 2 2011 Page 52 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 53. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s5.5 Risk an Testing (K2) nd 30 minut tesTermsProduct risk, project risk, risk, risk-based test tingBackgr roundRisk can be defined as the chanc of an even hazard, th n ce nt, hreat or situa ation occurrin and result ng ting inundesiraable consequuences or a p potential prob blem. The level of risk will be determi ined by thelikelihood of an adve d appening and the impact (the harm re erse event ha d esulting from that event).5.5.1 Project R Risks (K2) ) risks are the risks that surround the project’s capaProject r ability to deliv its object ver tives, such as:o Orga anizational faactors: • Skill, trai ining and sta shortages aff s • Personn issues nel • Political issues, such as: h Problems with testers co ommunicating their needs and test res g s sults Failure by the team to follow up on innformation fo ound in testin and review ng ws (e.g., not impproving deve elopment and testing prac d ctices) • Improper attitude tow ward or expectations of te esting (e.g., n appreciating the value of not finding d defects during testing) go Tech hnical issues s: • Problem in defining the right req ms quirements • The exte to which r ent requirements cannot be met given ex s xisting constr raints • Test env vironment no ready on tim ot me • Late data conversion migration p a n, planning and development and testing data d conversi ion/migration tools n • Low qua of the de ality esign, code, c configuration data, test data and tests n so Supp plier issues: • Failure o a third part of ty • Contract tual issuesWhen an nalyzing, managing and m mitigating the risks, the test manag is followin well-estab ese e ger ng blishedproject m management principles. T ‘Standar for Software Test Docu t The rd umentation’ ( (IEEE Std 82 29-1998) ouutline for test plans requir risks and contingenci to be stat t res d ies ted.5.5.2 Product Risks (K2 2)Potential failure area (adverse f as future events or hazards) in the software or system are known as s ) m nproduct r risks, as they are a risk to the quality of the produ y o uct. These in nclude:o Failu ure-prone software delive eredo The potential tha the softwar at re/hardware could cause harm to an individual or company e ro Poor software ch r haracteristics (e.g., functionality, reliability, usability and perfor s rmance)o Poor data integri and qualit (e.g., data migration issues, data c r ity ty conversion pr roblems, data a sport problem violation of data standards) trans ms,o Softw ware that does not perfor its intended functions rmRisks are used to de e ecide where t start testin and where to test more testing is u to ng e e; used to reduce therisk of an adverse eff n fect occurring, or to reduce the impac of an adve ct erse effect.Version 2 2011 Page 53 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 54. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board sProduct risks are a s special type o risk to the success of a project. Tes of sting as a ris sk-control act tivityprovides feedback ab s bout the residual risk by measuring th effectiven he ness of critica defect rem al movaland of co ontingency pplans.A risk-baased approac to testing provides pro ch oactive oppo ortunities to re educe the lev vels of produ uctrisk, star rting in the in nitial stages o a project. I involves the identificatio of produc risks and th of It on ct heiruse in gu uiding test planning and c control, spec eparation and execution o tests. In a risk- cification, pre d ofbased ap pproach the risks identifie may be used to: edo Dete ermine the te technique to be employed est eso Dete ermine the ex xtent of testin to be carr ng ried outo Prior ritize testing in an attemp to find the critical defec as early a possible pt cts aso Dete ermine wheth any non-t her ities could be employed t reduce risk (e.g., provi testing activi e to iding training to inexpe erienced des signers)Risk-bas testing draws on the collective kn sed nowledge and insight of th project sta d he akeholders to tdetermin the risks a the levels of testing r ne and s required to ad ddress those risks. eTo ensur that the ch re hance of a product failure is minimize risk mana e ed, ivities provide a agement actidiscipline approach to: edo Asse (and reassess on a regular basis) what can go wrong (risk ess ks)o Dete ermine what risks are imp portant to deal witho Implement action to deal wit those risks ns thIn additio testing m support t identificat on, may the tion of new risks, may he to determ r elp mine what risk ksshould b reduced, a may lower uncertaint about risks be and ty s.Version 2 2011 Page 54 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 55. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s5.6 Inciden Manag nt gement (K3) 40 minut tesTermsIncident logging, incident manage ement, incide report entBackgr roundSince on of the obje ne ectives of tes sting is to find defects, the discrepanc d cies between actual and nexpected outcomes n d need to be loogged as inc cidents. An inncident must be investiga t ated and may turnout to be a defect. Ap e ppropriate acctions to disp pose incidents and defec should be defined. Inc cts e cidentsand defeects should b tracked fro discovery and classification to cor be om y rrection and confirmation of the nsolution. In order to m manage all inncidents to c completion, an organizatio should es a on stablish an in ncidentmanagement proces and rules f classificat ss for tion.Incidents may be rais during development, review, test s sed , ting or use of a software product. The may f eybe raised for issues i code or the working sy d in ystem, or in any type of d a documentatio including onrequiremments, develo opment docu uments, test d documents, and user info ormation suc as “Help” or chinstallatio guides. onIncident reports have the followin objectives e ng s:o Prov vide develope and othe parties with feedback about the pro ers er h a oblem to enable identifica ation, isola ation and corrrection as neecessaryo Prov ders a means of tracking the quality of the system under test a the progress vide test lead s o m and of the testingo Prov vide ideas for test proces improveme r ss entDetails o the inciden report may include: of nt yo Date of issue, iss e suing organiz zation, and aauthoro Expe ected and ac ctual resultso Identification of t test item (configuratio item) and environment the on to Softw ware or syste life cycle process in w em which the inc cident was ob bservedo Desc cription of the incident to enable repro oduction and resolution, including log database d gs, e dum or screen mps nshotso Scop or degree of impact on stakeholde pe e n er(s) interestsso Seve erity of the im mpact on the systemo Urge ency/priority to fixo Statu of the inci us ident (e.g., o open, deferre duplicate, waiting to b fixed, fixed awaiting re ed, , be d e-test, closeed)o Conc clusions, reccommendatio and appr ons rovalso Glob issues, su as other areas that m be affect by a change resulting from the inc bal uch may ted g cidento Change history, such as the sequence of actions take by project team memb f en t bers with res spect to the incident to isolate, repa and conf o air, firm it as fixed do Refe erences, inclu uding the ideentity of the t test case spe ecification tha revealed t problem at theThe structure of an in ncident report is also cov vered in the ‘Standard for Software Te r estDocume entation’ (IEE Std 829-1998). EEVersion 2 2011 Page 55 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 56. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board sRefere ences5.1.1 Black, 2001, H Hetzel, 19885.1.2 Black, 2001, H Hetzel, 19885.2.5 Black, 2001, C Craig, 2002, I IEEE Std 8299-1998, Kaner 20025.3.3 Black, 2001, C Craig, 2002, H Hetzel, 1988 IEEE Std 829-1998 8, 85.4 Crai 2002 ig,5.5.2 Black, 2001 , IEEE Std 8299-19985.6 Blac 2001, IEE Std 829-1 ck, EE 1998Version 2 2011 Page 56 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 57. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s6. Tool Su T upport f Testi (K2) for ing ) 8 minutes 80Learni Objec ing ctives for Tool Sup r pport for TestingThe obje ectives identify what you will be able t do followin the compl to ng letion of each module. h6.1 Typ of Tes Tools (K pes st K2)LO-6.1.1 1 Classify different types of test too according to their purpose and to the activities of ols g s the funda amental test process and the softwar life cycle ( t d re (K2)LO-6.1.3 3 Explain t term test tool and the purpose of tool support for testing (K 2 the t e K2)6.2 Effe ective Use of Tools Potentia Benefits and Risk (K2) e s: al s ksLO-6.2.1 1 Summar rize the poten ntial benefits and risks of test automa s f ation and too support for ol r testing (K K2)LO-6.2.2 2 Rememb special c ber consideration for test exe ns ecution tools static analy s, ysis, and tes st management tools (K K1)6.3 Intr roducing a Tool into an Orga o anization (K1)LO-6.3.1 1 State the main princi e iples of introd ducing a tool into an orgaanization (K1 1)LO-6.3.2 2 State the goals of a p e proof-of-conc cept for tool evaluation and a piloting phase for to ool impleme entation (K1)LO-6.3.3 3 Recognize that facto other than simply acquiring a tool are required for good too ors n ol support (K1)2 LO-6.1.2 Intentiona skipped allyVersion 2 2011 Page 57 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 58. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s6.1 Types of Test T Tools (K K2) 45 minut tesTermsConfigur ration manag gement tool, coverage too debugging tool, dynam analysis tool, inciden ol, mic ntmanagement tool, load testing to modeling tool, monito ool, g oring tool, performance te esting tool, probeeffect, re equirements managemen tool, review tool, security tool, static analysis tool, stress tes nt w c stingtool, test comparator test data pr t r, reparation to test desig tool, test h ool, gn harness, test execution tool, ttest man nagement too unit test fr ol, ramework too ol6.1.1 Tool Sup pport for T Testing (K K2)Test tool can be use for one or more activit ls ed r ties that support testing. These inclu ude:1. Tools that are dir rectly used in testing suc as test exe n ch ecution tools test data ge s, eneration too ols and result compa arison tools2. Tools that help in managing t testing process such as those used to manag tests, test n the ge results, data, req quirements, incidents, defects, etc., and for report ting and mon nitoring test exec cution3. Tools that are us in reconn sed naissance, or, in simple terms: explor t ration (e.g., t tools that mo onitor file a activity for an application) n )4. Any tool that aids in testing (a spreadshe is also a test tool in this meaning) s a eet tTool sup pport for testing can have one or more of the follow e e wing purpose depending on the con es ntext:o Impr rove the efficciency of test activities by automating repetitive ta t y asks or suppoorting manua test al activ vities like test planning, te design, te reporting and monitor t est est ringo Auto omate activiti that require significan resources when done m ies nt manually (e.g static test g., ting)o Auto omate activiti that cann be execut manually (e.g., large scale perfor ies not ted y rmance testin of ng clien nt-server app plications)o Increease reliabilit of testing (e.g., by auto ty omating large data comp parisons or siimulating behaavior)The term “test frameworks” is als frequently used in the industry, in a least three meanings: m so at eo Reus sable and ex ting libraries that can be used to build testing tool (called tes xtensible test d ls st harnnesses as weell)o A typ of design of test autom pe mation (e.g., data-driven, keyword-driven) ,o Overall process of execution of testingFor the p purpose of th syllabus, the term “tes framework is used in its first two meanings as his st ks” sdescribe in Section 6.1.6. ed6.1.2 Test Too Classific ol cation (K2 2)There ar a number of tools that support diffe re erent aspects of testing. T s Tools can be classified based eon sever criteria su as purpose, commerc / free / op ral uch cial pen-source / shareware, technology used orth. Tools a classified in this syllab according to the testi activities that they support.and so fo are bus ingSome to ools clearly su upport one a activity; other may suppo more than one activity but are rs ort n y,classified under the a d activity with w which they are most clossely associate Tools fro a single ed. omprovider, especially tthose that ha been des ave signed to work together, may be bund dled into one epackage e.Some types of test to ools can be intrusive, which means th they can affect the ac hat ctual outcome of ethe test. For example the actual timing may b different due to the ex instructio that are e, be d xtra onsexecuted by the tool, or you may get a differe measure of code cove d , y ent erage. The c consequence of eintrusive tools is calle the probe effect. e ed eVersion 2 2011 Page 58 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 59. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board sSome to ools offer sup pport more ap ppropriate fo developers (e.g., tools that are used during or s dcompone and component integ ent gration testing Such tools are marke with “(D)” i the list bel g). ed in low.6.1.3 Tool Sup pport for M Manageme of Testing and T ent Tests (K1)Management tools apply to all tes activities o st over the entir software life cycle. reTest Ma anagement T ToolsThese toools provide interfaces for executing ttests, tracking defects an managing requirement nd ts,along with support fo quantitative analysis an reporting of the test objects. They also suppor or e nd rttracing th test objec to require he cts ement specifications and might have a independent version control an ccapability or an interf face to an ex xternal one.Require ements Mana agement To oolsThese to ools store req quirement sta butes for the requirement (including atements, store the attrib tspriority), provide uniq identifier and suppo tracing the requiremen to individu tests. Th que rs ort e nts ual hesetools ma also help w identifyin inconsiste or missing requirements. ay with ng entIncident Manageme Tools (D t ent Defect Tracking Tools)These to ools store and manage in ncident repor i.e., defec failures, change requ rts, cts, uests or percceivedproblems and anoma s alies, and he in managi the life cy elp ing ycle of incide ents, optionally with supp for portstatistica analysis. alConfiguuration Mana agement ToolsAlthough not strictly t h test tools, the are nece ese essary for sto orage and veersion manag gement oftestware and related software especially whe configuring more than one hardware/software e en genvironm ment in terms of operating system ver s g rsions, comppilers, browse etc. ers,6.1.4 Tool Sup pport for S Static Test ting (K1)Static tes sting tools pr rovide a cost effective wa of finding more defects at an earlie stage in th t ay er hedevelopm ment process s.Review ToolsThese toools assist with review pro ocesses, che ecklists, revie guideline and are us to store and ew es sed acommun nicate review comments a report on defects and effort. They can be of f w and n d y further help by bproviding aid for onlin reviews fo large or ge g ne or eographically dispersed t y teams.Static A Analysis Too (D) olsThese to velopers and testers find defects prior to dynamic testing by providing support ools help dev r rcing coding standards (infor enfor cure coding), analysis of s ncluding sec structures an dependen nd ncies.They can also help in planning or risk analysi by providin metrics fo the code (e n n r is ng or e.g., complex xity).Modelin Tools (D) ngThese to ools are used to validate software mo d odels (e.g., physical data model (PDM for a relational M)database by enume e), erating inconnsistencies and finding deefects. These tools can o e often aid ingenerating some test cases base on the mo ed odel.6.1.5 Tool Sup pport for T Test Speci ification (K K1)Test Dessign ToolsThese to ools are used to generate test inputs or executable tests and/o test oracle from d e or esrequirem ments, graphi ical user inte erfaces, desig models (s gn state, data or object) or c r code.Version 2 2011 Page 59 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 60. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board sTest Dat Preparation Tools taTest data preparation tools manip a n pulate databases, files or data transm missions to set up test da to atabe used during the e execution of t tests to ensu security th ure hrough data anonymity.6.1.6 Tool Sup pport for T Test Execu ution and Logging ( (K1)Test Exeecution TooolsThese to ools enable te ests to be ex xecuted autoomatically, or semi-autom r matically, usin stored inp ng putsand expeected outcom mes, through the use of a scripting language and usually prov h vide a test log for geach tes run. They c also be u st can used to recor tests, and usually support scripting languages or rd gGUI-bas configura sed ation for para ameterization of data and other customization in th tests. n d heTest Harness/Unit T Test Framewwork Tools ( (D)A unit test harness o framework facilitates th testing of components or parts of a system by or he csimulatin the enviro ng hich that test object will ru through the provision of mock objects onment in wh un,as stubs or drivers. sTest ComparatorsTest commparators de etermine diffe erences betw ween files, da atabases or t test results. T Test executio ontools typ pically include dynamic co e omparators, but post-exeecution comp parison may b done by a beseparate comparison tool. A test comparator may use a te oracle, especially if it is automate e n est t ed.Coverag Measurem ge ment Tools (D)These toools, through intrusive or non-intrusive means, me e easure the peercentage of specific types of f uctures that have been ecode stru exercised (e.g statements, branches or decisions and module or g., s s,function calls) by a set of tests.Security Testing To y oolsThese toools are used to evaluate the security characterist of softwa d e y tics are. This inccludes evaluaatingthe abilit of the softw ty ware to prote data conf ect fidentiality, in ntegrity, authentication, a authorization, ,availability, and non--repudiation. Security too are mostly focused on a particular technology, ols y nplatform, and purpos se.6.1.7 Tool Sup pport for P Performan and Mo nce onitoring (K1)Dynamic Analysis T c Tools (D)Dynamic analysis too find defec that are e c ols cts evident only when softwa is executi w are ing, such as timedepende encies or memory leaks. They are typ pically used in componen and compo nt onent integraationtesting, a when tes and sting middlew ware.Perform mance Testin ng/Load Tessting/Stress Testing Too olsPerforma ance testing tools monito and report on how a sy or ystem behaves under a v variety of sim mulatedusage co onditions in t terms of num mber of concu urrent users, their ramp-u pattern, fr up requency and drelative p percentage o transaction The simu of ns. ulation of load is achieved by means o creating vi d d of irtualusers caarrying out a selected set of transactio ons, spread across variou test mach a us hines commo onlyknown a load gener as rators.Monitorring ToolsMonitorin tools cont ng tinuously ana alyze, verify and report on usage of s specific syste resources and em s,give war rnings of pos ssible service problems. e6.1.8 Tool Sup pport for S Specific Te esting Nee (K1) edsData Qu uality AssessmentData is a the center of some pro at ojects such as data conve ersion/migrat tion projects and applicat tionslike data warehouses and its attri a s ibutes can va in terms of criticality a volume. In such cont ary and texts,tools nee to be emp ed ployed for da quality as ata ssessment to review and verify the da conversio and o ata onVersion 2 2011 Page 60 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 61. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board smigration rules to ensure that the processed data is corre complete and complie with a pre n e ect, e es e-defined c context-spec standard cific d.Other tes sting tools ex for usabi testing. xist ilityVersion 2 2011 Page 61 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 62. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s6.2 Effectiv Use o Tools: Poten ve of ntial 20 minut tesBenefits and Risks (K K2)TermsData-driv testing, k ven keyword-driv testing, s ven scripting lang guage6.2.1 Potential Benefits and Risks of Tool Support fo Testing (for all to s S or g ools)(K2)Simply p purchasing or leasing a to does not guarantee success with that tool. Each type of to ool oolmay requ additional effort to ac uire chieve real a lasting be and enefits. Ther are potent benefits and re tial aopportun nities with the use of tools in testing, b there are also risks. e s but ePotential benefits of using tools in nclude:o Repe etitive work i reduced (e is e.g., running regression tests, re-ente ering the sam test data, and me checcking against coding stan t ndards)o Grea consiste ater ency and repe eatability (e.g tests exec g., cuted by a to in the sam order with the ool me h same frequency, and tests de , erived from r requirements s)o Obje ective assess sment (e.g., static measu ures, coverag ge)o Ease of access t information about tests or testing (e e to n s e.g., statistic and graphs about test cs prog gress, inciden rates and performance nt e)Risks of using tools include:o Unre ealistic expecctations for th tool (inclu he uding functionality and ea of use) aseo Unde erestimating the time, co and effort for the initia introduction of a tool (in ost al n ncluding train ning and external exp pertise)o Unde erestimating the time and effort need to achiev significant and continu d ded ve t uing benefits from tool (including the need fo changes in the testing process and continuous improvement of the t or g d s the w the tool is used) wayo Unde erestimating the effort required to ma aintain the test assets generated by th tool heo Over-reliance on the tool (rep n placement fo test design or use of au or n utomated tes sting where manual testing w would be bett ter)o Neglecting versio control of test assets w on f within the tooolo Neglecting relatio onships and interoperabi issues be ility etween critic tools, such as requirem cal ments management too version c ols, control tools, incident management to ools, defect tr racking tools and s tools from multip vendors s pleo Risk of tool vend going out of business, retiring the tool, or sellin the tool to a different k dor t ng o venddoro Poor response fr r rom vendor f support, u for upgrades, an defect fixe nd eso Risk of suspension of open-s k source / free tool projecto Unfo oreseen, suc as the inab ch bility to support a new plaatform6.2.2 Special C Considera ations for Some Typ of Too (K1) pes olsTest Exeecution Too ols ecution tools execute test objects usin automated test scripts This type o tool oftenTest exe t ng d s. ofrequires significant e effort in order to achieve s r significant be enefits.Capturin tests by re ng ecording the actions of a manual teste seems attractive, but t er this approach does hnot scale to large numbers of aut e tomated test scripts. A caaptured scrip is a linear r pt representatio onwith specific data and actions as part of each script. This type of scrip may be uns d h pt stable whenunexpeccted events ooccur.Version 2 2011 Page 62 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 63. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board sA data-ddriven testing approach separates out the test inputs (the data usually int a spreadsheet, g t a), toand uses a more gen s neric test scr that can r ript read the inpu data and e ut same test script execute the swith diffe erent data. Testers who a not famili with the scripting lang are iar s guage can then create the test edata for these predef fined scripts. .There ar other techniques employed in data re a-driven techniques, wher instead of hard-coded data re fcombina ations placed in a spreads sheet, data is generated using algorit thms based o configura on ableparameters at run tim and supplied to the ap me pplication. Fo example, a tool may use an algorit or thm,which ge enerates a ra andom user I and for re ID, epeatability in pattern, a s n seed is emplloyed forcontrollin randomne ng ess.In a keywword-driven t testing appro oach, the spr readsheet co ontains keyw words describ bing the actio to onsbe taken (also called action word and test data. Testers (even if the are not fam n d ds), s ey miliar with th hescripting language) c then define tests usin the keywo can ng ords, which c be tailore to the can edapplication being tes sted.Technica expertise in the scriptin language is needed fo all approac al ng or ches (either by testers or by rspecialis in test aut sts tomation).Regardle of the sc ess cripting techn nique used, th expected results for e he each test nee to be store for ed edlater com mparison.Static A Analysis Too ols nalysis tools applied to soStatic an ource code c enforce coding standards, but if a can c applied to exi istingcode ma generate a large quant of messa ay tity ages. Warnin messages do not stop the code fro ng s om anslated into an executab program, but ideally should be addressed so tbeing tra ble s that maintena anceof the co is easier in the future A gradual implementati of the analysis tool w initial filte to ode e. ion with ersexclude some messa ages is an ef ffective appro oach.Test Maanagement T ToolsTest management to ools need to i interface with other tools or spreadsh h heets in order to produce usefulinformation in a format that fits th needs of the organizat he tion.Version 2 2011 Page 63 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 64. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s6.3 Introdu ucing a T Tool into an Org o ganizatio on 15 minut tes(K1)TermsNo specific terms.Backgr roundThe main considerat tions in selec cting a tool fo an organiz or zation include e:o Asse essment of o organizationa maturity, st al trengths and weaknesses and identif d fication of oppoortunities for an improved test proces supported by tools d sso Evaluation again clear requ nst uirements an objective criteria nd co A prooof-of-conce by using a test tool during the eva ept, aluation phas to establis whether it se sh t perfo orms effectivvely with the software und test and within the cu der urrent infrastr ructure or to identify changes needed to th infrastruc hat cture to effec ctively use th tool heo Evaluation of the vendor (inc e cluding trainin support and commerc aspects) or service support ng, a cial ) s supppliers in case of non-com e mmercial tools so Identification of internal requiirements for coaching an mentoring in the use o the tool nd ofo Evaluation of training needs considering the current test team’s te automatio skills est ono Estimmation of a ccost-benefit r ratio based o a concrete business ca on e aseIntroducing the seleccted tool into an organiza ation starts with a pilot pro w oject, which has the followwingobjectivees:o Lear more deta about the t rn ail toolo Evaluate how the tool fits with existing pr e rocesses and practices, a determin what would d and ne need to change do Deci on standard ways of using, mana ide aging, storing and maintaining the too and the tes g ol st asse (e.g., dec ets ciding on namming convent tions for files and tests, c s creating libraries and defining the m modularity of test suites) fo Asse whether the benefits will be achie ess eved at reaso onable costSuccess factors for the deployme of the too within an organization include: s ent ol oo Rolling out the to to the res of the orga ool st anization incr rementallyo Adap pting and improving proccesses to fit w the use of the tool witho Provviding training and coaching/mentorin for new us g ng serso Definning usage g guidelineso Implementing a w to gathe usage information from the actual u way er m useo Monitoring tool u and bene use efitso Provviding suppor for the test team for a g rt t given toolo Gathhering lesson learned fro all teams ns om sRefere ences6.2.2 Bu uwalda, 2001 Fewster, 1 1, 19996.3 Fewwster, 1999Version 2 2011 Page 64 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 65. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s7. Referen ncesStand dardsISTQB G Glossary of T Terms used in Software T Testing Versi 2.1 ion Chrissis, M.B Konrad, M and Shrum S. (2004) CMMI, Guidelines for Pro[CMMI] C B., M. m, ocess Integr rationand Prod duct Improveement, Addis Wesley: Reading, MA son ASee Secction 2.1[IEEE St 829-1998] IEEE Std 82 td 29™ (1998) IEEE Standa for Softw ard cumentation, ware Test DocSee Secctions 2.3, 2.4 4.1, 5.2, 5 5.5, 5.6 4, 5.3,[IEEE 10 028] IEEE St 1028™ (20 td 008) IEEE Standard for Software Rev S views and Au udits,See Secction 3.2[IEEE 12 2207] IEEE 1 12207/ISO/IE 12207-20 EC 008, Software life cycle processes, eSee Secction 2.1[ISO 912 ISO/IEC 9 26] 9126-1:2001 Software E 1, Product Quality, Engineering – Software PSee Secction 2.3Books s[Beizer, 1990] Beizer B. (1990) S r, Software Tes sting Techniq ques (2nd ed Nostrand Reinhold: dition), Van NBostonSee Sec ctions 1.2, 1.3 2.3, 4.2, 4 4.4, 4.6 3, 4.3,[Black, 2 2001] Black, R. (2001) Ma anaging the Testing Proccess (3rd edi ition), John W Wiley & Sons New s:YorkSee Sec ctions 1.1, 1.2 1.4, 1.5, 2 2.4, 5.1, 5.2, 5.3, 5.5, 5.6 2, 2.3, ,[Buwalda 2001] Buw a, tegrated Test Design and Automation Addison Wesley: walda, H. et a (2001) Int al. d n, WReading, MASee Sec ction 6.2[Copelan 2004] Co nd, opeland, L. (2 2004) A Prac ctitioner’s Gu uide to Softw ware Test Des sign, ArtechHouse: N Norwood, MA ASee Secctions 2.2, 2.3 4.2, 4.3, 4 4.6 3, 4.4,[Craig, 2 2002] Craig, R D. and J Rick Jaskiel, Stef P. (2002) Systematic Software Te fan ) esting, Artech hHouse: NNorwood, MA ASee Sec ctions 1.4.5, 2 2.1.3, 2.4, 4.1, 5.2.5, 5.3, 5.4[Fewster 1999] Fewster, M. and Graham, D. (1999) Softw r, ware Test Au utomation, A Addison Wesl ley:Reading, MASee Secctions 6.2, 6.3 3[Gilb, 1993]: Gilb, To and Graham, Dorothy (1993) Software Inspection, Addison Wesley: om y nReading, MASee Sec ctions 3.2.2, 3 3.2.4[Hetzel, 1988] Hetzel, W. (1988) Complete G Guide to Softw ware Testing QED: Welle g, esley, MASee Sec ctions 1.3, 1.4 1.5, 2.1, 2 2.3, 2.4, 4 5.1, 5.3 4, 2.2, 4.1,[Kaner, 2 2002] Kaner, C., Bach, J. and Petttico B. (2002 Lessons L , ord, 2) Learned in So oftware Testi ing,John Wil & Sons: N ley New YorkSee Secctions 1.1, 4.5 5.2 5,Version 2 2011 Page 65 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 66. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s[Myers 1979] Myers, Glenford J. (1979) The A of Softwa Testing, J Art are John Wiley & Sons: New York wSee Secctions 1.2, 1.3 2.2, 4.3 3,[van Vee enendaal, 20 004] van Vee enendaal, E. (ed.) (2004) The Testing Practitioner (Chapters 6, 8, g r 610), UTN Publishers: The Nether N rlandsSee Secctions 3.2, 3.3 3Version 2 2011 Page 66 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 67. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s8. Append A – S A dix Syllabus Backg groundHistory of this D ry Documen ntThis doc cument was p prepared bet tween 2004 a 2011 by a Working G and y Group compr rised of memmbersappointe by the Inte ed ernational Sooftware Testing Qualificat tions Board ( (ISTQB). It w initially wasreviewed by a select review pa d ted anel, and the by represe en entatives draawn from the internationaalsoftware testing com e mmunity. The rules used in the produc ction of this d document are shown in eAppendix C.This doc cument is the syllabus for the Internat e r tional Founda cate in Software Testing, the ation Certificfirst level internationa qualificatio approved by the ISTQ (www.istqb.org). al on QBObjectives of th Found he dation Ce ertificate Qualificat Q tiono To ggain recogniti for testing as an esse ion ential and pro ofessional sooftware engin neering speccializationo To pprovide a stanndard framew work for the developmen of testers c nt careerso To eenable profes ssionally quaalified testers to be recognized by employers, customers and peers, s p and to raise the pprofile of testerso To ppromote cons sistent and good testing p practices within all softwa engineer are ring discipline eso dentify testing topics that are relevant and of value to industry To id t t yo To eenable softwa suppliers to hire certified testers and thereby g are s a gain commercial advanta age over their compe r etitors by advvertising their tester recru uitment policy yo To pprovide an oppportunity for testers and those with an interest in testing to ac r a cquire an inter rnationally re ecognized qu ualification in the subjectObjectives of th International Q he Qualificatio (adapted from ISTQB onmeetin at Soll ng lentuna, N Novembe 2001) ero To b able to com be mpare testing skills acros different countries ss co To eenable testers to move ac cross country borders mo easily y oreo To eenable multin national projects to have a common u national/intern understandin of testing issues ngo To inncrease the nnumber of qu ualified teste worldwide ers eo To hhave more im mpact/value a an interna as ationally-base initiative than from any country-specific ed y appr roacho To ddevelop a com mmon international body of understanding and kn y nowledge ab bout testing throu the sylla ugh abus and termminology, and to increase the level of knowledge about testing for e f g all pa articipantso To ppromote testing as a profe ession in mo countries oreo To eenable testers to gain a reecognized qu ualification in their native language no To eenable sharin of knowled and reso ng dge ources acros countries sso To pprovide intern national recoognition of tessters and this qualification due to par s rticipation from many countriesEntry Requirem ments for this Qua r alificationThe entr criterion fo taking the ISTQB Foun ry or ndation Certif ficate in Softwware Testing examinatio is g onthat cand didates have an interest in software t e testing. Howe ever, it is stro ongly recommended that tcandidat also: teso Have at least a m e minimal backkground in either software developme or software testing, su as e ent uch six m months experience as a ssystem or us acceptanc tester or a a software developer ser ce as eVersion 2 2011 Page 67 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 68. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board so Take a course th has been accredited t ISTQB sta e hat to andards (by o of the IS one STQB-recogn nized Natio onal Boards) ).Backgground an History of the F nd y Foundatio Certific on cate in So oftwareTestin ngThe indeependent cer rtification of s software test ters began in the UK with the British C n h ComputerSocietys Information Systems Ex s n xamination BBoard (ISEB) when a Software Testin Board wa set ), ng asup in 199 (www.bcs 98 s.org.uk/iseb). In 2002, A ASQF in Germ many began to support a German tes sterqualification scheme (www.asqf.d This syll de). labus is base on the ISE and ASQ syllabi; it ed EB QFincludes reorganized updated an additional content, and the empha is directe at topics that d, nd l d asis edwill provide the most practical help to testers. t .An existi Foundation Certificate in Software Testing (e.g., from ISEB, ASQF or a ISTQB- ing e e anrecogniz National Board) awar zed rded before t this Internatio onal Certifica was relea ate ased, will bedeemed to be equiva alent to the In nternational Certificate. The Foundation Certificat does not expire T te eand does not need to be renewed The date i was awarded is shown on the Certificate. s o d. itWithin ea participa ach ating country local aspec are contro y, cts olled by a naational ISTQB B-recognized dSoftware Testing Boa Duties o National Boards are sp e ard. of pecified by th ISTQB, bu are implem he ut mentedwithin ea country. The duties o the country boards are expected to include accreditation of ach of y otraining p providers and the setting of exams. gVersion 2 2011 Page 68 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 69. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s9. A Append B – L dix Learnin Objec ng ctives/C Cognitiv Level of veKnow wledgeThe follo owing learnin objectives are defined as applying to this syllab ng bus. Each top in the syllabus picwill be ex xamined acccording to the learning ob e bjective for it. .Level 1: Remember (K1 1)The cand didate will re ecognize, rem member and recall a term or concept. m .Keyword Rememb retrieve, recall, recog ds: ber, gnize, knowExampleeCan reco ognize the deefinition of “fa ailure” as:o “Non n-delivery of service to an end user or any other stakeholder” or n so “Actu deviation of the comp ual n ponent or sysstem from its expected delivery, service or result” s ”Level 2: Under rstand (K2 2)The cand didate can seelect the rea asons or expl lanations for statements related to the topic, and can esummarize, compare classify, ca e, ategorize and give examples for the t d testing conce ept.Keyword Summar ds: rize, generaliize, abstract, classify, compare, map, contrast, ex , , xemplify, inte erpret,translate represent, infer, conclu e, ude, categorize, construct modelsExampleesCan exp plain the reas why tests should be d son s designed as early as pos ssible:o To find defects wwhen they are cheaper to remove e oo To find the most important deefects firstCan exp differences between integ plain the similarities and d gration and s system testinng:o Similarities: testing more than one compo n onent, and ca test non-f an functional asspectso Diffe erences: integration testin concentra ng ates on interf faces and int teractions, an system te nd esting conc centrates on whole-system aspects, s such as end--to-end proce essingLevel 3: Apply (K3)The cand didate can se elect the cor rrect applicat tion of a conc cept or techn nique and appply it to a giv vencontext.Keyword Impleme execute, use, follow a procedure, apply a proc ds: ent, cedureExample eo Can identify boundary values for valid and invalid par s rtitionso Can select test c cases from a given state transition diaagram in order to cover a transitions all sLevel 4: Analyz (K4) zeThe cand didate can se eparate infor rmation relat to a proce ted edure or tech hnique into it constituen parts ts ntfor better understand ding, and can distinguish between fac and infere n cts ences. Typic application is to calanalyze a document, software or project situa , r ation and proopose approp priate actions to solve a sproblem or task.Keyword Analyze, organize, fin coherenc integrate, outline, pars structure, attribute, ds: , nd ce, se, ,deconstr ruct, differentiate, discrim minate, distingguish, focus, select ,Version 2 2011 Page 69 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 70. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s eExampleo Anallyze product risks and propose preve entive and coorrective mitig gation activit tieso Desccribe which p portions of an incident report are factual and whic are inferre from results n ch edRefere ence(For the cognitive lev vels of learning objectives s)Anderso L. W. and Krathwohl, D. R. (eds) (2001) A Tax on, xonomy for Learning, Tea aching, andAssessin A Revisio of Blooms Taxonomy of Education Objective Allyn & Bacon ng: on s y nal es,Version 2 2011 Page 70 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 71. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s10. A Append C – R dix Rules A Applied to the ISTQBFound dation Sy yllabusThe rules listed here were used in the develo opment and review of this syllabus. (A “TAG” is sh r s A hownafter eac rule as a s ch shorthand ab bbreviation o the rule.) of10.1.1 General RulesSG1. The syllabus sh hould be undderstandable and absorb e bable by peop with zero to six month (or ple o hsmore) exxperience in testing. (6-MMONTH)SG2. The syllabus sh hould be pra actical rather than theoret tical. (PRACTTICAL)SG3. The syllabus sh hould be clea and unam ar mbiguous to it intended r ts readers. (CLE EAR)SG4. The syllabus sh hould be undderstandable to people fr e rom different countries, and easilytranslata able into diffe erent languagges. (TRANS SLATABLE)SG5. The syllabus sh hould use Ammerican English. (AMERICAN-ENGLISH)10.1.2 Current C ContentSC1. The syllabus sh hould include recent testi concepts and should reflect curre best pract e ing s ent ticesin softwa testing where this is g are generally agrreed. The syllabus is sub bject to review every three to w efive year (RECENT rs. T)SC2. The syllabus sh hould minimi time-relat issues, such as curre market co ize ted s ent onditions, toenable it to have a sh life of thr to five ye t helf ree ears. (SHELF F-LIFE).10.1.3 Learning Objective g esLO1. Lea arning objecttives should distinguish b between item to be reco ms ognized/reme embered (cognitivelevel K1) items the c ), candidate should underst tand concept tually (K2), it tems the canndidate should beable to p practice/use ( (K3), and items the candidate should be able to u to analyz a document, use zesoftware or project situation in co e ontext (K4). (KNOWLEDG GE-LEVEL)LO2. The description of the conte should be consistent with the lear e n ent e rning objectiv ves. (LO-CONSIS STENT)LO3. To illustrate the learning ob e bjectives, sam mple exam questions for each major s section shou be uldissued aalong with the syllabus. (L e LO-EXAM)10.1.4 Overall S StructureST1. The structure o the syllabus should be clear and allow cross-ref e of ferencing to and from oth herparts, fro exam que om estions and f from other re elevant documents. (CRO OSS-REF)ST2. Overlap betwee sections o the syllabu should be minimized. (OVERLAP) en of usST3. Eac section of the syllabus should hav the same structure. (STRUCTURE ch f s ve s E-CONSISTE ENT)ST4. The syllabus sh e hould contain version, da of issue and page num n ate a mber on ever page. ry(VERSIO ON)ST5. The syllabus sh e hould include a guideline for the amou of time to be spent in each sectio (to e unt o n on mportance of each topic). (TIME-SPENreflect th relative im he NT)Refere encesSR1. So ources and reeferences wil be given fo concepts in the syllabu to help training provide ll or n us ersfind out m more informaation about the topic. (REEFS)SR2. Wh here there ar not readily identified an clear sources, more d re y nd detail should be provided in thesyllabus. For exampl definitions are in the G le, s Glossary, so only the term are listed in the syllab ms bus.(NON-REF DETAIL)Version 2 2011 Page 71 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 72. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board sSource of Infor es rmationTerms used in the sy yllabus are defined in the ISTQB Glos e ssary of Term used in S ms Software Test ting. Aversion o the Glossa is availab from ISTQ of ary ble QB.A list of r recommende books on software tes ed sting is also issued in par rallel with this syllabus. The s Tmain boo list is part of the Refer ok t rences sectio on.Version 2 2011 Page 72 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 73. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s11. Appendi D – No A ix otice to T Training Provider rsEach ma subject h ajor heading in th syllabus is assigned an allocated ti he s n ime in minute The purp es. pose ofthis is bo to give gu oth uidance on th relative pr he roportion of time to be allocated to ea section of an t ach oaccredite course, and to give an approximat minimum time for the t ed n te t teaching of eeach section. .Training providers may spend mo time than is indicated and candidates may spend more tim ore n d meagain in reading and research. A course curriiculum does not have to follow the sa ame order as the ssyllabus.The syllaabus contains references to establish standards, which mus be used in the prepara s hed st n ationof trainin material. E ng Each standar used mus be the vers rd st sion quoted in the current version of this t andards not referenced in this syllabus may also besyllabus. Other publications, templates or sta r n bused and referenced but will not be examine d d, t ed.All K3 an K4 Learning Objective require a p nd es practical exe ercise to be in ncluded in th training hematerials s.Version 2 2011 Page 73 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 74. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s12. Appendi E – Re A ix elease No otesRelease 2010 1. CChanges to Learning Ob bjectives (LO) include som clarificatio me on a. W Wording cha anged for the following LO (content a level of L remains e Os and LO unchanged): LO-1.2.2, LO-1.3.1, LO- : -1.4.1, LO-1..5.1, LO-2.1.1, LO-2.1.3, LO- 2.4.2, LO-4.1 LO-4.2.1 LO-4.2.2, LO-4.3.1, LO 2 1.3, 1, O-4.3.2, LO-4 4.3.3, LO-4.4 4.1, LO-4.4.2, LO O-4.4.3, LO-4 4.6.1, LO-5.1 LO-5.2.2 LO-5.3.2, L 1.2, 2, LO-5.3.3, LO O- 5.5.2, LO-5.6 LO-6.1.1 LO-6.2.2, LO-6.3.2. 5 6.1, 1, b. LO-1.1.5 has been rewor s rded and upg graded to K2 Because a comparison of 2. n terms of defe related te t ect erms can be expected. c. LO-1.2.3 (K2 has been a 2) added. The content was already cov s vered in the 2007 2 syllabus. s d. LO-3.1.3 (K2 now comb 2) bines the con ntent of LO-3.1.3 and LO- -3.1.4. e. LO-3.1.4 has been removed from the 2010 syllab s e bus, as it is p partially redun ndant w LO-3.1.3. with f. LO-3.2.1 has been rewor s rded for cons sistency with the 2010 sy h yllabus conte ent. g. LO-3.3.2 has been modif s fied, and its level has bee changed from K1 to K2, for l en K consistency with LO-3.1.2. c h. LO 4.4.4 has been modif s fied for clarity and has been changed from a K3 to a y, d t K4. Reason LO-4.4.4 had already been written i a K4 mann n: b in ner. i. LO-6.1.2 (K1 was dropp from the 2010 syllabu and was r 1) ped us replaced with LO- h 6.1.3 (K2). T 6 There is no L LO-6.1.2 in th 2010 sylla he abus. 2. CConsistent u for test approach acc use cording to the definition in the glossary The term test e n y. t strategy will not be required as term t recall. s to 3. CChapter 1.4 now contains the concep of traceability between test basis and test cases. pt 4. CChapter 2.x now contains test objects and test ba s s asis. 5. RRe-testing is now the ma term in the glossary in s ain nstead of connfirmation tes sting. 6. T aspect d The data quality a testing h been add at severa locations in the syllabu and has ded al us: data quality a risk in C d and Chapter 2.2, 5 6.1.8. 5.5, 7. CChapter 5.2.3 Entry Crite are adde as a new subchapter. Reason: Consistency to Exit eria ed s Criteria (-> e C entry criteria added to LO O-5.2.9). 8. CConsistent u of the ter use rms test strat tegy and test approach w their definition in the t with glossary. g 9. CChapter 6.1 shortened be ecause the t tool descriptions were too large for a 45 minute le o esson. 10. IEEE Std 829:2008 has b been release This vers ed. sion of the syyllabus does not yet consider this new edit t tion. Section 5.2 refers to the docume Master Test Plan. The content of the o ent e Master Test Plan is cove M ered by the co oncept that the documen “Test Plan” covers diffe t nt ” erent levels of plan l nning: Test pplans for the test levels ca be create as well as a test plan on the an ed o project level covering mu p vels. Latter is named Master Test Pla in this syllabus ultiple test lev s an and a in the IS STQB Glossa ary. Code of Ethics has been moved from the CTAL to CTFL. 11. C m oRelease 2011Changes made with the “mainten s nance releas 2011 se” 1. G General: Wo orking Party rreplaced by W Working Gro oup 2. R Replaced po ost-conditions by postcon s nditions in ord to be con der nsistent with the ISTQB Glossary 2.1. G 3. F First occurre ence: ISTQB replaced by ISTQB® 4. Introduction to this Syllab bus: Descript tions of Cognnitive Levels of Knowledg removed, s ge because this was redund b s dant to Appendix B.Version 2 2011 Page 74 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 75. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s 5. SSection 1.6: Because the intent was not to define a Learning Objective for the “Code of e e r o Ethics”, the c E cognitive leve for the sec el ction has bee removed. en 6. SSection 2.2.1 2.2.2, 2.2.3 and 2.2.4, 3.2.3: Fixed formatting is 1, ssues in lists s. 7. SSection 2.2.2 The word f 2 failure was no correct for “…isolate fa ot r ailures to a s specific compponent …”. Therefor replaced w “defect” in that sente re with ence. 8. SSection 2.3: Corrected fo ormatting of bbullet list of test objective related to test terms in t es n section Test Types (K2). s 9. SSection 2.3.4 Updated d 4: description of debugging to be consistent with Ver f rsion 2.1 of the ISTQB Gloss sary. 10. S Section 2.4 r removed wor “extensive from “inclu rd e” udes extensiv regression testing”, ve n because the “extensive” depends on the change (size, risks, v b value, etc.) a written in the as t next sentenc n ce. Section 3.2: The word “in 11. S ncluding” has been remov to clarify the sentenc s ved y ce. 12. S Section 3.2.1 Because t activities of a formal review had b 1: the r been incorrec formatted the ctly d, review proce had 12 m r ess main activities instead of six, as intend s s ded. It has be changed back een d to t six, which makes this s section comp pliant with th Syllabus 2 he 2007 and the ISTQB Advanced e Level Syllabu 2007. L us 13. S Section 4: WWord “develop ped” replaced by “defined because test cases ge defined an not d” et nd developed. d 14. S Section 4.2: Text change to clarify ho black-box and white-b testing co e ow x box ould be used in d conjunction w experien c with nce-based te echniques. Section 4.3.5 text change “..between actors, inclu 15. S 5 e uding users a the syste and em..” to “ … between acto (users or systems), … “. b ors r 16. S Section 4.3.5 alternative path replace by alterna 5 ed ative scenario o. 17. S Section 4.4.2 In order to clarify the te branch testing in the text of Sect 2: o erm t e tion 4.4, a sentence to clarify the focus of branc testing has been chang s ch s ged. Section 4.5, Section 5.2.6: The term “experienced 18. S d-based” tes sting has bee replaced by the en b correct term “experience-based”. c Section 6.1: Heading “6.1.1 Understa 19. S anding the Meaning and Purpose of T M Tool Support for t Testing (K2)” replaced by “6.1.1 Tool Support for Testing (K2)”. T y l 20. S Section 7 / BBooks: The 3 edition of [Black,2001] listed, repla 3rd acing 2nd edittion. 21. A Appendix D: Chapters re equiring exerc cises have been replaced by the gen b neric requirem ment that all Learn t ning Objectiv K3 and h ves higher require exercises. This is a req e quirement specified in i the ISTQB Accreditatio Process ( B on (Version 1.26 6). 22. A Appendix E: The change learning objectives bet ed tween Versio 2007 and 2010 are no on ow correctly liste c ed.Version 2 2011 Page 75 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 76. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board s13. Indexaction word .............. ................................ 63 dyynamic testin ..................... 13, 31, 32, 36 ng 3alpha tes sting ............ .......................... 24, 27 emmergency ch hange ................................. 30architect ture .............. 15, 21, 22, 25, 28, 29 .. ennhancement .................................... 27, 30 2archiving .................. g .......................... 17, 30 en criteria .. ntry ........................................... 33automation ............... ................................ 29 eqquivalence p partitioning .......................... 40benefits of independe ence ....................... 47 er ............... rror ................... 1 11, 18, 43, 50 10, 4benefits of using tool ............................... 62 l er guessing ............................. 18, 43, 50 rror g 4beta test ting ........................................ 24, 27 exxhaustive tes sting ................................... 14black-bo technique . ox .................... 37, 39, 40 ex criteria13, 15, 16, 33, 35, 45, 48, 49, 50, xit , 4black-bo test design technique ............. 39 ox n 51black-bo testing ...... ox ................................ 28 exxpected resu ...................... 16, 38, 48, 63 ult 4bottom-u ................. up ................................ 25 exxperience-ba ased technique ....... 37, 39, 43 3boundar value analy ......................... 40 ry ysis exxperience-ba ased test des sign techniqu 39 ue ................................ 11bug ........................... exxploratory tes sting ............................. 43, 50 4captured script ......... d ................................ 62 fa actory accept tance testing ...................... 27 gchecklist ................. ts .......................... 34, 35 fa ailure10, 11, 13, 14, 18, 2 24, 26, 32 36, 21, 2,choosing test techniq .......................... 44 g que 43, 46, 50, 51, 53, 54, 6 69code cov verage ......... ........ 28, 29, 37, 42, 58 fa ailure rate ..... ..................................... 50, 51 5commerc off the sh (COTS) ............ 22 cial helf fa ............... ault ............................... 10, 11, 43compiler ................... r ................................ 36 fa attack ..... ault ........................................... 43complex ................ xity .............. 11, 36, 50, 59 fie testing .... eld ..................................... 24, 27 2compone integratio testing22, 25, 29, 59, ent on fo ollow-up ........ ............................... 33, 34, 35 3 60 fo ormal review . ..................................... 31, 33 3compone testing22 24, 25, 27, 29, 37, 41, ent 2, , fu unctional requ uirement ...................... 24, 262 42 fu unctional spe ecification ............................ 28configura ation management ......... 45, 48, 52 unctional task ......................................... 25 fu kConfigur ration manag gement tool ............. 58 unctional test .......................................... 28 fu tconfirma ation testing.. 13, 15, 16, 21, 28, 29 .. unctional test ..................................... 28 fu tingcontract acceptance testing .................... 27 fu unctionality ... ............. 24, 2 28, 50, 53, 62 25, 5control fl ............... low .............. 28, 36, 37, 42 im mpact analysis ........................... 21, 30, 38 3coverage 15, 24, 28, 29, 37, 38, 39, 40, 42, e incident ... 15, 16, 17, 19, 2 46, 48, 55 58, 24, 5, 50, 51 58, 60, 62 1, 59, 62coverage tool ........... e ................................ 58 incident loggin ....................................... 55 ngcustom-d developed so oftware.................... 27 incident mana agement.................. 48, 55, 58 5data flow .................. w ................................ 36 incident mana agement tool ................. 58, 59 5data-driv approach .............................. 63 ven h incident report ................................... 46, 55 t 4data-driv testing ... ven ................................ 62 independence ............................. 18, 47, 48 e 4debuggin ................ ng .............. 13, 24, 29, 58 informal review ............................ 31, 33, 34 w 3debuggin tool ......... ng .......................... 24, 58 inspection ...... ......................... 31, 33, 34, 35 3decision coverage .... .......................... 37, 42 inspection leader ..................................... 33decision table testing ........................ 40, 41 g integration13, 22, 24, 25, 2 29, 36, 40, 41, 27,decision testing ........ ................................ 42 42, 45, 48, 59, 60, 69defect10 11, 13, 14, 16, 18, 21, 24, 26, 28, 0, integration tes sting22, 24, 2 29, 36, 40 45, 25, 0, 29, 31 32, 33, 34, 35, 36, 37, 39, 40, 41, 1, 59, 60, 69 43, 44 45, 47, 49, 50, 51, 53, 54, 55, 59, 4, interoperability testing ............................. 28 y 60, 69 9 introducing a t tool into an o organization5 64 57,defect de ensity........... .......................... 50, 51 IS 9126 ....... SO ......................... 11, 29, 30, 65 3defect tra acking tool... ................................ 59 deevelopment m model................................. 22developm ment .. 8, 11, 12, 13, 14, 18, 21, 22, ite erative-increm mental development mod 22 del 24, 29 32, 33, 36, 38, 44, 47, 49, 50, 52, 9, keeyword-drive approach........................ 63 en 53, 55 59, 67 5, keeyword-drive testing ............................ 62 endevelopm ment model . .......................... 21, 22 ........................................... 33 kick-off ...........drawbac of indepe cks endence ................... 47 le earning objec ctive ... 8, 9, 10, 21, 31, 37 45, 7, ................................ 24driver ........................ 57, 69, 70, 71dynamic analysis too ....................... 58, 60 c ol lo testing .... oad ............................... 28, 58, 60 5Version 2 2011 Page 76 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 77. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board sload test ting tool........ ................................ 58 se ecurity testing ........................................ 28maintain nability testing ............................. 28 g se ecurity tool ........................................ 58, 60 5maintena ance testing ......................... 21, 30 simulators ................................................. 24management tool ..... .............. 48, 58, 59, 63 site acceptanc testing ........................... 27 cematurity .................... .............. 17, 33, 38, 64 so oftware deve elopment ............. 8, 11, 21, 22 2metric ........................................... 33, 35, 45 so oftware deve elopment model .................. 22mistake .................... .................... 10, 11, 16 sp pecial consid derations for some types of tool 62modelling tool........... ................................ 59 te case ........ est ........................................... 38moderator ................ .................... 33, 34, 35 sp pecification-b based technique..... 29, 39, 40 3monitorin tool ......... ng .......................... 48, 58 sp pecification-b based testing...................... 37 gnon-func ctional requir rement ......... 21, 24, 26 takeholders .. 12, 13, 16, 1 26, 39, 45, 54 st . 18, 4non-func ctional testing ....................... 11, 28 g st tate transition testing ....................... 40, 41 n 4objective for testing ............................... 13 es st tatement cov verage ................................ 42off-the-shelf .............. ................................ 22 tatement test ..................................... 42 st tingoperational acceptan testing ............... 27 nce tatic analysis .................................... 32, 36 st s 3operational test ........ .................... 13, 23, 30 st tatic analysis tool ........... 3 36, 58, 59, 63 s 31, 5patch ........................................................ 30 st tatic techniqu ................................. 31, 32 ue 3peer review .............. .................... 33, 34, 35 st tatic testing ....................................... 13, 32performa ance testing . .......................... 28, 58 st tress testing . ............................... 28, 58, 60 5performa ance testing tool ................... 58, 60 tress testing tool .............................. 58, 60 st 5pesticide paradox..... e ................................ 14 st tructural testi .................... 24, 28, 29, 42 ing 2portabilit testing ...... ty ................................ 28 st tructure-base technique ................ 39, 42 ed e 3probe eff .............. ffect ................................ 58 tructure-base test design technique .... 42 st edprocedur ................. re ................................ 16 tructure-base testing ..................... 37, 42 st ed 3product r .............. risk .............. 18, 45, 53, 54 st ............... tub ........................................... 24project risk ............... .................... 12, 45, 53 uccess factors ....................................... 35 suprototyping ............... ................................ 22 sy ystem integra ation testing ................. 22, 252quality 8 10, 11, 13, 19, 28, 37, 38, 47, 48, 8, sy ystem testing g13, 22, 24, 2 26, 27, 49, 69 25, 4 50, 53 55, 59 3, te echnical revie .................... 31, 33, 34, 35 ew 3rapid application dev velopment (R RAD) ..... 22 te analysis .. est ......................... 15, 38, 48, 49 4Rational Unified Proc cess (RUP) ............. 22 te approach ........................ 38, 48, 50, 51 est 5recorder ................... r ................................ 34 te basis ....... est ........................................... 15regressio testing .... 15, 16, 21, 28, 29, 30 on .. te case . 13, 14, 15, 16, 2 28, 32, 37 38, est 24, 7,Regulation acceptance testing ............... 27 39, 40, 41, 42, 45, 51, 5 59, 69 55,reliability ................... 11, 13, 28, 50, 53, 58 y .. te case spec est cification ................. 37, 38, 55 3reliability testing ....... y ................................ 28 te cases ...... est ........................................... 28requirem .............. ment ........ 13, 22, 24, 32, 34 te closure .... est ............................... 10, 15, 16requirem ments manag gement tool .............. 58 te condition . est ........................................... 38requirem ments specific cation ................ 26, 28 te conditions ........... 13, 1 16, 28, 38, 39 est s 15, 3responsi ibilities ............................. 24, 31, 33 te control..... est ............................... 15, 45, 51 4re-testing . 29, See co g onfirmation t testing, See  te coverage .................................... 15, 50 est confirm mation testing g te data ........ 15, 16, 38, 4 58, 60, 62, 63 est . 48, 6review13 19, 31, 32, 33, 34, 35, 36, 47, 48, 3, te data preparation tool .................. 58, 60 est 5 53, 55 58, 67, 71 5, te design13, 15, 22, 37, 38, 39, 43, 48, 58, est , 4review to ................ ool ................................ 58 62reviewer ................... r .......................... 33, 34 te design sp est pecification .......................... 45risk11, 12, 13, 14, 25 26, 29, 30, 38, 44, 45, 5, , te design tec est chnique .................. 37, 38, 39 3 49, 50 51, 53, 54 0, te design too .................................. 58, 59 est ol 5risk-base approach ............................... 54 ed Te Developm est ment Proces ..................... 38 ssrisk-base testing..... ed .................... 50, 53, 54 te effort ....... est ........................................... 50 .............. 11, 25, 49, 53risks ......................... te environme . 15, 16, 1 24, 26, 48, 51 est ent 17, 4risks of uusing tool ..... ................................ 62 te estimatio ....................................... 50 est onrobustne testing.... ess ................................ 24 te execution est n13, 15, 16, 3 36, 38, 43 45, 32, 3,roles ................ 8, 31, 33, 34, 35, 47, 48, 49 57, 58, 60root caus ................ se .......................... 10, 11 te execution schedule .......................... 38 est nscribe ................................................. 33, 34 te execution tool ..... 16, 3 57, 58, 60, 62 est n 38, 6scripting language.... .................... 60, 62, 63 te harness... est ................... 1 24, 52, 58, 60 16, 5security .................... 27, 28, 36, 47, 50, 58 .. te implemen est ntation ..................... 16, 38, 49 3Version 2 2011 Page 77 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board
  • 78. International Certif fied Teste er Software Te esting Founda ation Level Sy yllabus Q Qualifications Board stest lead ................ der .............. 18, 45, 47, 55 te esting and qu uality ................................... 11test lead tasks....... der ................................ 47 esting princip ............................... 10, 14 te plestest level. 21, 22, 24, 28, 29, 30, 37, 40, 42, te estware......... ................... 1 16, 17, 48, 52 15, 4 44, 45 48, 49 5, to support ... ool ................... 2 32, 42, 57, 62 24, 5 .............. 15, 16, 43, 60test log ..................... to support fo manageme of testing and ool or ent gtest man nagement ..... .......................... 45, 58 ........................................... 59 tests ..........test man nagement too ....................... 58, 63 ol to support fo performance and moni ool or itoring 60test man nager ............ ...................... 8, 47, 53 to support fo static testin ................... 59 ool or ngtest mon nitoring ......... .......................... 48, 51 to support fo test execution and logg ool or ging60test objeective ....... 13 22, 28, 43, 44, 48, 51 3, to support fo test specif ool or fication ............ 59test orac ................ cle ................................ 60 to support fo testing ...................... 57, 62 ool or 5test orgaanization ...... ................................ 47 to op-down ....... ........................................... 25test plan .. 15, 16, 32 45, 48, 49, 52, 53, 54 n 2, tra aceability ..... ............................... 38, 48, 52 4test plannning ............ 15, 16, 45, 49, 52, 54 .. tra ansaction pro ocessing seq quences ......... 25test plan nning activities ......................... 49 ypes of test to ................................ 57, 58 ty ool 5test proccedure .......... 15, 16, 37, 38, 45, 49 .. un test frame nit ework ...................... 24, 58, 605test proccedure specif fication .............. 37, 38 un test frame nit ework tool ..................... 58, 605test proggress monitoring ......................... 51 uppgrades ....... ........................................... 30test repo ................. ort .......................... 45, 51 ussability ......... ............. 11, 2 28, 45, 47, 53 27, 4test repoorting ............ .......................... 45, 51 ussability testin ................................. 28, 45 ng 2test scrip ................. pt .................... 16, 32, 38 us case test . se ..................................... 37, 40 3test strattegy ............. ................................ 47 us case testing .......................... 37, 40, 41 se 4test suite .................. e ................................ 29 us cases ...... se ......................... 22, 26, 28, 41 2test summmary report . ........ 15, 16, 45, 48, 51 us acceptan testing .......................... 27 ser ncetest tool classification .............................. 58 n vaalidation .................................................. 22test type ................... e ........ 21, 28, 30, 48, 75 veerification ................................................ 22test-drive developm en ment ......................... 24 veersion contro ......................................... 52 oltester 10 13, 18, 34, 41, 43, 45, 4 48, 52, 0, 47, V--model ......... ........................................... 22 62, 67 7 walkthrough ... ............................... 31, 33, 34 3tester tas .............. sks ................................ 48 white-box test design tech t hnique ....... 39, 42 3test-first approach .... ................................ 24 white-box test ............................... 28, 42 ting 2Version 2 2011 Page 78 of 78 31-Ma ar-2011© Internationa Software Testing Q al Qualifications Board

×