ISTQB CTFL 2024 Foundation Level PDF

Lucjan Stapp · Adam Roman Michaël Pilaeten ISTQB® Certified Tester Foundation Level A Self-Study Guide Syllabus v4.0 ISTQB® Certiﬁed Tester Foundation Level Lucjan Stapp Adam Roman Michaël Pilaeten ISTQB® Certiﬁed Tester Foundation Level A Self-Study Guide Syllabus v4.0 Lucjan Stapp Adam Roman Warszawa, Poland Jagiellonian University Kraków, Poland Michaël Pilaeten Londerzeel, Belgium ISBN 978-3-031-42766-4 ISBN 978-3-031-42767-1 (eBook) Translation from the Polish language edition: “Certyﬁkowany Tester ISTQB. Przygotowanie do egzaminu według sylabusa w wersji 4.0” by Lucjan Stapp et al., © Helion.pl sp. z o.o., Gliwice, Poland (https:// helion.pl/) - Polish rights only, all other rights with the authors 2023. Published by Helion.pl sp. z o.o., Gliwice, Poland (https://helion.pl/). All Rights Reserved. © The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature Switzerland AG 2024 This work is subject to copyright. All rights are solely and exclusively licensed by the Publisher, whether the whole or part of the material is concerned, speciﬁcally the rights of reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microﬁlms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a speciﬁc statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. The publisher, the authors, and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional afﬁliations. Cover Illustration: © trahko / Stock.adobe.com This Springer imprint is published by the registered company Springer Nature Switzerland AG The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland Paper in this product is recyclable. Preface Purpose of This Book This book is aimed at those preparing for the ISTQB® Certiﬁed Tester—Foundation Level exam based on the Foundation Level syllabus (version 4.0) published in 2023. Our goal was to provide candidates with reliable knowledge based on this document. We know from experience that one can ﬁnd a lot of information about ISTQB® syllabi and exams on the Internet, but much of it is unfortunately of poor quality. It even happens that materials found on the Web contain serious errors. In addition, due to the signiﬁcant changes that have taken place in the syllabus compared to the previous version (3.1.1) published in 2018, the amount of material available to candidates based on the new syllabus is still small. This book expands and details many issues that are described in the syllabus itself in a perfunctory or general way. According to the ISTQB® guidelines for syllabus- based training, an exercise must be provided for each learning objective at the K3 level and a practical example must be provided for each objective at the K2 or K3 level.1 In order to satisfy these requirements, we have prepared exercises and examples for all learning objectives at these levels. In addition, for each learning objective, we present one or more sample exam questions similar to those that the candidate will see on the exam. This makes the book an excellent aid for studying, preparing for the exam, and verifying acquired knowledge. Book Structure The book consists of four main parts. 1 More about the learning objectives and K levels is given below. v vi Preface Part I: Certiﬁcate, Syllabus, and Foundation Level Exam Part I provides ofﬁcial information on the content and structure of the syllabus and the ISTQB® Certiﬁed Tester—Foundation Level exam. It also discusses the ISTQB® certiﬁcation structure. This section also explains the basic technical concepts on which the syllabus and exam structure are based. We explain what the learning objectives and K levels are and what are the rules for building and administering the actual exam. It is worth familiarizing yourself with these issues, as understanding them will help you prepare much better for the exam. Part II: Discussion of the Content of the Syllabus Part II is the main part of the textbook. Here, we discuss in detail all the content and learning objectives of the Foundation Level syllabus. This part consists of six chapters, corresponding to the six chapters of the syllabus. Each learning objective at K2 or K3 level is illustrated with a practical example, and each learning objective at K3 level is illustrated with a practical exercise. At the beginning of each chapter, deﬁnitions of keywords applicable to the chapter are given. Each keyword, at the place of its ﬁrst relevant use in the text, is marked in bold and with a book icon. At the end of each chapter, the reader will ﬁnd sample exam questions covering all the learning objectives included in this chapter. The book contains 70 original sample exam questions covering all the learning objectives, as well as 14 practical exercises corresponding to the K3 level learning objectives. These questions and exercises are not part of the ofﬁcial ISTQB® materials but are constructed by the authors using the principles and rules that apply to their creation for the actual exams. Thus, they are additional material for the readers, allowing them to verify their knowledge after reading each chapter and better understand the material presented. Optional Material The text in the box denotes optional material. It relates to the content of the syllabus but goes beyond it and is not subject to examination. It is “for those, who are curious.” Sections with titles marked with an asterisk (*) are optional. They cover the material that was mandatory for the exam according to the old version of the syllabus. We decided to leave these chapters in the book because of their importance and practical application. The reader who uses the textbook only to study for the exam can skip these chapters while reading. These optional sections are: Preface vii Section 3.2.6—Review Techniques Section 4.2.5—Use Case Testing Part III: Answers to Questions and Exercises In Part III, we provide solutions to all sample exam questions and exercises appearing in Part II of the book. The solutions are not limited to just giving the correct answers but also include their justiﬁcations. They will help the reader to better understand how the real exam questions are created and to better prepare for solving them during the real exam. Part IV: Ofﬁcial Sample Exam and Additional Questions The last part, Part IV of the textbook, contains the ofﬁcial sample ISTQB® exam for the Foundation Level certiﬁcation, additional questions covering learning objectives not covered in the exam, and information about the correct answers and justiﬁcations for those answers. The book is therefore structured in such a way that all important and useful information is in one place: Exam structure and rules The content discussed in the syllabus with its comprehensive discussion and examples Deﬁnitions of terms, the knowledge of which is mandatory for the exam Original sample test questions and exercises, with correct answers and their justiﬁcation Sample ISTQB® exam with correct answers and their justiﬁcation We hope that the material presented in this publication will help all those interested in obtaining the ISTQB® Certiﬁed Tester—Foundation Level certiﬁca- tion. Warszawa, Poland Lucjan Stapp Kraków, Poland Adam Roman Londerzeel, Belgium Michaël Pilaeten Contents Part I Certiﬁcation, Syllabus, and Foundation Level Exam Foundation Level Certiﬁcate................................. 3 History of the Foundation Level Certiﬁcate........................ 3 Career Paths for Testers...................................... 4 Target Audience............................................ 5 Objectives of the International Qualiﬁcation System.................. 5 Foundation Level Syllabus................................... 7 Business Outcomes......................................... 7 Learning Objectives and K-Levels............................... 7 Requirements for Candidates................................... 9 References to Norms and Standards.............................. 9 Continuous Update.......................................... 10 Release Notes for Foundation Level Syllabus v4.0................... 10 Content of the Syllabus....................................... 11 Chapter 1. Fundamentals of Testing........................... 11 Chapter 2. Testing Throughout the Software Development Life Cycle... 12 Chapter 3. Static Testing................................... 13 Chapter 4. Test Analysis and Design........................... 13 Chapter 5. Managing the Test Activities........................ 14 Chapter 6. Test Tools...................................... 15 Foundation Level Exam..................................... 17 Structure of the Exam........................................ 17 Exam Rules............................................... 17 Distribution of Questions..................................... 18 Tips: Before and During the Exam.............................. 20 ix x Contents Part II The Syllabus Content Chapter 1 Fundamentals of Testing............................ 25 1.1 What Is Testing?......................................... 27 1.1.1 Test Objectives...................................... 28 1.1.2 Testing and Debugging................................ 29 1.2 Why Is Testing Necessary?................................. 31 1.2.1 Testing’s Contribution to Success......................... 34 1.2.2 Testing and Quality Assurance (QA)....................... 35 1.2.3 Errors, Defects, Failures, and Root Causes.................. 36 1.3 Testing Principles........................................ 41 1.4 Test Activities, Testware, and Test Roles....................... 47 1.4.1 Test Activities and Tasks............................... 47 1.4.2 Test Process in Context................................ 53 1.4.3 Testware........................................... 54 1.4.4 Traceability Between the Test Basis and Testware............. 60 1.4.5 Roles in Testing..................................... 61 1.5 Essential Skills and Good Practices in Testing................... 64 1.5.1 Generic Skills Required for Testing....................... 64 1.5.2 Whole Team Approach................................ 66 1.5.3 Independence of Testing............................... 67 Sample Questions........................................... 69 Chapter 2 Testing Throughout the Software Development Life Cycle.. 75 2.1 Testing in the Context of a Software Development Cycle........... 76 2.1.1 Impact of the Software Development Life Cycle on Testing...... 77 2.1.2 Software Development Life Cycle and Good Testing Practices.... 87 2.1.3 Testing as a Driver for Software Development................ 87 2.1.4 DevOps and Testing.................................. 92 2.1.5 Shift-Left Approach................................... 96 2.1.6 Retrospectives and Process Improvement................... 97 2.2 Test Levels and Test Types................................. 99 2.2.1 Test Levels......................................... 99 2.2.2 Test Types......................................... 115 2.2.3 Conﬁrmation Testing and Regression Testing................ 124 2.3 Maintenance Testing...................................... 127 Sample Questions........................................... 130 Chapter 3 Static Testing..................................... 133 3.1 Static Testing Basics...................................... 134 3.1.1 Work Products Examinable by Static Testing................ 135 3.1.2 Value of Static Testing................................. 136 3.1.3 Differences Between Static Testing and Dynamic Testing........ 140 3.2 Feedback and Review Process............................... 143 3.2.1 Beneﬁts of Early and Frequent Stakeholder Feedback.......... 143 3.2.2 Review Process Activities.............................. 144 Contents xi 3.2.3 Roles and Responsibilities in Reviews..................... 150 3.2.4 Review Types....................................... 151 3.2.5 Success Factors for Reviews............................. 160 3.2.6 (*) Review Techniques................................ 162 Sample Questions........................................... 165 Chapter 4 Test Analysis and Design............................ 169 4.1 Test Techniques Overview................................. 171 4.2 Black-Box Test Techniques................................. 176 4.2.1 Equivalence Partitioning (EP)............................ 177 4.2.2 Boundary Value Analysis (BVA)......................... 187 4.2.3 Decision Table Testing................................ 194 4.2.4 State Transition Testing................................ 199 4.2.5 (*) Use Case Testing.................................. 208 4.3 White-Box Test Techniques................................ 211 4.3.1 Statement Testing and Statement Coverage.................. 212 4.3.2 Branch Testing and Branch Coverage...................... 214 4.3.3 The Value of White-Box Testing......................... 217 4.4 Experience-Based Test Techniques........................... 219 4.4.1 Error Guessing...................................... 220 4.4.2 Exploratory Testing................................... 223 4.4.3 Checklist-Based Testing................................ 226 4.5 Collaboration-Based Test Approaches......................... 229 4.5.1 Collaborative User Story Writing......................... 229 4.5.2 Acceptance Criteria................................... 232 4.5.3 Acceptance Test-Driven Development (ATDD)............... 234 Sample Questions........................................... 237 Exercises................................................. 245 Chapter 5 Managing the Test Activities......................... 251 5.1 Test Planning........................................... 252 5.1.1 Purpose and Content of a Test Plan........................ 253 5.1.2 Tester’s Contribution to Iteration and Release Planning......... 257 5.1.3 Entry Criteria and Exit Criteria........................... 258 5.1.4 Estimation Techniques................................. 259 5.1.5 Test Case Prioritization................................ 268 5.1.6 Test Pyramid........................................ 275 5.1.7 Testing Quadrants.................................... 276 5.2 Risk Management........................................ 277 5.2.1 Risk Deﬁnition and Risk Attributes........................ 279 5.2.2 Project Risks and Product Risks.......................... 279 5.2.3 Product Risk Analysis................................. 281 5.2.4 Product Risk Control.................................. 284 5.3 Test Monitoring, Test Control, and Test Completion............... 286 xii Contents 5.3.1 Metrics Used in Testing................................ 287 5.3.2 Purpose, Content, and Audience for Test Reports.............. 288 5.3.3 Communicating the Status of Testing...................... 291 5.4 Conﬁguration Management................................. 292 5.5 Defect Management...................................... 294 Sample Questions........................................... 296 Exercises for Chapter 5....................................... 302 Chapter 6 Test Tools....................................... 307 6.1 Tool Support for Testing................................... 307 6.2 Beneﬁts and Risks of Test Automation......................... 309 Sample Questions........................................... 310 Part III Answers to Questions and Exercises Answers to Sample Questions................................. 313 Answers to Questions from Chap. 1.............................. 313 Answers to Questions from Chap. 2.............................. 317 Answers to Questions from Chap. 3.............................. 321 Answers to Questions from Chap. 4.............................. 323 Answers to Questions from Chap. 5.............................. 332 Answers to Questions from Chap. 6.............................. 337 Solutions to Exercises....................................... 339 Solutions to Exercises from Chap. 4............................. 339 Solutions to Exercises from Chap. 5............................. 349 Part IV Ofﬁcial Sample Exam Exam Set A.............................................. 355 Additional Sample Questions................................. 369 Exam Set A: Answers....................................... 379 Additional Sample Questions—Answers......................... 391 References............................................... 399 Index................................................... 403 About the Authors2 Lucjan Stapp, PhD, is a retired researcher and teacher of the Warsaw University of Technology, where for many years he gave lectures and seminars on software testing and quality assurance. He is the author of more than 40 publications, including 12 on various problems related to testing and quality assurance. As a tester, on his career path, he moved from junior tester to test team leader in more than a dozen projects. He has played the role of co-organizer and speaker at many testing conferences (including TestWarez—the biggest testing conference in Poland). Stapp is the founding member of the Information Systems Quality Association (www.sjsi.org), currently its vice president. He is also a certiﬁed tester (including ISTQB® CTAL- TM, CTAL-TA, Agile Tester, Acceptance Tester). Adam Roman, PhD, DSc, is a professor of computer science and research and teaching fellow at the Institute of Computer Science and Computer Mathematics at Jagiellonian University, where he has been giving lectures and seminars on software testing and quality assurance for many years. He heads the Software Engineering Department and is the co-founder of the “Software Testing” postgraduate program at Jagiellonian University. His research interests include research on software mea- surement, defect prediction models, and effective test design techniques. As part of the Polish Committee for Standardization, he collaborated on the international ISO/IEEE 29119 Software Testing Standard. Roman is the author of monographs Testing and Software Quality: Models, Techniques, Tools, Thinking-Driven Testing, and A Study Guide to the ISTQB® Foundation Level 2018 Syllabus: Test Techniques and Sample Mock Exams as well as many scientiﬁc and popular publications in the ﬁeld of software testing. He has played the role of speaker at many Polish and 2 All three authors are experts in software testing. They are co-authors of the Foundation Level syllabus version 4.0, as well as other ISTQB® syllabi. They also have practical experience in writing exam questions. xiii xiv About the Authors international testing conferences (including EuroSTAR, TestWell, TestingCup, and TestWarez). He holds several certiﬁcations, including ASQ Certiﬁed Software Quality Engineer, ISTQB® Full Advanced Level, and ISTQB® Expert Level— Improving the Test Process. Roman is a member of the Information Systems Quality Association (www.sjsi.org). Michaël Pilaeten. Breaking the system, helping to rebuild it, and providing advice and guidance on how to avoid problems. That’s Michaël in a nutshell. With almost 20 years of experience in test consultancy in a variety of environments, he has seen the best (and worst) in software development. In his current role as Learning and Development Manager, he is responsible for guiding his consultants, partners, and customers on their personal and professional path toward quality and excellence. He is the chair of the ISTQB Agile workgroup and Product Owner of the ISTQB® CTFL 4.0 syllabus. Furthermore, he is a member of the BNTQB (Belgium and Netherlands Testing Qualiﬁcations Board), an accredited training for most ISTQB® and IREB trainings, and an international keynote speaker and workshop facilitator. List of Abbreviations AC Acceptance criteria API Application Programming Interface ASQF Der Arbeitskreis für Software-Qualität und Fortbildung ATDD Acceptance test-driven development BDD Behavior-driven development BPMN Business Process Model and Notation BVA Boundary value analysis CC Cyclomatic complexity CD Continuous delivery CFG Control ﬂow graph CI Continuous integration CMMI Capability Maturity Model Integration COTS Commercial off-the-shelf CPU Central processing unit CRM Customer relationship management DDD Domain-driven design DDoS Distributed Denial-of-Service DevOps Development and operations DoD Deﬁnition of Done DoR Deﬁnition of Ready DTAP Development, testing, acceptance, and production EP Equivalence partitioning FDD Feature-driven development FMEA Failure mode and effect analysis GUI Graphical user interface IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers IaC Infrastructure as Code INVEST Independent, Negotiable, Valuable, Estimable, Small, and Testable IoT Internet of Things xv xvi List of Abbreviations IREB International Requirements Engineering Board ISEB Information Systems Examination Board ISO International Organization for Standardization ISTQB International Software Testing Qualiﬁcations Board KPI Key performance indicator LO Learning objective LOC Lines of code MBT Model-based testing MC/DC Modiﬁed condition/decision coverage MCR Modern Code Review MTTF Mean time to failure MTTR Mean time to repair N/A Not applicable PERT Program Evaluation and Review Technique OAT Operational acceptance testing QA Quality assurance QC Quality control QM Quality management Req Requirement SDLC Software development lifecycle SMART Speciﬁc, Measurable, Attainable, Realistic, and Time-Bound SQL Structured query language TC Test case TDD Test-driven development TMap Test Management Approach UAT User acceptance testing UI User interface UML Uniﬁed Modeling Language UP Uniﬁed Process US User story WBS Work breakdown structure WIP Work in process (or work in progress) XP eXtreme Programming XSS Cross-site scripting Part I Certiﬁcation, Syllabus, and Foundation Level Exam Foundation Level Certiﬁcate History of the Foundation Level Certiﬁcate Independent certiﬁcation of software testers began in 1998 in the United Kingdom. At that time, under the auspices of the British Computer Society’s Information Systems Examination Board (ISEB), a special unit for software testing was established—the Software Testing Board (www.bcs.org.uk/iseb). In 2002, the Ger- man ASQF (www.asqf.de) also created its own qualiﬁcation system for testers. The Foundation Level syllabus was created on the basis of the ISEB and ASQF syllabi, with the information contained in it reorganized, updated, and supplemented. The main focus has been on topics that provide the greatest practical support for testers. Foundation Level syllabus was created in order to: Emphasize testing as one of the core professional specialties within software engineering Create a standard framework for professional development of testers Establish a system to enable recognition of testers’ professional qualiﬁcations by employers, customers, and other testers and raise the status of testers Promote consistent good testing practices across all software engineering disciplines Identify testing issues that are relevant and valuable to the IT industry as a whole Create opportunities for software vendors to hire certiﬁed testers and gain a commercial advantage over their competitors by advertising their adopted tester recruitment policy Provide an opportunity for testers and those interested in testing to gain an internationally recognized qualiﬁcation in the ﬁeld Existing basic certiﬁcations in the ﬁeld of software testing (e.g., certiﬁcations issued by ISEB, ASQF, or ISTQB® national councils) that were awarded prior to the inception of the international certiﬁcate are considered equivalent to this certiﬁcate. © The Author(s), under exclusive license to Springer Nature Switzerland AG 2024 3 L. Stapp et al., ISTQB® Certiﬁed Tester Foundation Level 4 Foundation Level Certiﬁcate The basic certiﬁcate does not expire and does not need to be renewed. The date of certiﬁcation is placed on the certiﬁcate. Local conditions in each participating country are the responsibility of ISTQB®’s national councils (or “Member Boards”). The responsibilities of national councils are deﬁned by ISTQB®, while the implementation of these responsibilities is left to individual member organizations. The responsibilities of national councils typically include accreditation of training providers and scheduling of exams. Career Paths for Testers The system created by ISTQB® allows deﬁning career paths for testing professionals based on a three-level certiﬁcation program that includes Foundation Level, Advanced Level, and Expert Level. The entry point is the Foundation Level described in this book. Holding the Foundation Level certiﬁcation is a prerequisite for earning subsequent certiﬁcations. The holders of a Foundation Level certiﬁcate can expand their knowledge of testing by obtaining an Advanced Level qualiﬁca- tion. At this level, ISTQB® offers a number of educational programs. In terms of the basic path, there are three possible programs: Technical Test Analyst (technology oriented, non-functional testing, static anal- ysis, white-box test techniques, working with source code) Test Analyst (customer oriented, business understanding, functional testing, black-box test techniques, and experience-based testing) Test Manager (test process and test team management oriented) The advanced level is the starting point for acquiring further knowledge and skills at the expert level. A person who has already gained experience as a test manager, for example, can choose to further develop their career as a tester by obtaining expert- level certiﬁcations in the areas of test management and test process improvement. In addition to the core track, ISTQB® also offers specialized education programs on topics such as acceptance testing, artiﬁcial intelligence testing, automotive testing, gaming machine testing, game testing, mobile application testing, model- based testing, performance testing, security testing, test automation, or usability testing. In terms of agile methodologies, it is Technical Agile Tester or Agile Test Leadership at Scale. Figure 1 shows the certiﬁcation scheme offered by ISTQB® as of June 25, 2023. The latest version of the ISTQB® career path review is available at www.istqb.org. Objectives of the International Qualiﬁcation System 5 AGILE CORE SPECIALIST EXPERT LEVEL Test Management Acceptance Testing Managing The Test Team AI Testing Operational Test Management Automotive Software Tester Strategic Test Management Gambling Industry Tester ADVANCED LEVEL Improving The Test Process Game Testing Agile Technical Tester Assessing Test Processes Mobile Application Testing Agile Test Leadership At Scale MVP Implementing Test Process Improvement Model-Based Tester FOUNDATION LEVEL Performance Testing ADVANCED LEVEL Agile Tester Test Manager Security Tester Test Analyst Test Automation Engineer Technical Test Analyst Usability Testing FOUNDATION LEVEL Certified Tester START HERE Fig. 1 Ofﬁcial ISTQB® certiﬁcation scheme (source: www.istqb.org) Target Audience The Foundation Level qualiﬁcation is designed for anyone interested in software testing. This may include testers, test analysts, test engineers, test consultants, test managers, users performing acceptance testing, agile team members, and developers. In addition, the Foundation Level qualiﬁcation is suitable for those looking to gain basic knowledge in software testing, such as project managers, quality managers, software development managers, business analysts, CIOs, and management consultants. Objectives of the International Qualiﬁcation System Laying the groundwork for comparing testing knowledge in different countries Making it easier for testers to ﬁnd work in other countries Ensuring a common understanding of testing issues in international projects Increasing the number of qualiﬁed testers worldwide Creating an international initiative that will provide greater beneﬁts and a stronger impact than initiatives implemented at the national level Developing a common international body of information and knowledge about testing on the basis of syllabuses and a glossary of testing terms and raising the level of knowledge about testing among IT workers 6 Foundation Level Certiﬁcate Promoting the testing profession in more countries Enabling testers to obtain widely recognized qualiﬁcations in their native language Creating conditions for testers from different countries to share knowledge and resources Ensuring international recognition of the status of testers and this qualiﬁcation Foundation Level Syllabus Business Outcomes Associated with each ISTQB® syllabus is a set of so-called business outcomes (business goals). A business outcome is a concise, deﬁned, and observable result or change in business performance, supported by a speciﬁc measure. Table 1 lists 14 business outcomes to which a candidate receiving Foundation Level certiﬁcation should contribute. Learning Objectives and K-Levels The content of each syllabus is created to cover the set of learning objectives established for that syllabus. The learning objectives support the achievement of business goals and are used to create exams for Foundation Level certiﬁcate. Understanding what the learning objectives are and knowing the relation between learning objectives and exam questions are key to effective preparation for the certiﬁcation exam. All learning objectives are deﬁned in the syllabus in such a way that each of them constitutes an indivisible whole. Learning objectives are deﬁned at the beginning of each section of the syllabus. Each section of the syllabus deals with exactly one learning objective. This makes it possible to unambiguously link each learning objective (and exam questions) to well-deﬁned portions of the material. The section below outlines the learning objectives applicable to the Foundation Level syllabus. Knowledge of each topic covered in the syllabus will be tested on the exam according to the assigned learning objective. Each learning objective is assigned a so-called knowledge level, also known as the cognitive level (or K level), K1, K2, or K3, which determines the degree to which a particular piece of material should be assimilated. The knowledge levels for each learning objective are © The Author(s), under exclusive license to Springer Nature Switzerland AG 2024 7 L. Stapp et al., ISTQB® Certiﬁed Tester Foundation Level 8 Foundation Level Syllabus Table 1 Business outcomes pursued by a certiﬁed Foundation Level tester FL-BO1 Understand what testing is and why it is beneﬁcial FL-BO2 Understand fundamental concepts of software testing FL-BO3 Identify the test approach and activities to be implemented depending on the context of testing FL-BO4 Assess and improve the quality of documentation FL-BO5 Increase the effectiveness and efﬁciency of testing FL-BO6 Align the test process with the software development life cycle FL-BO7 Understand test management principles FL-BO8 Write and communicate clear and understandable defect reports FL-BO9 Understand the factors that inﬂuence the priorities and efforts related to testing FL-BO10 Work as part of a cross-functional team FL-BO11 Know risks and beneﬁts related to test automation FL-BO12 Identify essential skills required for testing FL-BO13 Understand the impact of risk on testing FL-BO14 Effectively report on test progress and quality presented next to each learning objective listed at the beginning of each chapter of the syllabus. Level 1: Remember (K1)—the candidate remembers, recognizes, or recalls a term or concept. Action verbs: Identify, recall, remember, recognize Examples: “Identify typical test objectives.” “Recall the concepts of the test pyramid.” “Recognize how a tester adds value to iteration and release planning.” Level 2: Understand (K2)—the candidate can select the reasons or explanations for statements related to the topic and can summarize, compare, classify, and give examples for the testing concept. Action verbs: Classify, compare, contrast, differentiate, distinguish, exemplify, explain, give examples, interpret, summarize Examples: “Classify the different options for writing acceptance criteria.” “Compare the different roles in testing” (look for similarities, differences, or both). “Distinguish between project risks and product risks” (allows concepts to be differentiated). “Exemplify the purpose and content of a test plan.” “Explain the impact of context on the test process.” “Summarize the activities of the review process.” References to Norms and Standards 9 Level 3: Apply (K3)—the candidate can carry out a procedure when confronted with a familiar task or select the correct procedure and apply it to a given context. Action verbs: Apply, implement, prepare, use Examples: “Apply test case prioritization.” “Prepare a defect report.” “Use boundary value analysis to derive test cases.” References for the cognitive levels of learning objectives: Anderson, L. W. and Krathwohl, D. R. (eds) (2001) A Taxonomy for Learning, Teaching, and Assessing: A Revision of Bloom’s Taxonomy of Educational Objec- tives, Allyn & Bacon Requirements for Candidates Candidates taking the ISTQB® Certiﬁed Tester Foundation Level exam are only required to have an interest in software testing. However, it is strongly recommended that candidates: Had at least basic experience in software development or testing, such as 6 months’ experience as a tester performing system testing or acceptance testing or as a developer Have completed an ISTQB® training course (accredited by one of the ISTQB® national councils in accordance with the ISTQB® standards) These are not formal requirements, although fulﬁlling them makes it signiﬁcantly easier to prepare for and pass the certiﬁcation exam. Anyone can take the exam, regardless of interest or experience as a tester. References to Norms and Standards The syllabus contains references to IEEE, ISO, etc. standards and norms. The purpose of these references is to provide a conceptual framework or to refer the reader to a source they can use for additional information. It should be noted, however, that only those provisions of the referenced norms or standards to which the speciﬁcally discussed sections of the syllabus refer may be the subject of the exam. The content of norms and standards is not the subject of the exam, and references to these documents are for informational purposes only. 10 Foundation Level Syllabus The current version of the syllabus (v4.0) refers to the following standards: ISO/IEC/IEEE 29119—Software Testing Standard. This standard consists of several parts, the most important of which from the point of view of the syllabus are Part 1 (general concepts) , Part 2 (testing processes) , Part 3 (test documentation) , and Part 4 (test techniques). Part 3 of this standard replaces the withdrawn IEEE 829 standard. ISO/IEC 25010—System and Software Quality Requirements and Evaluation (aka SQuaRE), System and software quality models. This standard describes the software quality model and replaces the withdrawn ISO 9126 standard. ISO/IEC 20246—Work Product Reviews. This standard describes issues related to work product reviews. It replaces the withdrawn IEEE 1028 standard. ISO 31000—Risk Management, Principles and Guidelines. This standard describes the risk management process. Continuous Update The IT industry is undergoing dynamic changes. In order to take into account the changing situation and ensure that stakeholders have access to useful, up-to-date information, ISTQB®’s working groups have created a list of links to supporting documents and changes in standards, which is available at www.istqb.org. The above information is not subject to the Foundation Level syllabus exam. Release Notes for Foundation Level Syllabus v4.0 The Foundation Level v4.0 syllabus includes best practices and techniques that have stood the test of time, but a number of signiﬁcant changes have been made from the previous version (v3.1) in 2018 to present the material in a more modern way, make it more relevant to the Foundation Level, and take into account changes that have occurred in software engineering in recent years. In particular: Greater emphasis on methods and practices used in agile software development models (whole-team approach, shift-left approach, iteration planning and release planning, test pyramid, testing quadrants, “test ﬁrst” practices like TDD, BDD, or ATDD). The section on testing skills, particularly soft skills, has been expanded and deepened. The risk management section has been reorganized and better structured. A section discussing the DevOps approach has been added. A section discussing in detail some test estimation techniques has been added. The decision testing technique was replaced by branch testing. A section describing detailed review techniques has been removed. Content of the Syllabus 11 The use case-based testing technique has been removed (it is discussed in the Advanced Level syllabus “Test Analyst”). A section discussing sample test strategies has been removed. Some tools-related content has been removed, in particular the issue of introduc- ing a tool to an organization or conducting a pilot project. Content of the Syllabus Chapter 1. Fundamentals of Testing The reader learns the basic principles related to testing, the reasons why testing is required, and what the test objectives are. The reader understands the test process, the major test activities, and testware. The reader understands the essential skills for testing. Learning Objectives 1.1. What is testing? FL-1.1.1 (K1) Identify typical test objectives. FL-1.1.2 (K2) Differentiate testing from debugging. 1.2. Why is testing necessary? FL-1.2.1 (K2) Exemplify why testing is necessary. FL-1.2.2 (K1) Recall the relation between testing and quality assurance. FL-1.2.3 (K2) Distinguish between root cause, error, defect, and failure. 1.3. Testing principles FL-1.3.1 (K2) Explain the seven testing principles. 1.4. Test activities, testware, and test roles FL-1.4.1 (K2) Summarize the different test activities and tasks. FL-1.4.2 (K2) Explain the impact of context on the test process. FL-1.4.3 (K2) Differentiate the testware that supports the test activities. FL-1.4.4 (K2) Explain the value of maintaining traceability. FL-1.4.5 (K2) Compare the different roles in testing. 1.5. Essential skills and good practices in testing FL-1.5.1 (K2) Give examples of the generic skills required for testing. FL-1.5.2 (K1) Recall the advantages of the whole team approach. FL-1.5.3 (K2) Distinguish the beneﬁts and drawbacks of independence of testing. 12 Foundation Level Syllabus Chapter 2. Testing Throughout the Software Development Life Cycle The reader learns how testing is incorporated into different development approaches. The reader learns the concepts of test-ﬁrst approaches, as well as DevOps. The reader learns about the different test levels, test types, and maintenance testing. Learning Objectives 2.1. Testing in the context of a software development life cycle FL-2.1.1 (K2) Explain the impact of the chosen software development life cycle on testing. FL-2.1.2 (K1) Recall good testing practices that apply to all software development life cycles. FL-2.1.3 (K1) Recall the examples of test-ﬁrst approaches to development. FL-2.1.4 (K2) Summarize how DevOps might have an impact on testing. FL-2.1.5 (K2) Explain the shift-left approach. FL-2.1.6 (K2) Explain how retrospectives can be used as a mechanism for process improvement. 2.2 Test levels and test types FL-2.2.1 (K2) Distinguish the different test levels. FL-2.2.2 (K2) Distinguish the different test types. FL-2.2.3 (K2) Distinguish conﬁrmation testing from regression testing. 2.3 Maintenance testing FL-2.3.1 (K2) Summarize maintenance testing and its triggers. Content of the Syllabus 13 Chapter 3. Static Testing The reader learns about the static testing basics, the feedback, and review process. Learning Objectives 3.1. Static testing basics FL-3.1.1 (K1) Recognize types of products that can be examined by the different static test techniques. FL-3.1.2 (K2) Explain the value of static testing. FL-3.1.3 (K2) Compare and contrast static and dynamic testing. 3.2. Feedback and review process FL-3.2.1 (K1) Identify the beneﬁts of early and frequent stakeholder feedback. FL-3.2.2 (K2) Summarize the activities of the review process. FL-3.2.3 (K1) Recall which responsibilities are assigned to the principal roles when performing reviews. FL-3.2.4 (K2) Compare and contrast the different review types. FL-3.2.5 (K1) Recall the factors that contribute to a successful review. Chapter 4. Test Analysis and Design The reader learns how to apply black-box, white-box, and experience-based test techniques to derive test cases from various software work products. The reader learns about the collaboration-based test approach. Learning Objectives 4.1. Test techniques overview FL-4.1.1 (K2) Distinguish black-box, white-box, and experience-based test techniques. 4.2. Black-box test techniques FL-4.2.1 (K3) Use equivalence partitioning to derive test cases. FL-4.2.2 (K3) Use boundary value analysis to derive test cases. FL-4.2.3 (K3) Use decision table testing to derive test cases. FL-4.2.4 (K3) Use state transition testing to derive test cases. 14 Foundation Level Syllabus 4.3. White-box test techniques FL-4.3.1 (K2) Explain statement testing. FL-4.3.2 (K2) Explain branch testing. FL-4.3.3 (K2) Explain the value of white-box testing. 4.4. Experience-based test techniques FL-4.4.1 (K2) Explain error guessing. FL-4.4.2 (K2) Explain exploratory testing. FL-4.4.3 (K2) Explain checklist-based testing. 4.5. Collaboration-based test approaches FL-4.5.1 (K2) Explain how to write user stories in collaboration with developers and business representatives. FL-4.5.2 (K2) Classify the different options for writing acceptance criteria. FL-4.5.3 (K3) Use acceptance test-driven development (ATDD) to derive test cases. Chapter 5. Managing the Test Activities The reader learns how to plan tests in general and how to estimate test effort. The reader learns how risks can inﬂuence the scope of testing. The reader learns how to monitor and control test activities. The reader learns how conﬁguration management supports testing. The reader learns how to report defects in a clear and understandable way. Learning Objectives 5.1 Test planning FL-5.1.1 (K2) Exemplify the purpose and content of a test plan. FL-5.1.2 (K1) Recognize how a tester adds value to iteration and release planning. FL-5.1.3 (K2) Compare and contrast entry criteria and exit criteria. FL-5.1.4 (K3) Use estimation techniques to calculate the required test effort. FL-5.1.5 (K3) Apply test case prioritization. FL-5.1.6 (K1) Recall the concepts of the test pyramid. FL-5.1.7 (K2) Summarize the testing quadrants and their relationships with test levels and test types. Content of the Syllabus 15 5.2 Risk management FL-5.2.1 (K1) Identify risk level by using risk likelihood and risk impact. FL-5.2.2 (K2) Distinguish between project risks and product risks. FL-5.2.3 (K2) Explain how product risk analysis may inﬂuence thoroughness and scope of testing. FL-5.2.4 (K2) Explain what measures can be taken in response to analyzed product risks. 5.3 Test monitoring, test control, and test completion FL-5.3.1 (K1) Recall metrics used for testing. FL-5.3.2 (K2) Summarize the purposes, content, and audiences for test reports. FL-5.3.3 (K2) Exemplify how to communicate the status of testing. 5.4 Conﬁguration management FL-5.4.1 (K2) Summarize how conﬁguration management supports testing. 5.5 Defect management FL-5.5.1 (K3) Prepare a defect report. Chapter 6. Test Tools The reader learns to classify tools and to understand the risks and beneﬁts of test automation. Learning Objectives 6.1 Tool support for testing FL-6.1.1 (K2) Explain how different types of test tools support testing. 6.2. Beneﬁts and risks of test automation FL-6.2.1 (K1) Recall the beneﬁts and risks of test automation. Foundation Level Exam Structure of the Exam The description of the Foundation Level certiﬁcation exam is deﬁned in a document entitled “Exam Structure Rules,” which is available at www.istqb.org. The exam is in the form of a multiple-choice test and consists of 40 questions. To pass the exam, it is necessary to answer at least 65% of the questions correctly (i.e., 26 questions). Examinations can be taken as part of an accredited training course or indepen- dently (e.g., at an examination center or in a public examination). Completion of an accredited course is not a prerequisite for taking the exam, but attending such a course is recommended, as it allows you to better understand the material and signiﬁcantly increases your chances of passing the exam. If you fail the exam, you can retake it as many times as you like. Exam Rules The Foundation Level exams are based on the Foundation Level syllabus. Answering an exam question may require using material from more than one section of the syllabus. All learning objectives included in the syllabus (with cognitive levels from K1 to K3) are subject to examination. All deﬁnitions of keywords in the syllabus are subject to examination (at the K1 level). An online dictionary is available at www.glossary.istqb.org. Each Foundation Level exam consists of a set of multiple-choice questions based on the learning objectives for Foundation Level syllabus. The level of coverage and distribution of questions are based on the learning objectives, their K levels, and their level of importance according to the ISTQB® assessment. For details on © The Author(s), under exclusive license to Springer Nature Switzerland AG 2024 17 L. Stapp et al., ISTQB® Certiﬁed Tester Foundation Level 18 Foundation Level Exam Table 1 Distribution of exam questions by K level K-level Number of questions Time per question [in min] Average time for level K [in min] K1 8 1 8 K2 24 1 24 K3 8 3 24 Total 40 56 the structure of each exam component, see the “Distribution of Questions” subsection below. In general, it is expected that the time to read, analyze, and answer questions at K1 and K2 levels should not exceed 1 min, and at K3 level, it may take 3 min. However, this is only a guideline for average time, and it is likely that some questions will require more and others less time to answer. The exam consists of 40 multiple-choice questions. Each correct answer is worth one point (regardless of the K level of the learning objective to which the question applies). The maximum possible score for the exam is 40 points. The time allotted for the exam is exactly 60 min. If the candidate’s native language is not the language of the exam, the candidate is allowed an additional 25% of the time (in the case of the Foundation Level exam, this means that the exam will last 75 min). A minimum of 65% (26 points) is required to pass. A general breakdown of questions by K level is shown in Table 1. Rules and recommendations for writing multiple-choice questions can be found in ISTQB®—Exam Information document. If you add up the expected time to answer the questions according to the rules given above, then—taking into account the distribution of questions by K levels— you will ﬁnd that it should take about 56 min to answer all the questions. This leaves a 4-min reserve. Each exam question should test at least one learning objective (LO) from the Foundation Level syllabus. Questions may include terms and concepts that exist in the K1 level sections, as candidates are expected to be familiar with them. In case the questions are related to more than one LO, they should refer (and be assigned) to the learning objective with the highest K level value. Distribution of Questions The structure of the Foundation Level exam is shown in Table 2. Each exam requires mandatory questions covering speciﬁc learning objectives, as well as a certain number of questions based on the selected learning objectives. If the number of learning objectives is greater than the number of questions for a speciﬁc group of Distribution of Questions 19 Table 2 Detailed distribution of exam questions by K levels and chapters Number of questions from Scoring of The distribution of K- the selected group of learning a single questions level objectives question Chapter 1 FL-1.1.1, FL-1.2.2 K1 1 1 A total of 8 ques- FL-1.5.2 K1 1 1 tions required for FL-1.1.2, FL-1.2.1, K2 1 1 Chap. 1 FL-1.2.3 K1 = 2 K2 = 6 FL-1.3.1 K2 1 1 K3 = 0 FL-1.4.1, FL-1.4.2, K2 3 1 Number of points FL-1.4.3, FL-1.4.4, for this chapter = 8 FL-1.4.5 FL-1.5.1, FL-1.5.3 K2 1 1 Chapter 2 FL-2.1.2 K1 1 1 A total of 6 ques- FL-2.1.3 K1 1 1 tions required for FL-2.2.1, FL-2.2.2 K2 1 1 Chap. 2 K1 = 2 FL-2.2.3, FL-2.3.1 K2 1 1 K2 = 4 FL-2.1.1, FL-2.1.6 K2 1 1 K3 = 0 FL-2.1.4, FL-2.1.5 K2 1 1 Number of points for this chapter = 6 Chapter 3 FL-3.1.1, FL-3.2.1, K1 2 1 A total of 4 ques- FL-3.2.3, FL-3.2.5 tions required for FL-3.1.2, FL-3.1.3 K2 1 1 Chap. 3 FL-3.2.2, FL-3.2.4 K2 1 1 K1 = 2 K2 = 2 K3 = 0 Number of points for this chapter = 4 Chapter 4 FL-4.1.1 K1 1 1 A total of 11 FL-4.3.1, FL-4.3.2, K2 2 1 questions required FL-4.3.3 for Chap. 4 FL-4.4.1, FL-4.4.2, K2 2 1 K1 = 0 FL-4.4.3 K2 = 6 K3 = 5 FL-4.5.1, FL-4.5.2 K2 1 1 Number of points FL-4.2.1, FL-4.2.2, K3 5 1 for this chapter = FL-4.2.3, FL-4.2.4, 11 FL-4.5.3 Chapter 5 FL-5.1.2, FL-5.1.6, K1 1 1 A total of 9 ques- FL-5.2.1, FL-5.3.1 tions required for FL-5.1.1, FL-5.1.3 K2 1 1 Chap. 5 FL-5.1.7 K2 1 1 K1 = 1 K2 = 5 FL-5.2.2, FL-5.2.3, K2 1 1 K3 = 3 FL-5.2.4 Number of points FL-5.3.2, FL-5.3.3 K2 1 1 for this chapter = 9 (continued) 20 Foundation Level Exam Table 2 (continued) Number of questions from Scoring of The distribution of K- the selected group of learning a single questions level objectives question FL-5.4.1 K2 1 1 FL-5.1.4, FL-5.1.5, K3 3 1 FL-5.5.1 Chapter 6 FL-6.1.1 K2 1 1 A total of 2 ques- FL-6.2.1 K1 1 1 tions required for Chap. 6 K1 = 1 K2 = 1 K3 = 0 Number of points for this chapter = 2 Certiﬁed Tester—Foundation Level SUMMARY 40 points, A total of 40 60 min questions learning objectives described in the table, each question must cover a different learning objective. The analysis of Table 2 shows that the following 17 learning objectives are certain to be covered and examined: Five K1-level questions (FL-1.5.2, FL-2.1.2, FL-2.1.3, FL-4.1.1, FL-6.2.1) Four K2-level questions (FL-1.3.1, FL-5.1.7, FL-5.4.1, FL-6.1.1) Eight questions covering all eight learning objectives at the K3 level Each of the remaining 23 questions will be selected from a group of two or more learning objectives. Since it is not known which of these learning objectives will be covered, the candidate must master all the material on the syllabus (all learning objectives) anyway. Tips: Before and During the Exam In order to successfully pass the exam, the ﬁrst thing you need to do is carefully read the syllabus and glossary of terms, knowledge of which is required at Foundation Level. This is because the exam is based on these two documents. It is advisable to also solve sample test questions and sample exams. On the ISTQB® website (www. istqb.org), you can ﬁnd ofﬁcial sample exam sets in English and on the Member Boards websites in other languages. The list of all ISTQB® member boards and their websites is published on www.istqb.org/certiﬁcations/member-board-list. This publication, in addition to a number of sample questions for each chapter of the syllabus, also includes the ofﬁcial ISTQB® sample exam. Tips: Before and During the Exam 21 During the exam itself, you should: Read the questions carefully—sometimes one word changes the whole meaning of the question or is a clue to give the correct answer! Pay attention to keywords (e.g., in what software development life cycle model the project is run). Try to match the question with the learning objective—then it will be easier to understand the idea of the question and justify the correctness and incorrectness of individual answers. Be careful with questions containing negation (e.g., “which of the following is NOT...”)—in such questions, three answers will be true statements, and one will be false statement. You need to indicate the answer containing the false statement. Choose the option that directly answers the question. Some answers may be completely correct sentences, but do not answer the question asked—for exam- ple, the question is about the risks of automation, and one of the answers mentions some beneﬁt of automation. Guess if you don’t know which answer to choose—there are no negative points, so it doesn’t pay to leave questions unanswered. Remember that answers with strong, categorical phrases are usually incorrect (e.g., “always,” “must be,” “never,” “in any case”)—although this rule may not apply in all cases. Part II The Syllabus Content Chapter 1 Fundamentals of Testing Keywords: Coverage the degree to which speciﬁed coverage items are exercised by a test suite expressed as a percentage. Synonyms: test coverage. Debugging the process of ﬁnding, analyzing, and removing the causes of failures in a component or system. Defect an imperfection or deﬁciency in a work product where it does not meet its requirements or speciﬁcations. After ISO 24765. Synonyms: bug, fault. Error a human action that produces an incorrect result. After ISO 24765. Synonyms: mistake. Failure an event in which a component or system does not perform a required function within speciﬁed limits. After ISO 24765. Quality The degree to which a work product satisﬁes stated and implied needs of its stakeholders. After IREB. Quality assurance activities focused on providing conﬁdence that quality requirements will be fulﬁlled. Abbreviation: QA. After ISO 24765. Root cause a source of a defect such that if it is removed, the occurrence of the defect type is decreased or removed. References: CMMI Test analysis the activity that identiﬁes test conditions by analyzing the test basis. Test basis The body of knowledge used as the basis for test analysis and design. After TMap. © The Author(s), under exclusive license to Springer Nature Switzerland AG 2024 25 L. Stapp et al., ISTQB® Certiﬁed Tester Foundation Level 26 Chapter 1 Fundamentals of Testing Test case a set of preconditions, inputs, actions (where applicable), expected results, and postconditions, developed based on test conditions. Test completion the activity that makes testware available for later use, leaves test environments in a satisfactory condition, and communicates the results of testing to relevant stakeholders. Test condition a testable aspect of a component or system identiﬁed as a basis for testing. References: ISO 29119-1. Synonyms: test situation, test requirement. Test control the activity that develops and applies corrective actions to get a test project on track when it deviates from what was planned. Test data data needed for test execution. Synonyms: test dataset. Test design the activity that derives and speciﬁes test cases from test conditions. Test execution the activity that runs a test on a component or system producing actual results. Test implementation the activity that prepares the testware needed for test execution based on test analysis and design. Test monitoring the activity that checks the status of testing activities, identiﬁes any variances from planned or expected, and reports status to stakeholders. Test object the work product to be tested. Test objective the purpose for testing. Synonyms: test goal. Test planning the activity of establishing or updating a test plan. Test procedure a sequence of test cases in execution order and any associated actions that may be required to set up the initial preconditions and any wrap-up activities post execution. References: ISO 29119-1. Test result the consequence/outcome of the execution of a test. Synonyms: outcome, test outcome, result. Testing the process within the software development life cycle that evaluates the quality of a component or system and related work products. Testware work products produced during the test process for use in planning, designing, executing, evaluating, and reporting on testing. After ISO 29119-1. Validation Conﬁrmation by examination that a work product matches a stakeholder’s needs. After IREB. Veriﬁcation Conﬁrmation by examination and through provision of objective evidence that speciﬁed requirements have been fulﬁlled. References: ISO 9000. 1.1 What Is Testing? 27 1.1 What Is Testing? FL-1.1.1 (K1) Identify typical test objectives. FL-1.1.2 (K2) Differentiate testing from debugging. Nowadays, there is probably no area of life where software is not used to a greater or lesser extent. Information systems are playing an increasingly important role in our lives, from business solutions (banking sector, insurance) to consumer devices (cars), entertainment (computer games), or communications. Using software that contains defects can: Cause a loss of money or time Cause a loss of customer conﬁdence Make it difﬁcult to gain new customers Eliminate from the market In extreme situations—cause a threat to health or life Testing of software enables the assessment of software quality and contrib- utes to reducing the risk of software failure in action. Therefore, good testing is essential for project success. Software testing is a set of activities carried out to facilitate the detection of defects and evaluate the properties of software artifacts. Each of these testing artifacts is known as the test object. Many people, including those working in the IT industry, mistakenly think of testing as just executing tests, that is, running software to ﬁnd defects. However, executing tests is only part of testing. There are other activities involved in testing. These activities occur both before (items 1–5 below) and after (item 7 below) test execution. These are: 1. Test planning 2. Test monitoring and test control 3. Test analysis 4. Test design 5. Test implementation 6. Test execution 7. Test completion Testing activities are organized and carried out differently in different software development life cycle (SDLC) models (see Chap. 2). Moreover, testing is often seen as an activity focused solely on veriﬁcation of requirements, user stories, or other forms of speciﬁcation (i.e., checking that the system meets the speciﬁed requirements). But testing also includes validation —that is, verifying that the system meets user requirements and other stakeholder needs in its operational environment. Testing may require running the component or system under test—then we have what is called dynamic testing. You can also perform testing without running the 28 Chapter 1 Fundamentals of Testing object under test—such testing is called static testing. Testing thus also includes reviews of work products such as: Requirements User stories Source code Static testing is described in more detail in Chap. 3. Dynamic testing uses different types of test techniques (e.g., black-box, white-box, and experience- based) to derive test cases and is described in detail in Chap. 4. Testing is not just a technical activity. The testing process must also be properly planned, managed, estimated, monitored, and controlled (see Chap. 5). Testers extensively use various types of tools in their daily work (see Chap. 6), but it is important to remember that testing is largely an intellectual, sapient activity, requir- ing testers to have specialized knowledge, analytical skills, critical thinking, and systems thinking [10, 11]. ISO/IEC/IEEE 29119-1 provides additional information on the concept of software testing. It is worth remembering that testing is a technical study to obtain information about the quality of the test object: Technical—because we use an engineering approach, using experiments, expe- rience, formal techniques, mathematics, logic, tools (supporting programs), measurements, etc. Study—because it is a continuous organized search for information 1.1.1 Test Objectives Testing enables the detection of failures or defects in the work product under test. This fundamental property of testing enables to achieve a number of objectives. The primary test objectives are: Evaluating work products such as requirements, user stories, designs, and code Triggering failures and ﬁnding defects Ensuring required coverage of a test object Reducing the level of risk of inadequate software quality Verifying whether speciﬁed requirements have been fulﬁlled Verifying that a test object complies with contractual, legal, and regulatory requirements Providing information to stakeholders to allow them to make informed decisions Building conﬁdence in the quality of the test object Validating whether the test object is complete and works as expected by the stakeholders 1.1 What Is Testing? 29 Different goals require different testing strategies. For example, in the case of component testing—i.e., testing individual pieces of an application/system (see Sect. 2.2)—the goal may be to trigger as many failures as possible so that the defects causing them can be identiﬁed and ﬁxed early. One may also aim to increase code coverage through component testing. In acceptance testing (see Sect. 2.2), on the other hand, the goals may be: To conﬁrm that the system works as expected and meets its (user) requirements To provide stakeholders with information on the risks involved in releasing the system at a given time In acceptance testing [especially user acceptance testing (UAT)], we do not expect to detect a large number of failures or defects, as this may lead to a loss of conﬁdence by future users (see Sect. 2.2.1.4). These failures or defects should be detected at earlier stages of testing. 1.1.2 Testing and Debugging Some people think that testing is about debugging. However, it is important to remember that testing and debugging are two different activities. Testing (especially dynamic testing) is supposed to reveal failures caused by defects. Debugging , on the other hand, is a programming activity performed to identify the cause of a defect (fault), correcting the code and verifying that the defect has been correctly ﬁxed. When dynamic tests detect a failure, a typical debugging process will consist of the following steps: Failure reproduction (in order to make sure that the failure actually occurs and so that it can be triggered in a controlled manner in the subsequent debugging process) Diagnosis (ﬁnding the cause of the failure, such as locating the defect responsible for the occurrence of that failure) Fixing the cause (eliminating the cause of failure, such as ﬁxing a defect in the code) The subsequent conﬁrmation testing (re-testing) performed by the tester is to ensure that the ﬁx actually ﬁxed the failure. Most often, conﬁrmation testing is performed by the same person who performed the original test that revealed the problem. Regression testing can also be performed after the ﬁx to verify that the ﬁx in the code did not cause the software to malfunction elsewhere. Conﬁrmation testing and regression testing are discussed in detail in Sect. 2.2.3. When static testing discovers a defect, the debugging process is simply to eliminate the defect. It is not necessary, as in the case of failure discovery in dynamic testing, to perform failure reproduction and diagnosis, because in static testing, the work product under test is not run. The related source code might not even have been 30 Chapter 1 Fundamentals of Testing Fig. 1.1 Software failure created. This is because static testing does not ﬁnd failures but directly identiﬁes defects. Static testing is discussed in detail in Chap. 3. Example Consider a simpliﬁed version of the problem described by Myers. We are testing a program that receives three natural numbers, a, b, c, as the input. The program answers “yes” or “no,” depending on whether a triangle can be constructed from segments with sides of lengths a, b, c. The program is in the form of an executable ﬁle triangle.exe and takes input values from the keyboard. The tester prepared several test cases. In particular, the tester ran the program for the input data a = b = c = 16,500 (a test case involving the entry of very large, but valid input values) and received the result presented in Fig. 1.1. The program answered “no,” i.e., it stated that it is impossible to build a triangle from three segments of length 16,500 each. This is a failure, because the expected result is “yes”—it is possible to build an equilateral triangle from such segments. The tester reported this defect to the developer. The developer repeated the test case and got the same result. The developer began to analyze the code, which looks as follows: int main(int argc, _TCHAR* argv[]) { short a,b,c,d; scanf("%d",&a); scanf("%d",&b); scanf("%d",&c); d=a+b; if (abs(a-b)0 AND a+c>b>0 AND b+c>a>0) THEN (you can build a triangle with sides of length a, b, c); IF (monthlySalary > 10000) THEN (grant bank loan AND offer a gold card). Decision tables allow us to systematically test the correctness of the implemen- tation of combinations of conditions. This is one of the so-called combinatorial 4.2 Black-Box Test Techniques 195 Table 4.4 Example decision table Business rules 1–8 1 2 3 4 5 6 7 8 Conditions Has a loyalty card? YES YES YES YES NO NO NO NO Total amount > $1000? YES YES NO NO YES YES NO NO Shopping in last 30 days? YES NO YES NO YES NO YES NO Actions Granted discount 10% 5% 5% 0% 0% 0% 0% 0% techniques. For more information on these techniques, see the Advanced Level— Test Analyst syllabus. Construction of the Decision Table We will describe the construction of the decision table using an example (see Table 4.4). The decision table consists of two parts, describing conditions (upper part) and actions (lower part), respectively. The individual columns describe business rules. Table 4.4 describes the rules for assigning a discount on purchases depending on three factors describing the customer in question: Does the customer have a loyalty card? (YES or NO) Does the total amount of purchases exceed $1000? (YES or NO) Has the customer made purchases in the last 30 days? (YES or NO) Based on the answers to these questions, a discount is assigned: 0%, 5%, or 10%. Example A customer has a loyalty card and has so far made purchases of $1250, and the last purchases took place 5 days ago. This situation corresponds to rule 1 (has a loyalty card, total amount >$1000, shopping in the last 30 days). So, the system should assign a 10% discount to this customer. Deriving Test Cases from the Decision Table The process of creating speciﬁc test cases using decision tables can be presented in the following ﬁve steps. Step 1. Identify all possible single conditions (from the test basis, e.g., based on speciﬁcations, customer conversations, so-called common sense), and list them in the consecutive rows in the upper part of the table. If needed, split compound conditions into single conditions. Conditions usually appear in speciﬁcations as sentence fragments preceded by words such as “if,” “in the event that,” etc. Step 2. Identify all corresponding actions that can occur in the system and that are dependent on these conditions (also derived from the test basis), and list them in the consecutive lines in the lower part of the table. Actions usually appear in speciﬁca- tions as sentence fragments preceded by words such as “then,” “in this case,” “the system should,” etc. 196 Chapter 4 Test Analysis and Design Step 3. Generate all combinations of conditions, and eliminate infeasible combi- nations of conditions. For each feasible combination, a separate column is created in the table with the values of each condition listed in this column. Step 4. Identify, for each identiﬁed combination of conditions, which actions and how they should occur. This results in completing the bottom part of the corresponding column of the decision table. Step 5. For each column of the decision table, design a test case in which the test input represents combination of conditions speciﬁed in this column. The test is passed if, after its execution, the system takes actions as described at the bottom part of the table in the corresponding column. These action entries serve as the expected output for the test case. Notation and Possible Entries in the Decision Table Typically, condition and action values take the form of logical values TRUE or FALSE. They can be represented in various ways, such as the symbols T and F or Y and N (yes/no) or 1 and 0 or as the words “true” and “false.” However, the values of conditions and actions can in general be any objects, such as numbers, ranges of numbers, category values, equivalence partitions, and so on. For example, in our table (Table 4.4), the values of the “discount granted” action are categories expressing different types of discounts: 0%, 5%, and 10%. In the same table, there can be conditions and actions of different types, e.g., logical, numerical, and categorical conditions can occur simultaneously. The decision table with only Boolean (true/false) values is called a limited-entry decision table. If for any condition or action there are other than Boolean entries, such a table is called an extended-entry decision table. How to Determine all Combinations of Conditions If we need to manually determine combinations of conditions, and we are afraid that we will miss some combinations, we can use a very simple tree method to system- atically determine all combinations of conditions. Consider the following example: Example Suppose a decision table has three conditions: Earnings (two possible values—S, small; L, large) Age (three possible values—Y, young; MA, middle aged; O, old) Place of living (two possible values—C, city; V, village) To create all combinations of values of triples (age, earnings, residence), we build a tree, from the root of which we derive all possibilities of the ﬁrst condition (earnings). This is the ﬁrst level of the tree. Next, from each vertex of this level, we derive all the possibilities of the second condition (age). We get the second level of the tree. Finally, from each vertex of this level, we derive all the possible values of the third condition (place of living). Of course, if there were more conditions, we would proceed analogously. Our ﬁnal tree looks like the one in Fig. 4.8. Each possible combination of conditions is a combination of vertex labels on the paths leading from the root (the vertex at the top of the tree) to any vertex at the very bottom of the tree. Thus, there will be as many combinations as there are vertices at 4.2 Black-Box Test Techniques 197 Fig. 4.8 Support tree for identifying combinations of conditions the lowest level (in our case—12; this, of course, follows from the number of combinations: 2 × 3 × 2 = 12). In the ﬁgure, the bold lines indicate the path corresponding to the example combination (S, MA, C), which means small earnings, middle age, and city as the place of living. We can now enter each of these combinations into the individual columns of our decision table. At the same time, we are sure that no combination has been left out. The conditions of the decision table thus created are shown in Table 4.5. Infeasible Combinations Sometimes, after listing all possible combinations of conditions, you may ﬁnd that some of them are infeasible for various reasons. For example, suppose we have the following two conditions in the decision table: Customer’s age >18? (possible values: YES, NO) Customer’s age ≤18? (possible values: YES, NO) It is obvious that although we have four possible combinations of these condi- tions, (YES, YES), (YES, NO), (NO, YES), and (NO, NO), only two of them are feasible, (YES, NO) and (NO, YES), since it is impossible to be more than 18 and less than 19 years old at the same time. Of course, in this case, we could replace these two conditions with one, “age”, and with two possible values: greater than 18 and less than or equal to 18. Sometimes, the decision table will not contain some combinations not for purely logical reasons but for semantic reasons. For example, if we have two conditions: Was the goal deﬁned? (YES, NO) Was the goal achieved? (YES, NO) then the combination (NO, YES) is infeasible (nonsensical), because it is impos- sible to achieve a goal that you have not previously deﬁned. 198 Chapter 4 Test Analysis and Design Table 4.5 Combinations of decision table conditions formed from the support tree 1 2 3 4 5 6 7 8 9 10 11 12 Earnings S S S S S S L L L L L L Age Y Y MA MA O O Y Y MA MA O O Place of residence C V C V C V C V C V C V Minimizing the Decision Table Sometimes, some conditions may not have any effect on the actions taken by the system. For example, if the system allows only adult customers to buy insurance, and depending on whether they smoke or not they get a discount on that insurance, then as long as the customer is a minor, the system will not allow them to buy insurance regardless of whether the customer smokes or not. Such irrelevant values are most often marked in the decision table with a dash symbol or N/A (not applicable). Typically, a dash is used when the corresponding condition occurs, but its value is irrelevant for determining the action. The N/A symbol, on the other hand, is used when the condition cannot occur. For example, consider two conditions: “payment type” (card or cash) and “is the PIN correct?” (yes or no). If the payment type is cash, we can’t even check the value of the condition “is the PIN correct?” because the condition doesn’t occur at all. So we have only three possible combinations of conditions: (card, yes), (card, no) and (cash, N/A). This minimization, or collapsing, makes the decision table more compact with fewer columns and therefore fewer test cases to execute. On the other hand, for a test with an irrelevant value in the actual test case, we have to choose some speciﬁc, concrete value for this condition. So, there is a risk that if a defect occurs for some speciﬁc combination of values marked as irrelevant in the decision table, we can easily miss it and not test it. Minimizing decision tables is however a risk mitigation exercise: maybe the current mock-up of the GUI does not allow certain input, but the actual implemen- tation might or a future API might just as well. Consider the collapsed decision table shown in Table 4.6. If we wanted to design a concrete test case for the ﬁrst column, we would have to decide whether the customer smokes or not (although from the point of view of the speciﬁcation this is irrelevant), because this input should be given. We can decide on the combination (adult = NO, smokes = NO), and such a test will pass, but we can imagine that due to some defect in the code, the program does not work properly for the combination (adult = NO, smokes = YES). Such a combination has not been tested by us, and failure will not be detected. On the actual exam, there may be questions involving minimized decision tables, but the candidate is not required to be able to perform minimization but only to be able to understand, interpret, and use decision tables that are already minimized. The minimization is required on the Advanced Level—Test Analyst certiﬁcation exam. Therefore, in this book, we do not present an algorithm for minimizing decision tables. Coverage In decision table testing, the coverage items are the individual columns of the table, containing possible combinations of conditions (i.e., the so-called feasible columns). 4.2 Black-Box Test Techniques 199 Table 4.6 Decision table CONDITIONS with irrelevant values Adult? NO YES YES Smokes? – YES NO ACTIONS Grant insurance? NO YES YES Grant discount? NO NO YES For a given decision table, full 100% coverage requires that at least one test case corresponding to each feasible column be prepared and executed. The test is passed if the system actually executes the actions deﬁned for that column. The important thing is that coverage counts against the number of (feasible) columns of the decision table, not against the number of all possible combinations of conditions. Usually, these two numbers are equal, but in the case of the occurrence of infeasible combinations, as we discussed earlier, this might not be the case. For example, in order to achieve 100% coverage for the decision table in Table 4.6, we need three (not four, as the number of combinations would suggest) test cases. If we had the following tests: Adult = YES, smokes = YES. Adult = NO, smokes = YES. Adult = NO, smokes = NO. then we would achieve 2/3 coverage (or about 66%), since the last two test cases cover the same, ﬁrst column of the table. Decision Tables as a Static Testing Technique The decision table testing is excellent for detecting problems with requirements, such as their absence or contradiction. Once the decision table is created from the speciﬁcation or even while it is still being created, it is very easy to discover such speciﬁcation problems as: Incompleteness—no deﬁned actions for a speciﬁc combination of conditions Contradiction—deﬁning in two different places of speciﬁcation two different behaviors of the system against the same combination of conditions Redundancy—deﬁning the same system behavior in two different places in the speciﬁcation (perhaps described differently) 4.2.4 State Transition Testing Application State transition testing is a technique used to check the behavior of a compo- nent or system. Thus, it checks its behavioral aspect—how it behaves over time and how it changes its state under the inﬂuence of various types of events. The model describing this behavioral aspect is the so-called state transition diagram. In the literature, different variants of this model are called a ﬁnite autom- aton, ﬁnite state automaton, state machine, or Labeled Transition System. The 200 Chapter 4 Test Analysis and Design syllabus uses the name “state transition diagram” to denote the graphical form of the state transition model and “state transition table” to denote the equivalent, tabular form of the model. Construction of the State Transition Diagram A state transition diagram is a graphical model, as described in the UML standard. From a theoretical point of view, it is a labeled directed graph. The state transition diagram consists of the following elements: States—represent possible situations in which the system may be Transitions—represent possible (correct) changes of states Events—represent phenomena, usually external to the system, the occurrence of which triggers the corresponding transitions Actions—actions that the system can take during the transition between states Guard conditions—logical conditions associated with transitions; a transition can be executed only if the associated guard condition is true Figure 4.9 shows an example of a state transition diagram. It is not trivial, although in practice even more complicated models are often used, using richer notation than that discussed in the syllabus. However, this diagram allows us to show all the essential elements of the state transition model described in the syllabus while keeping the example practical. The diagram represents a model of the system’s behavior for making a phone call to a cell phone user with a speciﬁc number. The user dials a nine-digit phone number by pressing the keys corresponding to successive digits of the number one by one. When the ninth digit is entered, the system automatically attempts the call. The state transition diagram modeling this system consists of ﬁve states (rectangles). The possible transitions between them are indicated by arrows. The system starts in the initial state Welcome screen and waits for an event (labeled EnterDigit) involving the user selecting the ﬁrst digit of a nine-digit phone number. When this event occurs, the system transitions to the Entering state, and in addition, during this transition, the system performs an action to set the value of the x variable to 1. This variable will represent the number of digits of the dialed phone number entered by the user so far. In the Entering state, only the EnterDigit event can occur, but depending on how many digits have been entered so far, transitions to two different states are possible. As long as the user has not entered the ninth digit, the system remains in the Entering state, each time increasing the x variable by one. This is because the guard condition “x < 8” is true in this situation. Just before the user enters the last, ninth digit, the variable x has a value of 8. This means that the guard condition “x < 8” is false and the guard condition “x = 8” is true. Therefore, selecting the last, ninth digit of the number will switch from the Entering state under the EnterDigit event to the Connect state. When the call succeeds (the occurrence of the ConnectionOK event), the system enters the Call state, in which it remains until the user terminates the call, which will be signaled by the occurrence of the EndConnection event. At this point, the system goes to the ﬁnal state End, and its operation ends. If the system is in the Connect state and the ConnectionError event occurs, the system transitions to the ﬁnal state, but unlike the analogous transition from the Call state, it will additionally perform the 4.2 Black-Box Test Techniques 201 Fig. 4.9 Example of state transition diagram ErrorMessage action, signaling to the user the inability to connect to the selected number. The system at each moment of time is in exactly one of the states, and the change of states occurs as a result of the occurrence of corresponding events. The concept of state is abstract. A state can denote a very-high-level situation (e.g., the system being in a certain application screen), but it can also describe low-level situations (e.g., the system executing a certain program statement). The level of abstraction depends on the model adopted, i.e., what the model actually describes and at what level of generality. It is assumed that when a certain event occurs, the change of states is instantaneous (it can be assumed that it is a zero-duration event). The transition labels (i.e., arrows on the diagram) are in general of the form: event [guard condition] / action If, in a given case, the guard condition or action does not exist or is not relevant from the tester’s point of view, they can be omitted. Thus, transition labels can also take one of the following three forms: Event Event/action Event [guard condition] A guard condition for a given transition allows that transition to be executed only if the condition holds. Guard conditions allow us to deﬁne two different transitions under the same event while avoiding non-determinism. For example, in the diagram in Fig. 4.9 from the Entering state, we have two transitions under the EnterDigit event, but only one of them can be executed at any time because the corresponding guard conditions are disjoint (either x is less than 8 or is equal to 8). An example test case for the state transition diagram in Fig. 4.9, verifying the correctness of a successful connection, might look like the one in Table 4.7. 202 Chapter 4 Test Analysis and Design Table 4.7 Example of a sequence of transitions in the state transition diagram of Fig. 4.9 Step State Event Action Next state 1 Welcome screen EnterDigit x := 1 Entering 2 Entering EnterDigit x := x + 1 Entering 3 Entering EnterDigit x := x + 1 Entering 4 Entering EnterDigit x := x + 1 Entering 5 Entering EnterDigit x := x + 1 Entering 6 Entering EnterDigit x := x + 1 Entering 7 Entering EnterDigit x := x + 1 Entering 8 Entering EnterDigit x := x + 1 Entering 9 Entering EnterDigit x := 9 Connect 10 Connect ConnectionOK Call 11 Call EndConnection End The scenario is trigger

ISTQB CTFL 2024 Foundation Level PDF

Document Details

Tags

Related

Summary

Full Transcript