ISTQB ISTQB-CTFL ISTQB Certified Tester Foundation Level (CTFL v4.0) Exam Practice Test

Test planning involves defining the overall approach to testing, including scheduling, resources, and milestones. It is during this phase that the detailed schedule for each testing activity is determined based on estimates, resource availability, and constraints. The ISTQB CTFL Syllabus v4.0 outlines that test planning encompasses the creation of test plans and schedules to ensure that testing activities are properly managed and controlled​​.

This answer is correct because code-related white-box test techniques are test design techniques that use the structure of the code to derive test cases. They provide an objective measure of coverage, such as statement coverage, branch coverage, or path coverage, which indicate how much of the code has been exercised by the test cases. Code-related white-box test techniques can be used to complement black-box test techniques, which are test design techniques that use the functional or non-functional requirements of the system or component to derive test cases. By combining both types of techniques, testers can increase their confidence in the code and find more defects. References: ISTQB Glossary of Testing Terms v4.0, ISTQB Foundation Level Syllabus v4.0, Section 2.3.2.2

Using equivalence partitioning, the investment ranges are divided into four partitions:

R500 to R10,000 (10%)

R10,001 to R50,000 (11%)

R50,001 to R100,000 (12%)

R100,001 to R500,000 (13%)

Thus, the minimum number of test cases required to cover all valid equivalence partitions for calculating the interest is 4​​.

Test automation allows you to produce tests that are less subject to human errors, as they can execute predefined test scripts or test cases with consistent inputs, outputs, and expected results. Test automation can also reduce the manual effort and time required to execute repetitive or tedious tests, such as regression tests, performance tests, or data-driven tests. Test automation does not demonstrate the absence of defects, as it can only verify the expected behavior of the system under test, not the unexpected or unknown behavior. Test automation does not avoid performing exploratory testing, as exploratory testing is a valuable technique to discover new information, risks, or defects that are not covered by automated tests. Test automation does not increase test process efficiency by facilitating management of defects, as defect management is a separate activity that involves reporting, tracking, analyzing, and resolving defects, which may or may not be related to automated tests. References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 3.3.1, Test Automation1

ISTQB® Glossary of Testing Terms v4.0, Test Automation2

You should choose a test technique because you need to match the way you test to the content of the product under test. A test technique is a method or process for deriving and selecting test cases based on some criteria or rules. Different test techniques are suitable for different types of software products, depending on their characteristics, functionalities, requirements, specifications, risks, etc. Choosing a test technique helps to ensure that the test cases are relevant, effective, and efficient for the product under test. The other options are not correct reasons to choose a test technique. Time constraints are not a factor for choosing a test technique, but rather for prioritizing or optimizing testing activities. Covering the full scope of the product’s functionality is not a guarantee of choosing a test technique, but rather a goal of testing. Choosing a test technique is not a common practice in software testing, but rather a professional skill and responsibility. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 31.

The correct statement is B. According to the ISTQB CTFL syllabus, the testing quadrants help to categorize tests based on their purpose and whether they are technology-facing or business-facing, and whether they support the team or critique the product. Quadrant Q2 includes tests that are business-facing and support the team, such as automated acceptance tests produced during Behavior-Driven Development (BDD) and Acceptance Test-Driven Development (ATDD)​​ .

Quadrant Q3 includes business-facing tests that critique the product, such as exploratory testing, usability testing, and user acceptance testing. These tests are typically manual and focus on evaluating the product from a user perspective, rather than being part of a continuous integration process​​.

Quadrant Q4 includes technology-facing tests that critique the product, such as performance tests, security tests, and other non-functional tests, which can be automated but are not related to unit tests produced during TDD .

In Agile teams using the planning poker technique for estimating user stories, it is common practice to have further discussions and rounds of estimation if there is a significant discrepancy in the initial estimates. This helps in reaching a consensus and ensures that all team members understand the complexity and requirements of the user story. According to the ISTQB CTFL syllabus, planning poker involves discussions to clarify differences in estimates, especially when there is a wide range of values selected. By having Memb6 and Memb4, who provided the most pessimistic and optimistic estimates, explain their reasoning, it fosters a deeper understanding and encourages the team to converge towards a more accurate and agreed-upon estimate.

An incident is any event that occurs during testing that requires investigation. An incident report is a document that records the details of an incident. The next step the tester should take prior to recording the deviation is to try to recreate the incident before reporting. This can help confirm that the incident is reproducible and not caused by a random or external factor. This can also help gather more information about the incident, such as the steps to reproduce it, the expected and actual results, the severity and priority of the incident, or any screenshots or logs that can illustrate the incident. Trying to identify the code fragment causing the problem is not the next step the tester should take prior to recording the deviation, as this is a debugging activity that is usually performed by developers after receiving the incident report. Sending an email to the developer and not reporting the bug is not the next step the tester should take prior to recording the deviation, as this is an informal and unstructured way of communicating incidents that can lead to confusion, inconsistency or loss of information. Reporting the incident as is without any further action is not the next step the tester should take prior to recording the deviation, as this can result in incomplete or inaccurate incident reports that can hamper the investigation and resolution of incidents. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, Chapter 3, page 32-33.

This question asks for a non-functional aspect of testing the download process of a mobile application. Option A, "It was easy to locate, download and install the application," refers to usability, which is a non-functional quality attribute. Non-functional testing involves testing the system's attributes, such as usability, performance, reliability, etc., rather than specific behaviors or functions. Options B, "The application was correctly downloaded," C, "The application created an installation log file in a given folder," and D, "The application installed only after the user's approval," describe functional aspects, focusing on what the software does rather than how it performs or is experienced by the user.

The testing of software does not demonstrate the absence of defects, but rather the presence of defects or the conformance of the software to the specified requirements1. Testing can never prove that the software is defect-free, as it is impossible to test all possible scenarios, inputs, outputs, and behaviors of the software2. Testing can only provide a level of confidence in the quality of the software, based on the coverage, effectiveness, and efficiency of the testing activities3.

The other options are correct because:

A. Properly designed tests that pass reduce the level of risk in a system, as they verify that the system meets the expected quality attributes and satisfies the needs and expectations of the users and clients4. Risk is the potential for loss or harm due to the occurrence of an undesirable event5. Testing can help to identify, analyze, prioritize, and mitigate the risks associated with the software product and project6.

C. Software testing identifies defects, which can be used to improve development activities, as they provide feedback on the quality of the software and the effectiveness of the development processes7. Defects are flaws or errors in the software that cause it to deviate from the expected or required results or behavior. Testing can help to detect, report, track, and resolve the defects, and prevent them from recurring in the future.

D. Performing a review of the requirement specifications before implementing the system can enhance quality, as it can ensure that the requirements are clear, complete, consistent, testable, and aligned with the needs and expectations of the users and clients. Requirements are the specifications of what the software should do and how it should do it. Testing can help to validate that the requirements are met by the software, and verify that the software is implemented according to the requirements.

References =

1 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 10

2 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 11

3 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 12

4 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 13

5 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 97

6 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 98

7 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 14

[8] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 15

[9] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 16

[10] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 17

[11] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 18

[12] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 19

All testing levels are applicable, independent of which software development life-cycle process (V-model, iterative, incremental) is used. Testing levels are defined based on the scope and objectives of testing, not on the software development model. Component testing, integration testing, system testing and acceptance testing are common testing levels that can be applied to any software development model, as long as they are planned and executed properly. The V-model is a software development model that emphasizes the relationship between each development phase and its corresponding testing phase. Iterative and incremental models are software development models that divide the development process into smaller cycles or iterations, where each iteration produces a working version of the software that can be tested and evaluated. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 18.

Maintenance testing is testing performed on a software product after delivery to correct defects or improve performance or other attributes. Maintenance testing can be triggered by various situations, such as modifications to a released software or system, migration of the system data to a replacement system, or retirement of the software or system. Maintenance testing is not executed when there is an update to the maintainability requirements during the development phase, as this is not a maintenance situation but rather a change request that should be handled by the development process. Verified References: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer], Chapter 2, page 18-19.

The correct set of data for valid equivalence class partitions should include one value from each equivalence class, and no value from outside the range. Option C satisfies this condition, as it has one value from each of the four equivalence classes (50, 100, 250, 500). Option A has two values from the same equivalence class (100 and 200), option B has values outside the range (0 and 0.99), and option D has two values from the same equivalence class (1000 and 500). Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 35.

The principle of early testing is applicable to all recognized software development models, including sequential, iterative, and incremental models. Starting test activities early in the lifecycle helps in identifying and addressing defects as soon as possible, which can save time and costs by preventing defects from propagating to later stages of development. This proactive approach enhances the overall quality and efficiency of the software development process. Reference: ISTQB CTFL Syllabus V4.0, Section 1.3

The set of test inputs that achieve the relatively highest equivalence partition coverage for grading students is option D: 69, 79, 80, 89, 90. This set effectively tests the boundaries between each grade category, ensuring that the grading system accurately transitions from one grade to another at the correct thresholds​ (ISTQB Main Web)​.

The statement "Traceability may make it harder to understand the impact of changes" is incorrect. Traceability in testing actually facilitates understanding the impact of changes by linking test cases to requirements. This linkage helps ensure that any changes in the requirements are adequately reflected and verified in the test cases, thus supporting effective management of changes and maintaining the integrity of the system or product being developed​ (ISTQB not-for-profit association)​​ (ISTQB Main Web)​.

The purpose of a review is to find defects and improve the quality of the work product, not to criticize or blame the author. Reporting defects objectively means describing them factually and constructively, without using negative or emotional language that could offend the author or damage their motivation. This way, the author can take the feedback positively as an effort at improving the product and not as a personal assault. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 138.

When working on a project with incomplete requirements and under pressure to deploy, exploratory testing is particularly suitable. This type of testing allows testers to use their expertise and intuition to explore the system's functionality and identify defects without needing detailed specifications. Exploratory testing is flexible and can quickly adapt to changes and gaps in the requirements​​.

 If a program got 100% decision coverage in a test, then it is guaranteed that every executable statement is covered. Decision coverage (also known as branch coverage) is a type of structural coverage (also known as white-box coverage) that measures how many decision outcomes have been exercised by a test suite. A decision outcome is a possible result of a decision point (such as an if-then-else statement) in a program’s code. Decision coverage requires that each decision point has both true and false outcomes executed at least once by a test suite. Decision coverage implies statement coverage, which is another type of structural coverage that measures how many executable statements have been executed by a test suite. Statement coverage requires that each executable statement is executed at least once by a test suite. Therefore, if a program got 100% decision coverage in a test, then it also got 100% statement coverage in a test, which means that every executable statement is covered. The other options are not guaranteed to be true if a program got 100% decision coverage in a test. Every output equivalence class has been tested and every input equivalence class has been tested are not guaranteed to be true if a program got 100% decision coverage in a test, because equivalence classes are based on functional requirements or specifications, not on code structure or logic. Equivalence classes are used in specification-based testing (also known as black-box testing), which is a type of testing that does not consider the internal structure or implementation of the system under test. Decision coverage is used in structure-based testing (also known as white-box testing), which is a type of testing that considers the internal structure or implementation of the system under test. Therefore, achieving 100% decision coverage does not imply achieving 100% equivalence class coverage. The “dead” code has not been covered is not guaranteed to be true if a program got 100% decision coverage in a test, because dead code (also known as unreachable code) is code that can never be executed due to logical errors or design flaws. Dead code can reduce readability and maintainability of the code, as well as increase complexity and size. Decision coverage does not account for dead code, as it only considers the decision outcomes that are possible to execute. Therefore, achieving 100% decision coverage does not imply that the dead code has not been covered. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 36.

Problems in defining the right requirements is not a product risk, but rather a project risk. A product risk is a risk that affects the quality or performance of the software product itself, such as poor usability, failure-prone functionality, security vulnerabilities, compatibility issues, etc. A project risk is a risk that affects the management or delivery of the software project itself, such as unrealistic schedule, insufficient resources, unclear scope, changing requirements, etc. The other options are examples of product risks, as they relate to the software product’s characteristics or features. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 12.

Comprehensive and Detailed In-Depth Explanation:

The Moderator (D) plays a key role in formal reviews by facilitating discussions, ensuring that reviews stay on track, and creating an open environment for feedback. The Manager (A) is responsible for overseeing the testing process but does not directly facilitate reviews. The Reviewer (B) is responsible for examining the work product, while the Review Leader (C) organizes reviews but does not necessarily mediate them.

This answer is correct because Behavior-Driven Development (BDD) is a test-first approach, where tests that express a shared understanding from stakeholders of how the application is expected to work, are first written in business-readable language (following the Given/When/Then format), and then made executable to drive development. BDD is a collaborative approach that involves testers, developers, business analysts, product owners, and other stakeholders in defining the expected behavior of the application using scenarios that describe the preconditions, actions, and outcomes of the application. BDD scenarios are written using a domain-specific language (DSL) that can be translated into executable test cases using tools such as Cucumber or SpecFlow. BDD aims to improve communication, collaboration, and feedback among the team members, and to deliver software that meets the customer’s needs and expectations. References: ISTQB Glossary of Testing Terms v4.0, ISTQB Foundation Level Syllabus v4.0, Section 3.1.1.4

, Requirements Engineering Fundamentals.

The statement that refers to good testing practice to be applied regardless of the chosen software development model is option D, which says that involvement of testers in work product reviews should occur as early as possible to take advantage of the early testing principle. Work product reviews are static testing techniques, in which the work products of the software development process, such as the requirements, the design, the code, the test cases, etc., are examined by one or more reviewers, with or without the author, to identify defects, violations, or improvements. Involvement of testers in work product reviews can provide various benefits for the testing process, such as improving the test quality, the test efficiency, and the test communication. The early testing principle states that testing activities should start as early as possible in the software development lifecycle, and should be performed iteratively and continuously throughout the lifecycle. Applying the early testing principle can help to prevent, detect, and remove defects at an early stage, when they are easier, cheaper, and faster to fix, as well as to reduce the risk, the cost, and the time of the testing process. The other options are not good testing practices to be applied regardless of the chosen software development model, but rather specific testing practices that may or may not be applicable or beneficial for testing, depending on the context and the objectives of the testing activities, such as:

Tests should be written in executable format before the code is written and should act as executable specifications that drive coding: This is a specific testing practice that is associated with test-driven development, which is an approach to software development and testing, in which the developers write automated unit tests before writing the source code, and then refactor the code until the tests pass. Test-driven development can help to improve the quality, the design, and the maintainability of the code, as well as to provide fast feedback and guidance for the developers. However, test-driven development is not a good testing practice to be applied regardless of the chosen software development model, as it may not be feasible, suitable, or effective for testing in some contexts or situations, such as when the requirements are unclear, unstable, or complex, when the test automation tools or skills are not available or adequate, when the testing objectives or levels are not aligned with the unit testing, etc.

Test levels should be defined such that the exit criteria of one level are part of the entry criteria for the next level: This is a specific testing practice that is associated with sequential software development models, such as the waterfall model, the V-model, or the W-model, in which the software development and testing activities are performed in a linear and sequential order, with well-defined phases, deliverables, and dependencies. Test levels are the stages of testing that correspond to the levels of integration of the software system, such as component testing, integration testing, system testing, and acceptance testing. Test levels should have clear and measurable entry criteria and exit criteria, which are the conditions that must be met before starting or finishing a test level. In sequential software development models, the exit criteria of one test level are usually part of the entry criteria for the next test level, to ensure that the software system is ready and stable for the next level of testing. However, this is not a good testing practice to be applied regardless of the chosen software development model, as it may not be relevant, flexible, or efficient for testing in some contexts or situations, such as when the software development and testing activities are performed in an iterative and incremental order, with frequent changes, feedback, and adaptations, as in agile software development models, such as Scrum, Kanban, or XP, when the test levels are not clearly defined or distinguished, or when the test levels are performed in parallel or concurrently, etc.

Test objectives should be the same for all test levels, although the number of tests designed at various levels can vary significantly: This is a specific testing practice that is associated with uniform software development models, such as the spiral model, the incremental model, or the prototyping model, in which the software development and testing activities are performed in a cyclical and repetitive manner, with similar phases, deliverables, and processes. Test objectives are the goals or the purposes of testing, which can vary depending on the test level, the test type, the test technique, the test environment, the test stakeholder, etc. Test objectives can be defined in terms of the test basis, the test coverage, the test quality, the test risk, the test cost, the test time, etc. Test objectives should be specific, measurable, achievable, relevant, and time-bound, and they should be aligned with the project objectives and the quality characteristics. In uniform software development models, the test objectives may be the same for all test levels, as the testing process is repeated for each cycle or iteration, with similar focus, scope, and perspective of testing. However, this is not a good testing practice to be applied regardless of the chosen software development model, as it may not be appropriate, realistic, or effective for testing in some contexts or situations, such as when the software development and testing activities are performed in a hierarchical and modular manner, with different phases, deliverables, and dependencies, as in sequential software development models, such as the waterfall model, the V-model, or the W-model, when the test objectives vary according to the test levels, such as component testing, integration testing, system testing, and acceptance testing, or when the test objectives change according to the feedback, the learning, or the adaptation of the testing process, as in agile software development models, such as Scrum, Kanban, or XP, etc. References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 1.1.1, Testing and the Software Development Lifecycle1

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 1.2.1, Testing Principles1

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 1.2.2, Testing Policies, Strategies, and Test Approaches1

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 1.3.1, Testing in Software Development Lifecycles1

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.1, Test Planning1

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.2, Test Monitoring and Control1

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.3, Test Analysis and Design1

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.4, Test Implementation1

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.5, Test Execution1

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.6, Test Closure1

ISTQB® Glossary of Testing Terms v4.0, Work Product Review, Static Testing, Early Testing, Test-driven Development, Test Level, Entry Criterion, Exit Criterion, Test Objective, Test Basis, Test Coverage, Test Quality, Test Risk, Test Cost, Test Time2

Decision tables are used to model complex decision logic by considering different combinations of conditions and actions. Based on the given decision table for prescribing drug therapy:

Column 1 and Column 3 both result in the same actions (prescribing Amoxicillin).

These columns can be merged because the actions taken do not depend on whether the patient is taking anticoagulant therapy (both are 'T' for this condition).

Thus, combining these columns simplifies the decision table without losing any information.

Equivalence partitioning is a technique that divides the input data and output results of a software component into partitions of equivalent data. Each partition should contain data that is treated in the same way by the component. Equivalence partitioning can be used to reduce the number of test cases by selecting one representative value from each partition. Equivalence partitioning is suitable for testing the price computation, as it can identify different partitions based on the passenger type, the travelling type, the distance and the kind of transport. Equivalence partitioning is not statement coverage, which is a technique that measures how many executable statements in a source code are executed by a test suite. Statement coverage is not appropriate for testing the price computation, as it does not consider the input data or output results. Equivalence partitioning is not state transition testing, which is a technique that models how a system transitions from one state to another depending on events or conditions. State transition testing is not relevant for testing the price computation, as it does not involve any states or transitions. Equivalence partitioning is not use case testing, which is a technique that tests how users interact with a system to achieve a specific goal. Use case testing is not applicable for testing the price computation, as it does not focus on a single function or component. Verified References: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer], Chapter 4, page 37-38.

Achieving full code coverage does not guarantee that the component or system is fully tested or free of defects. Code coverage metrics indicate the extent to which the source code has been tested, but they do not account for the quality of the tests or whether all possible scenarios have been considered. Other types of testing, including functional, performance, and security testing, are necessary to ensure comprehensive testing. The ISTQB CTFL Syllabus v4.0 highlights that while high code coverage is beneficial, it does not equate to complete testing​​.

Experience based techniques (EBT) are techniques that use the knowledge, intuition and skills of the test engineers to design and execute tests. EBT use tests derived from the test engineers’ previous experience with similar technologies, domains, applications or systems. EBT are not based on the ability of the test engineer to implement various testing techniques, but rather on their personal judgment and creativity. EBT are not done as a second stage of testing, after non-experience-based testing took place, but rather as a complementary or alternative approach to other techniques. EBT require broad and deep knowledge in both testing and the application or technological domain, as this can help the test engineer identify potential risks, scenarios or defects. Verified References: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer], Chapter 5, page 48-49.

The whole team approach involves collaboration among all team members, including testers, developers, and business representatives, to achieve quality goals. However, this approach may not be suitable in situations where a high level of test independence is required. Test independence is essential in cases where unbiased testing is critical, such as in regulated environments or where high-risk systems are involved. This is because team members might unintentionally influence each other's work, leading to potential bias in testing outcomes​​.

The test levels and their objectives can be matched as follows:

Verifying whether the functional and non-functional behaviors of the system are as designed and specified (A3: System testing).

Verifying whether the functional and non-functional behaviors of the interfaces are as designed (B2: Integration testing).

Verifying whether the functional and non-functional behaviors of the components are as designed and specified (C1: Component testing).

Establishing confidence in the quality of the system as a whole (D4: Acceptance testing)​​.

This answer is correct because a walkthrough is a type of review where the author of the work product leads the review process and explains the work product to the reviewers. The reviewers are not required to prepare for the review in advance, and the main objective of the walkthrough is to establish a common understanding of the work product and to identify any major defects or issues. A walkthrough is usually informal and does not follow a defined process or roles. In this case, the review for a high-level architectural document written by a software architect matches the characteristics of a walkthrough. References: ISTQB Glossary of Testing Terms v4.0, ISTQB Foundation Level Syllabus v4.0, Section 2.4.2.2

Independent testing offers several advantages, such as unbiased testing and detection of different defects. However, a drawback is that an independent test team may be isolated from the development team and project team. This can lead to communication gaps, reduced collaboration, and a lack of understanding of the project context.

According to the ISTQB Certified Tester Foundation Level (CTFL) syllabus v4.0, an independent test team may not have the same level of understanding of the system as the development team, leading to potential issues in communication and integration​ (ISTQB not-for-profit association)​.

The statement "Early and frequent feedback helps to avoid requirements misunderstanding" is true. Early feedback from stakeholders, through reviews and other static testing techniques, helps clarify requirements and ensures that any misunderstandings are addressed promptly. This practice aligns with Agile principles and contributes to developing software that meets user needs more accurately.

A unit test framework tool is a tool that supports the creation, execution, and reporting of unit tests, which are tests that verify the functionality and quality of individual software components (such as functions or methods) in source code. A unit test framework tool can help to detect defects in functions or methods in source code by providing features such as test case generation, test case execution, test result comparison, test coverage measurement, etc. Some examples of unit test framework tools are JUnit, NUnit, TestNG, etc. The other options are not tools that are likely to detect defects in functions or methods in source code. A configuration management tool is a tool that supports the management and control of different versions and variants of software products or components. A test design tool is a tool that supports the design and generation of test cases based on some criteria or rules. A monitoring tool is a tool that monitors the behavior or performance of a system or component under test. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 10.

In formal reviews, the scribe's role is to collate potential defects and other findings during the review process. This position is crucial as it ensures all observations and defects are recorded accurately, facilitating efficient analysis and resolution of issues identified during the review.

A correct list of boundary values for the P input should include the minimum and maximum values of the valid range (15 and 350), as well as the values just below and above the boundaries (14 and 351). Boundary value analysis is a test design technique that involves testing the values at or near the boundaries of an input domain or output range, as these values are more likely to cause errors than values in the middle. Option B satisfies this condition, as it has all four boundary values (14, 15, 350, 351). Option A has only two boundary values (14 and 351), option C has only two boundary values (15 and 350), and option D has no boundary values at all. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 34.

This answer is correct because configuration management is a process of establishing and maintaining consistency of a product’s performance, functional, and physical attributes with its requirements, design, and operational information throughout its life. Configuration management helps ensure that all relevant project documentation and software items are uniquely identified in all their versions and therefore can be unambiguously referenced in test documentation. This supports testing by providing traceability, consistency, and control over the test artifacts and the software under test. References: : ISTQB Glossary of Testing Terms v4.0, : ISTQB Foundation Level Syllabus v4.0, Section 2.2.2.2

This answer is correct because the whole-team approach is a way of working in agile projects where all team members share the responsibility for the quality of the product, and collaborate on delivering value to the customer. The whole-team approach involves testers, developers, business analysts, product owners, and other stakeholders in planning, designing, developing, testing, and delivering the product. The whole-team approach fosters communication, feedback, learning, and continuous improvement within the team. References: ISTQB Glossary of Testing Terms v4.0, ISTQB Foundation Level Syllabus v4.0, Section 3.1.1.1

Good testing practice dictates that each test level (e.g., unit testing, integration testing, system testing) should have distinct test objectives aligned with the phase of the software development lifecycle it addresses. This ensures that testing is effective and relevant at each stage. According to the ISTQB CTFL Syllabus v4.0, establishing clear test objectives that are consistent with the development phase helps in achieving specific goals and improving the overall quality of the software product​​.

Covering all transitions at least once is the highest coverage criterion for state transition based test cases, because it ensures that every possible change of state is tested at least once. This means that all the events that trigger the transitions, as well as the actions and outputs that result from the transitions, are verified. Covering all transitions at least once also implies covering all states at least once, but not vice versa. Therefore, option D is not the highest coverage criterion. Option C is the lowest coverage criterion, because it only tests the initial and final states of the system or component, without checking the intermediate states or transitions. Option A is incorrect, because the coverage criteria for state transition based test cases can be determined and compared based on the number of transitions and states covered. References = CTFL 4.0 Syllabus, Section 4.2.3, page 49-50.

The question is about selecting the correct test values for x based on equivalence partitioning. Equivalence partitioning is a software test design technique that divides the input data of a software unit into partitions of equivalent data from which test cases can be derived. In this case, the given equivalence classes are:

(x \leq -100)

(-100 < x < 100)

(100 \leq x < 1000)

(x \geq 1000)

Option D provides a value from each of these partitions:

For (x \leq -100), it gives -1000.

For (-100 < x < 100), it gives -100 and 100.

For (100 \leq x < 1000), it gives 500.

For (x \geq 1000), it gives 1500.

So, option D covers all four given equivalence classes with appropriate values.

Effort estimate does not depend on the budget of the project, but rather on the scope, complexity, and quality of the software product and the testing activities1. Budget is a constraint that may affect the feasibility and accuracy of the effort estimate, but it is not a factor that determines the effort estimate. Effort estimate is the amount of work required to complete the testing activities, measured in terms of person-hours, person-days, or person-months2.

The other options are correct because:

A. Once the test effort is estimated, resources can be identified and a schedule can be drawn up, as they are interrelated aspects of the test planning process3. Resources are the people, tools, equipment, and facilities needed to perform the testing activities4. Schedule is the time frame and sequence of the testing activities, aligned with the project milestones and deadlines5.

B. Effort estimate can be inaccurate because the quality of the product under tests is not known, as it affects the number and severity of the defects that may be found and the rework that may be needed to fix them6. Quality is the degree to which the software product satisfies the specified requirements and meets the needs and expectations of the users and clients7.

D. Experience based estimation is one of the estimation techniques, which relies on the judgment and expertise of the testers and other project stakeholders to estimate the test effort based on similar projects or tasks done in the past. Experience based estimation can be useful when there is a lack of historical data, formal methods, or detailed information about the software product and the testing activities.

References =

1 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 154

2 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 155

3 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 156

4 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 157

5 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 158

6 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 159

7 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 16

[8] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 160

[9] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 161

The features of the test object to be tested and those excluded from the testing represent information that is usually included in a test plan and, in the given test plan, it is more likely to be specified within “Test Scope” rather than in the other two sections mentioned. The test scope defines the boundaries and limitations of the testing activities, such as the test items, the features to be tested, the features not to be tested, the test objectives, the test environment, the test resources, the test assumptions, the test risks, etc. The test scope helps to establish a common understanding of what is included and excluded from the testing, and to avoid ambiguity, confusion, or misunderstanding among the stakeholders. The other two sections, “Testing Communication” and “Stakeholders”, are also important parts of a test plan, but they do not directly address the features of the test object. The testing communication describes the methods, frequency, and responsibilities for the communication and reporting of the testing progress, status, issues, and results. The stakeholders identify the roles and responsibilities of the people involved in or affected by the testing activities, such as the test manager, the test team, the project manager, the developers, the customers, the users, etc. References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.1, Test Planning1

ISTQB® Glossary of Testing Terms v4.0, Test Plan, Test Scope2

The following statements about reviews are true:

I) In walkthroughs the review meeting is typically led by the author. A walkthrough is a type of review that has a predefined objective and agenda but no formal process or roles. A walkthrough is typically led by the author of the work product under review, who guides the participants through a scenario and solicits feedback.

IV) Management rarely participates in technical review meetings. A technical review is a type of review that has a predefined objective and agenda but no formal process or roles. A technical review is typically performed by peers with technical expertise in order to evaluate technical aspects of a work product. Management rarely participates in technical review meetings, as they may not have sufficient technical knowledge or skills to contribute effectively. The following statements about reviews are false:

II) Inspection is characterized by an open-ended review meeting. An inspection is a type of review that follows a defined process with formal entry and exit criteria and roles and responsibilities for participants. An inspection is characterized by a structured review meeting with a fixed duration and agenda.

III) Preparation before the review meeting is part of informal reviews. Preparation before the review meeting is part of formal reviews, such as inspections or technical reviews. Preparation involves checking

A correct list of boundary values for the P input should include the minimum and maximum values of the valid range (15 and 350), as well as the values just below and above the boundaries (14 and 351). Boundary value analysis is a test design technique that involves testing the values at or near the boundaries of an input domain or output range, as these values are more likely to cause errors than values in the middle. Option B satisfies this condition, as it has all four boundary values (14, 15, 350, 351). Option A has two values from the same equivalence class (1000 and 99999), option C has two values outside the range (999 and 100000), and option D has no boundary values at all. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 34.

In the context of agile (iterative-incremental) development models, testing is integrated into the development process and occurs continuously throughout the lifecycle of the project. Agile testing emphasizes adaptability and the need for feedback at various stages of development.

Option C is correct because regression testing is indeed necessary whenever a new increment is added to the existing system. Agile development often involves frequent changes and additions to the codebase, which can potentially introduce new defects into previously tested code. Regression testing ensures that new changes have not adversely affected existing functionality.

Options A, B, and D present misconceptions about agile testing:

A is incorrect because, in agile, all types of testing (unit, integration, system, acceptance) are important and occur throughout the iteration, not just unit and acceptance tests.

B is incorrect because agile methodologies advocate for continuous integration and testing, where development and testing activities overlap and support each other throughout an iteration.

D is incorrect because agile methodologies encourage a wide range of testing types, including both functional and non-functional, as well as exploratory testing, to ensure a comprehensive quality assessment.

The acceptance criteria associated with a user story are the conditions that must be met for the user story to be considered done and to deliver the expected value to the user. They are often written in different formats, such as rule-oriented, scenario-oriented, or table-oriented, depending on the nature and complexity of the user story. They represent an aspect of a user story referred to as confirmation, which is one of the so called “3 C’s” of user stories. The other two aspects are card and conversation. Card refers to the concise and informal description of the user story, usually following the template: “As a [role], I want [feature], so that I can [benefit]”. Conversation refers to the ongoing dialogue between the stakeholders and the team members to clarify and refine the user story and its acceptance criteria. Therefore, option C is the correct answer.

Equivalence partitioning is a black-box test design technique where inputs to the software or system are divided into groups that are expected to exhibit similar behavior. For an integer field that should accept values from 1 to 15, the valid equivalence class is 1 through 15. The invalid equivalence classes are numbers less than 1 and numbers more than 15. Therefore, option D, "Less than 1, 1 through 15, more than 15," correctly identifies the valid equivalence class along with the two invalid classes, covering all possible input scenarios for the field. Options A, B, and C either do not accurately capture the valid range or incorrectly specify the range boundaries.

According to the ISTQB Certified Tester Foundation Level (CTFL) v4.0, the life cycle of a defect typically follows a sequence from its discovery to its closure. In the provided figure, it starts with S0 (New), moves to S1 (Assigned), then to S2 (Resolved), followed by S3 (Verified). If the defect is not fixed, it can be Re-opened (S5) and goes back for verification (S3). Once verified, it is Closed (S4). References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Section 1.4.3, Page 17.

Decision coverage, also known as branch coverage, is measured as the number of decision outcomes executed by the tests divided by the total number of decision outcomes in the test object. It ensures that every possible branch (true/false) decision in the code has been executed at least once.

A technical review is a type of formal review that involves a team of technical experts who evaluate a software product against a set of predefined quality criteria. A technical review is suitable for ensuring high quality and technical correctness of complex or critical software components, such as algorithms, architectures or designs. A technical review is not a walkthrough, which is an informal review led by the author of the work product. A technical review is not an informal review, which is a review that does not follow a defined process and has no formal entry or exit criteria. A technical review is not a management review, which is a type of formal review that focuses on business aspects and project progress. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, Chapter 3, page 29-30.

Comprehensive and Detailed In-Depth Explanation:

Equivalence partitioning (EP) divides input values into classes where test cases represent all possible values of each partition. The partitions in this scenario are:

≤7 (too cold → W)

8-21 (standstill → X)

22-29 (ideal → Y)

≥30 (too hot → Z)

Option C ({7,10,25,29}) covers all partitions by selecting representative values:

7 → Too cold (W)

10 → Standstill (X)

25 → Ideal (Y)

29 → Upper boundary of ideal (Y)

Other options do not cover all partitions adequately.

A test task that usually occurs during test implementation is to make sure the planned test environment is ready to be delivered. The test environment is the hardware and software configuration on which the tests are executed, and it should be as close as possible to the production environment where the software system will operate. The test environment should be planned, prepared, and verified before the test execution, to ensure that the test conditions, the test data, the test tools, and the test interfaces are available and functional. The other options are not test tasks that usually occur during test implementation, but rather test tasks that occur during other test activities, such as:

Find, analyze, and remove the causes of the failures highlighted by the tests: This is a test task that usually occurs during test analysis and design, which is the activity of analyzing the test basis, designing the test cases, and identifying the test data. During this activity, the testers can use techniques such as root cause analysis, defect prevention, or defect analysis, to find, analyze, and remove the causes of the failures highlighted by the previous tests, and to prevent or reduce the occurrence of similar failures in the future tests.

Archive the testware for use in future test projects: This is a test task that usually occurs during test closure, which is the activity of finalizing and reporting the test results, evaluating the test process, and identifying the test improvement actions. During this activity, the testers can archive the testware, which are the test artifacts produced during the testing process, such as the test plan, the test cases, the test data, the test results, the defect reports, etc., for use in future test projects, such as regression testing, maintenance testing, or reuse testing.

Gather the metrics that are used to guide the test project: This is a test task that usually occurs during test monitoring and control, which is the activity of tracking and reviewing the test progress, status, and quality, and taking corrective actions when necessary. During this activity, the testers can gather the metrics, which are the measurements of the testing process, such as the test coverage, the defect density, the test effort, the test duration, etc., that are used to guide the test project, such as planning, estimating, scheduling, reporting, or improving the testing process. References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.1, Test Planning1

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.2, Test Monitoring and Control1

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.3, Test Analysis and Design1

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.4, Test Implementation1

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.5, Test Execution1

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.6, Test Closure1

ISTQB® Glossary of Testing Terms v4.0, Test Environment, Test Condition, Test Data, Test Tool, Test Interface, Failure, Root Cause Analysis, Defect Prevention, Defect Analysis, Testware, Regression Testing, Maintenance Testing, Reuse Testing, Test Coverage, Defect Density, Test Effort, Test Duration2

Applicable acceptance test cases for the given user story should focus on the specific requirement of deleting an individual item from the shopping list and ensuring that it is removed in less than 1 second. Therefore, the valid test cases are: i. Click on my online shopping list, select the unwanted item, delete the unwanted item, the unwanted item is deleted from the shopping list in less than 1 second. iii. Tab to the online shopping list and press enter, select the unwanted item, delete the unwanted item, the unwanted item is deleted from the shopping list in less than 1 second.

Statement Testing is a type of white-box testing technique where the test cases are designed based on the implementation of the software, specifically aiming to execute every statement in the code at least once. This falls under the category of structure-based testing (also known as white-box testing), where the internal structure of the system is used to design test cases. Therefore, option D is correct​​.

This answer is correct because identifying potential anomalies in the work product under review is one of the tasks the Author is responsible for, as part of a typical formal review. The Author is the person who creates the work product to be reviewed, such as a requirement specification, a design document, or a test case. The Author’s tasks include preparing the work product for the review, identifying potential anomalies in the work product, and fixing the anomalies found in the work product after the review. References: ISTQB Glossary of Testing Terms v4.0, ISTQB Foundation Level Syllabus v4.0, Section 2.4.2.1

In an incident report, essential details provide context and facilitate the investigation and resolution of the incident. The missing elements in the given incident report are:

I. Identification or configuration of the application: This detail is crucial as it specifies which version or configuration of the application is affected, helping in reproducing the issue. IV. The actions and/or conditions that came before pressing the button: Understanding the sequence of actions leading to the issue is vital for replicating and diagnosing the problem.

The name of the developer (II) and the recommendation of the developer (III) are not typically included in an incident report as they do not contribute to identifying or resolving the incident. The focus is on the incident's details, reproduction steps, and the system's state rather than on personnel or proposed solutions at this stage. Therefore, option B, which includes both I and IV, is the correct answer.

Testing can contribute to higher quality by helping to measure the quality of software. Quality is defined as the degree to which a component or system satisfies specified requirements and customer or user needs and expectations. Testing is a process of evaluating a component or system by applying inputs and observing outputs, and comparing them with expected results. Testing can help to measure the quality of software by providing information on its functionality, performance, usability, security, reliability, etc. Testing can also help to identify and report defects in software, which can lead to improvement actions and quality assurance activities. The other options are not accurate descriptions of how testing can contribute to higher quality. Testing does not ensure that remaining defects are documented, but rather that detected defects are reported. Testing does not remove errors in software, but rather finds defects in software behavior or quality. Testing does not eliminate the risk with software, but rather assesses and manages the risk with software. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 3.

In maintenance testing, the relationship between impact analysis and regression testing is that the impact analysis is used to evaluate the amount of regression testing to be performed. Maintenance testing is a type of testing that is performed on an existing software product after it has been delivered or deployed, in order to ensure that it still meets its requirements and functions correctly after a change or a modification. Maintenance testing can be triggered by various reasons, such as corrective maintenance (fixing defects), adaptive maintenance (adapting to new environments), perfective maintenance (improving performance), preventive maintenance (avoiding future problems), etc. Impact analysis is a technique that is used to assess the extent and nature of changes introduced by maintenance activities on the software product or project. Impact analysis helps to identify which parts of the software product are affected by the changes, which parts need to be modified or updated accordingly, which parts need to be retested or verified for correctness or compatibility, etc. Regression testing is a type of testing that verifies that previously tested software still performs correctly after a change or a modification. Regression testing helps to detect any side effects or unintended consequences of maintenance activities on the software product’s functionality or quality. Regression testing can be performed at various levels and scopes depending on the impact analysis results. Therefore, in maintenance testing, impact analysis is used to evaluate the amount of regression testing to be performed. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 20.

The minimum number of test cases needed to cover every unique sequence of up to 3 states/2 transitions starting in the “Start” state and ending in the “End” state is 4. This is because there are 4 unique sequences of up to 3 states/2 transitions starting in the “Start” state and ending in the “End” state:

Start -> Bet -> End

Start -> Deal -> End

Start -> 1st Deal -> End

Start -> 2nd Deal -> End References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents.

Equivalence partitioning and boundary value analysis are test design techniques that are most appropriate for testing the login page of a web site. The page contains fields for user name and password, which are input values that can be divided into partitions of equivalent data. Equivalence partitioning is a technique that divides the input data and output results of a software component into partitions of equivalent data. Each partition should contain data that is treated in the same way by the component. Equivalence partitioning can be used to reduce the number of test cases by selecting one representative value from each partition. Boundary value analysis is a technique that tests boundary values between partitions of equivalent data. Boundary values are values at the edge of an equivalence partition or at the smallest incremental distance on either side of an edge. Boundary value analysis can be used to detect defects caused by incorrect handling of boundary conditions. For example, for testing the user name field, we can identify two equivalence partitions: valid user name (existing and correct) and invalid user name (non-existing or incorrect). The boundary values for these partitions are the minimum and maximum length of user name allowed by the system.

Decision table testing and state transition testing are not suitable for testing the login page of a web site, as they are more applicable for testing components that have multiple inputs and outputs that depend on logical combinations of conditions or events. Decision table testing is a technique that shows combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects). State transition testing is a technique that models how a system transitions from one state to another depending on events or conditions.

Exploratory testing and statement coverage are not suitable for testing the login page of a web site, as they are more applicable for testing components that require learning, creativity and intuition or structural analysis. Exploratory testing is an approach to testing that emphasizes learning, test design and test execution at the same time. Exploratory testing relies on the tester’s skills, creativity and intuition to explore the software under test and discover defects. Statement coverage is a type of structural testing that measures how many statements in a program have been executed by a test suite. Statement coverage can be used to assess the adequacy or completeness of a test suite.

Decision coverage and fault attack are not suitable for testing the login page of a web site, as they are more applicable for testing components that have complex logic or potential errors. Decision coverage is a type of structural testing that measures how many decision outcomes in a program have been executed by a test suite. Decision coverage can be used to assess the adequacy or completeness of a test suite. Fault attack is a type of functional testing that deliberately introduces faults into a system in order to provoke failures or errors. Verified References: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer], Chapter 4, page 34-46; Chapter 5, page 47-48.

An oracle is a mechanism or source that can provide the expected result for a given test input or situation. Sometimes old version of a product can be used as an oracle, if it is assumed that the old version behaves correctly for the test cases that are executed on the new version. This is also known as back-to-back testing. Oracles do not help in reproducing the irreproducible bugs, as they only provide the expected results, not the actual results. Oracles are not derived from the design, but from the requirements or specifications. Oracles cannot be generated automatically using data generators, as data generators only provide test inputs, not test outputs. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 9.

Testware is a term that refers to all artifacts produced during the testing process, such as test plans, test cases, test scripts, test data, test results, defect reports, etc. The following statements about testware are correct:

II) All the testware should be subject to Configuration Management. Configuration management is a process that establishes and maintains consistency among work products throughout their life cycle. Configuration management applies to all testware, as it helps ensure their quality and consistency, track their changes and defects, control their versions and access rights, and link them to other artifacts.

III) The testware at the end of the project should be transferred to the organization responsible for maintenance. Maintenance testing is testing performed on a software product after delivery to correct defects or improve performance or other attributes. Maintenance testing requires testware from previous testing activities or phases, such as test cases, test data, test results, etc. Therefore, the testware at the end of the project should be transferred to the organization responsible for maintenance testing, such as support team or maintenance team. The following statements about testware are incorrect:

I) When closing the test activities, all the testware resources can be uninstalled and released. This statement is incorrect, as some testware resources may still be needed for future testing activities or phases, such as maintenance testing or regression testing. Therefore, when closing the test activities, some testware resources should be archived and stored for future use, while others can be uninstalled and released.

IV) The developers are responsible for the correct installation of the testware. This statement is incorrect, as the testers are responsible for the correct installation of the testware. The testers should ensure that they have access to all necessary testware resources and that they are installed and configured properly before starting the test execution. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, Chapter 6, page 58-61.

A test status report is a document that provides a snapshot of the testing activities and their progress during a particular period. It should include information about any impediments encountered during the test execution and the actions taken to resolve them, which helps stakeholders understand the challenges and how they were addressed​​ .

Option B describes an activity related to test completion rather than ongoing status reporting. Option C is incorrect because the structure and contents of the report may vary based on the audience's needs. Option D, while important, is not the primary purpose of a test status report, which focuses more on the current status and impediments.

Comprehensive and Detailed In-Depth Explanation:

Static analysis requires access to work products like source code, models, or documentation, making it impossible to analyze Commercial off-the-shelf (COTS) software (A) because its source code is typically unavailable. Static analysis is applicable to source code (B), BPMN models (C), and UML diagrams (D).

Checklist-based testing involves using checklists that contain items, such as potential test conditions, that should be tested. These checklists are often based on insights into what is important to the user, potential areas where software might fail, and specific aspects that need to be tested. It provides a structured yet flexible approach to testing, ensuring key areas are covered while allowing testers to use their experience and understanding of the system. Checklist-based testing is not limited to non-functional testing but can be applied to various types of testing, including functional testing.

Defect clustering is a testing principle that states that a small number of modules contain most of the defects detected during pre-release testing, or are responsible for most of the operational failures. Defect clustering can be explained by Pareto’s principle (also known as the 80-20 rule), which states that approximately 80% of the problems are found in 20% of the modules. Defect clustering suggests a change to the current test strategy for the next test cycle, as it implies that more effort should be allocated to test the modules that have shown high defect density or criticality. Pesticide paradox is another testing principle that states that if the same tests are repeated over and over again, eventually they will no longer find any new defects. Pesticide paradox suggests a change to the current test strategy for the next test cycle, but not based on defect clustering, but rather on test diversity and coverage. Early testing is a testing principle that states that testing activities should start as early as possible in the software development life cycle and should be focused on defined objectives. Early testing does not suggest a change to the current test strategy for the next test cycle, but rather a proactive approach to prevent defects from occurring or propagating. Absence-of-errors fallacy is a testing principle that states that finding and fixing defects does not help if the system built is unusable and does not fulfill the users’ needs and expectations. Absence-of-errors fallacy does not suggest a change to the current test strategy for the next test cycle, but rather a focus on quality attributes and user requirements. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, Chapter 1, page 9-10.

Test exit criteria are the conditions or requirements that must be met before testing can be concluded. Test exit criteria are usually defined in the test plan and agreed by the stakeholders. Test exit criteria can be based on various factors, such as test coverage, defect status, quality level, risk level, etc. Test schedules would be the least likely to be used as the basis for test exit criteria, because test schedules are not directly related to the quality or performance of the software product, but rather to the time or resources allocated for testing. Test schedules can be used as the basis for test entry criteria, which are the conditions or requirements that must be met before testing can start. The other options are more likely to be used as the basis for test exit criteria. Cost of testing performed so far can be used as a basis for test exit criteria, because it can indicate the return on investment or the cost-benefit ratio of testing. Confidence of testers in tested code can be used as a basis for test exit criteria, because it can reflect the level of satisfaction or assurance of the testers about the quality or reliability of the software product. Number of unfixed defects can be used as a basis for test exit criteria, because it can indicate the level of risk or impact of the remaining defects on the software product. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 13.

The state transition diagram provided shows three distinct states:

Waiting for fingerprint

Waiting for PIN

Valid PIN/ask menu selection

Each state represents a different stage in the system's operation, with transitions based on user actions and system responses​​.

Non-functional testing refers to testing aspects that do not relate to specific behaviors or functions of the software but to attributes such as performance, usability, reliability, etc. Tests that capture the time it takes to save a file directly relate to the performance of the system, thus falling under non-functional testing.

Confirmation testing, also known as re-testing, is performed to verify that specific defects have been successfully fixed.

Option A: "Testing due to the application of a new version of the interface" would typically involve regression testing, not confirmation testing.

Option B: "Testing that fixes resolved the defects in the search function" fits the description of confirmation testing as it focuses on ensuring that specific issues have been addressed.

Option C: "Testing if a system still works after update of an operating system" is an example of regression testing, as it checks the overall system behavior after an update.

Option D: "Testing to ensure the adding of new functionalities haven't broken existing functions" is another example of re​ (ISTQB not-for-profit association)​​ (Udemy)​ it checks for unintended consequences of new changes.

Therefore, the correct answer is B【6†source】【9†source】.

In a planning poker session, if there is a significant difference in the estimations, it indicates that there may be misunderstandings or different perspectives on the complexity of the user story. According to the agile principles, the team should discuss these differences to reach a common understanding. The goal is to ensure that all team members have a shared understanding of the user story's scope and complexity before finalizing the estimate​​.

When developers are trying to identify and remove a defect, they need clear information on what went wrong and what was expected. The items that will be most useful to developers in this context are the expected results (item 1), the actual results (item 2), and a description of the defect including steps to reproduce, screenshots, and database dumps (item 5). This information helps developers understand the nature of the defect and provides the necessary details to reproduce and diagnose the issue effectively.

The following statements about re-testing and regression testing are true:

I) Re-testing should be performed after a defect is fixed. Re-testing is a type of testing that verifies that a defect has been successfully resolved by executing a test case that previously failed due to that defect. Re-testing should be performed after a defect is fixed and delivered to ensure that it does not cause any new failures or side effects.

III) Re-testing and regression testing may be performed at any test level. Re-testing and regression testing are not limited to a specific test level, but can be applied at any level depending on the context and objectives. For example, re-testing and regression testing can be performed at unit level, integration level, system level or acceptance level.

IV) Regression testing may include functional, non-functional and structural testing. Regression testing is a type of testing that verifies that previously tested software still performs correctly after changes. Regression testing may include various types of testing depending on the scope and purpose of the changes. For example, regression testing may include functional testing to check if the software meets its requirements, non-functional testing to check if the software meets its quality attributes, or structural testing to check if the software meets its design or code standards. The following statement about re-testing and regression testing is false:

II) Regression testing should always be performed after a defect is fixed. Regression testing is not always necessary after a defect is fixed, as some defects may have a low impact or low likelihood of affecting other parts of the software. Regression testing should be performed after a defect is fixed only if there is a risk of introducing new defects or causing existing defects due to the changes made to fix the defect. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, Chapter 2, page 19; Chapter 4, page 45.

Comprehensive and Detailed In-Depth Explanation:

Boundary Value Analysis (BVA) focuses on test cases at the edges of partitions because defects often occur at boundaries. The temperature ranges are:

≤7 (Too cold → W)

[8-21] (Standstill → X)

[22-29] (Ideal → Y)

≥30 (Too hot → Z)

A two-point BVA means testing both the lower and upper boundary values of each partition.

The correct selection {7,8,21,22,29,30} includes:

7 → Boundary of Too Cold (W)

8 → Lower boundary of Standstill (X)

21 → Upper boundary of Standstill (X)

22 → Lower boundary of Ideal (Y)

29 → Upper boundary of Ideal (Y)

30 → Lower boundary of Too Hot (Z)

This ensures maximum boundary coverage.

Experience-based testing techniques leverage the tester's intuition and prior experience to identify defects that systematic techniques might miss. These techniques are valuable because they can uncover issues based on real-world usage and scenarios that aren't always covered by more formalized black-box and white-box methods. The ISTQB CTFL Syllabus v4.0 highlights the complementary nature of experience-based techniques in providing a broader defect detection strategy​​.

Comprehensive and Detailed In-Depth Explanation:

Configuration management (B) ensures that versions of software and test artifacts are properly tracked, stored, and retrievable. It allows teams to:

Restore earlier versions of software and test work products

Maintain traceability between requirements, tests, and code

Avoid discrepancies due to mismanaged versions

(A) is incorrect because defect management tracks issues but does not restore versions.

(C) is incorrect because change management controls changes but does not track past versions.

(D) is incorrect because risk management assesses risks but does not manage software versions.

Effective configuration management ensures the ability to roll back changes and maintain system stability.

A valid criticism of this report is that the version of the application is missing. The version of the application is an important piece of information that should be included in a defect report, as it helps to identify which release or build of the software product contains the defect. The version of the application can also help to reproduce and debug the defect, as different versions may have different behaviors or features. The other options are not valid criticisms of this report. The priority, the correction description and the developer name are not missing, but rather not applicable for this report. The priority is a measure of how urgently a defect needs to be fixed, which can be assigned by the project manager or the defect tracking system, not by the tester who reports the defect. The correction description and the developer name are information that are added after the defect has been resolved, not when it has been reported. There is no link to the applicable requirement (traceability) is not a valid criticism of this report, because traceability is not a mandatory attribute of a defect report, but rather an optional one. Traceability is a relationship between two or more entities (such as requirements, test cases, defects, etc.) that shows how they are related or dependent on each other. Traceability can help to verify that the requirements are met by the test cases and defects, but it is not essential for reporting a defect. The description is not highlighting the source of the problem is not a valid criticism of this report, because highlighting the source of the problem is not a responsibility of the tester who reports the defect, but rather of the developer who fixes the defect. The description should provide enough information to describe what happened when the defect occurred, such as input values, expected results, actual results, error messages, screenshots, etc., but it does not need to explain why or how it happened. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 140.

The unscripted tests produced by the tester’s experience during the two-hour test session belong to the testing quadrant Q3. The testing quadrants are a classification of testing types based on two dimensions: the test objectives (whether the testing is focused on supporting the team or critiquing the product) and the test basis (whether the testing is based on the technology or the business). The testing quadrants are labeled as Q1, Q2, Q3, and Q4, and each quadrant represents a different testing perspective, such as unit testing, acceptance testing, usability testing, or performance testing. The testing quadrant Q3 corresponds to the testing types that have the objective of critiquing the product from the business perspective, such as exploratory testing, usability testing, user acceptance testing, alpha testing, beta testing, etc. The unscripted tests performed by the tester in the given scenario are examples of exploratory testing and usability testing, as they are based on the tester’s experience, intuition, and learning of the web application, and they focus on some specific usability issues, such as the user interface, the user satisfaction, the user feedback, etc. The other options are incorrect, because:

The testing quadrant Q1 corresponds to the testing types that have the objective of supporting the team from the technology perspective, such as unit testing, component testing, integration testing, system testing, etc. These testing types are usually performed by developers or testers who have access to the source code, the design, the architecture, or the configuration of the software system, and they aim to verify the functionality, the quality, and the reliability of the software system at different levels of integration.

The testing quadrant Q2 corresponds to the testing types that have the objective of supporting the team from the business perspective, such as functional testing, acceptance testing, story testing, scenario testing, etc. These testing types are usually performed by testers or customers who have access to the requirements, the specifications, the user stories, or the business processes of the software system, and they aim to validate that the software system meets the expectations and the needs of the users and the stakeholders.

The testing quadrant Q4 corresponds to the testing types that have the objective of critiquing the product from the technology perspective, such as performance testing, security testing, reliability testing, compatibility testing, etc. These testing types are usually performed by testers or specialists who have access to the tools, the metrics, the standards, or the benchmarks of the software system, and they aim to evaluate the non-functional aspects of the software system, such as the efficiency, the security, the reliability, or the compatibility of the software system under different conditions or environments. References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 1.3.1, Testing in Software Development Lifecycles

ISTQB® Glossary of Testing Terms v4.0, Testing Quadrant, Exploratory Testing, Usability Testing, Unit Testing, Component Testing, Integration Testing, System Testing, Functional Testing, Acceptance Testing, Story Testing, Scenario Testing, Performance Testing, Security Testing, Reliability Testing, Compatibility Testing

Test automation provides numerous benefits to software testing, and one of the key advantages is the reduction of repetitive manual work. This benefit is explicitly covered in the ISTQB Foundation Level Syllabus (v4.0).

Test automation allows testers to automate repetitive tasks such as regression testing, freeing up their time to focus on more complex and exploratory testing. This leads to improved efficiency and helps in avoiding human errors associated with repetitive tasks.

Option A: "More subjective assessment" contradicts the benefit of automation as it focuses on objectivity.

Option C: "Availability of the test automation tool vendor" is not a direct benefit of test automation, although vendor support can be valuable.

Option D: "Negligible effort to maintain the test assets" is misleading as maintaining automated tests often requires effort and attention to changes in the system under test.

Therefore, the correct answer is B​ (ISTQB not-for-profit association)​​ (ISTQB)​.

This answer is correct because equivalence partitioning is a test design technique that divides the input domain of a system or component into partitions of equivalent data, such that each partition is expected to produce the same output or behavior. Equivalence partitioning aims to reduce the number of test cases by selecting one representative value from each partition. In this case, the input domain of the TAS can be divided into four partitions based on the bonus rules: less than 50k€, between 50k€ and 80k€, between 80k€ and 120k€, and more than 120k€. The test cases in the answer belong to the same partition, which is between 80k€ and 120k€, and they are expected to produce the same output, which is a bonus of 15%. References: ISTQB Glossary of Testing Terms v4.0, ISTQB Foundation Level Syllabus v4.0, Section 2.3.2.1

The critical information missing from the defect report is a detailed description of the defect to enable reproduction. A clear and concise description of the steps taken to reproduce the defect is essential for developers to understand the context and to be able to replicate the issue in their environment. Without this information, it can be challenging to diagnose and fix the defect. The ISTQB CTFL syllabus emphasizes the importance of providing all necessary details in a defect report to facilitate effective communication and resolution.

Comprehensive and Detailed In-Depth Explanation:

The primary objectives of testing, as outlined in the ISTQB CTFL v4.0 syllabus, include verifying whether specified requirements are met (A), detecting failures and defects (B), and validating that the test object functions as expected (D). However, "finding errors" (C) is not a direct objective. Errors result from human mistakes, but testing primarily identifies defects, which are flaws in the system that cause failures. Testing aims to reveal defects rather than directly identify errors in the code.

The correct outcome of a two-value boundary value analysis applied to the password length is the set of test cases represented by option D. Boundary value analysis is a test design technique that focuses on the values at the boundaries of an equivalence partition, such as the minimum and maximum values, or the values just above and below the boundaries. A two-value boundary value analysis uses two values for each boundary, one representing the valid value and one representing the invalid value. For example, if the valid range of values is from 4 to 7, then the two values for the lower boundary are 3 and 4, and the two values for the upper boundary are 7 and 8. The test cases in option D use these values for the password length, while also satisfying the other requirements of the password, such as containing at least one numeric character, one capital letter, and one lowercase letter. The test cases in option D are:

1RhT: a 4-character password that is valid

rSp53: a 5-character password that is valid

3N3e10: a 6-character password that is valid

8sBdby: an 8-character password that is invalid The test cases in the other options are incorrect, because they either use values that are not at the boundaries of the password length, or they do not meet the other requirements of the password. For example, the test cases in option A are:

1xA: a 3-character password that is invalid, but it does not contain a capital letter

aB11: a 4-character password that is valid

Pq1ZZab: a 7-character password that is valid

7iDD0a1x: an 8-character password that is invalid References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.2.1, Black-box Test Design Techniques1

ISTQB® Glossary of Testing Terms v4.0, Boundary Value Analysis, Equivalence Partition2

The question is about marking the correct sentences among the given statements related to defects, failures, and mistakes. According to the ISTQB glossary, the definitions of these terms are1:

Defect: A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system.

Failure: An event in which a component or system does not perform a required function within specified limits.

Mistake: A human action that produces an incorrect result.

Therefore, out of the five given statements, only two are correct, namely:

A human mistake may produce a defect: This is true, as a mistake is a source or cause of a defect, e.g. a programmer may make a mistake in writing a code statement, which results in a defect in the software component.

When a defect exists in a system it may result in a failure: This is true, as a defect is a potential or actual cause of a failure, e.g. a defect in the software component may cause the system to fail to perform a required function when the defect is encountered during execution.

The other three statements are incorrect, namely:

Defects are a result of environmental conditions and are also referred to as “Failures”: This is false, as defects are not a result of environmental conditions, but of mistakes or other factors, and defects are not the same as failures, but rather the causes of failures.

A system will totally fail to operate correctly when a failure exists in it: This is false, as a system may not necessarily fail completely or stop operating when a failure occurs, but may continue to operate with reduced functionality or performance, or with incorrect results.

Defects occur only as a result of technology changes: This is false, as defects can occur due to various reasons, not only technology changes, such as human mistakes, design flaws, requirement changes, hardware failures, etc.

Test-Driven Development (TDD) emphasizes writing tests before code and includes refactoring as a key practice to improve both the tests and the code. This ensures that the codebase remains clean and maintainable. The ISTQB CTFL Syllabus v4.0 discusses TDD as a practice that includes writing tests first, coding to satisfy those tests, and then refactoring the code to improve its structure and readability while keeping the tests intact​​.

A key skill for testers is the ability to use various tools to automate repetitive tasks, enhancing the efficiency and effectiveness of testing processes. This includes tools for test execution, test management, and defect tracking. The ISTQB CTFL Syllabus v4.0 emphasizes the importance of using tools to improve productivity and reduce manual effort in repetitive testing tasks, making this a critical skill for testers​​.

A static analysis tool is best suited for determining source code compliance with coding standards. These tools analyze the code without executing it and can check for adherence to coding standards, syntax errors, and other static properties of the code. The ISTQB CTFL syllabus emphasizes the role of static analysis tools in verifying that code meets predefined standards and guidelines.

Comprehensive and Detailed In-Depth Explanation:

Maintenance testing is carried out whenever changes are made to an existing system, including enhancements, defect fixes, and system migrations (C). It is not limited to adaptive maintenance (A) and is needed even when no defects are reported (B). Test cases are essential to validate fixes and prevent regressions (D).

Comprehensive and Detailed In-Depth Explanation:

A test plan is a management document that outlines the scope, objectives, schedule, resources, and risks of the testing process. The budget and schedule (A) are essential components as they help plan resources and timeline constraints.

(B) is incorrect because defect analysis is part of the test summary report, not the test plan.

(C) is incorrect because final reports summarize execution, while the test plan is created before testing starts.

(D) is incorrect because test logs are execution artifacts rather than planning elements.

A test plan guides testing activities and ensures alignment with project objectives.

Risk management is a process that identifies, analyzes, evaluates and mitigates risks in a software project. Risks are factors that may negatively affect the quality, schedule, budget or scope of a software project. The main goals of risk management in a software project are to reduce the probability of undesired situations and to reduce the effect of potential impact. This can be achieved by applying various strategies, such as avoidance, transfer, reduction or acceptance. Risk management does not aim to increase the success probability for the project regardless of costs, as this may not be feasible or realistic. Risk management does not aim to increase focus on preventative processes and to increase satisfaction for the testers, as these are secondary or indirect outcomes. Risk management does not aim to control contractual problems and minimize the impacts of company policies, as these are specific types of risks that may not apply to all projects. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, Chapter 2, page 14-15.

A test progress report is prepared during a test activity and provides updates on the current status of testing activities, including progress made, issues encountered, and test metrics. A test summary report, on the other hand, is prepared at the end of a test activity and provides a comprehensive overview of the testing carried out, including the final status, test results, defect summaries, and overall conclusions.

Comprehensive and Detailed In-Depth Explanation:

Exhaustive testing (testing all input combinations) is practically impossible except in trivial cases (C). Instead, testers focus on risk-based, prioritized, and efficient test techniques. The seven principles of testing in the ISTQB syllabus highlight that exhaustive testing is infeasible, and therefore, techniques such as equivalence partitioning, boundary value analysis, and risk-based testing are used to optimize test coverage.

A product risk is a risk that affects the quality or timeliness of the software product being developed or tested1. Product risks are related to the requirements, design, implementation, verification, and maintenance of the software product2.

The risk of the sub-contractor failing to meet his commitment is a product risk, as it could cause a delay in the completion of the testing required for the current cycle, which in turn could affect the release date of the product. The release date is an important aspect of the product quality, as it reflects the customer satisfaction and the market competitiveness of the product3.

The other options are not correct because:

A. It is not true that any risk associated with development timeline is a product risk. Some risks could be project risks, which are risks that affect the management or control of the software project, such as budget, resources, schedule, or communication1. For example, a risk of losing a key project stakeholder is a project risk, not a product risk.

B. It is not true that the risk is no longer a risk for the Test Manager since an independent party is managing it. The Test Manager is still responsible for ensuring that the testing activities are completed according to the test plan and the quality objectives4. The Test Manager should monitor and control the sub-contractor’s performance and communicate with him regularly to identify and mitigate any potential issues or deviations5.

C. It is not clear what is meant by “object” in this option, but it could be interpreted as the software system under test or the test object6. In any case, the risk is not an object risk, as it does not affect the successful completion of the object, but rather the successful completion of the testing of the object. An object risk could be a risk that affects the functionality, reliability, usability, efficiency, maintainability, or portability of the software system under test2. For example, a risk of the software system having a high complexity or a low testability is an object risk, not a product risk.

References =

1 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 97

2 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 98

3 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 99

4 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 100

5 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 101

6 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 102

Comprehensive and Detailed In-Depth Explanation:

Exploratory testing is an unscripted approach where testers actively design and execute tests based on their intuition, experience, and knowledge of the system. A test charter (A) provides a guideline on what areas to explore, defining test objectives but leaving room for dynamic adaptation.

(B), (C), and (D) contradict exploratory testing principles, which focus on freedom rather than rigid documentation.

Exploratory testing is especially useful in agile environments, usability testing, and uncovering unexpected defects.

A formal review is a type of review that follows a defined process with formal entry and exit criteria and roles and responsibilities for participants. A formal review can have various roles involved, such as manager, moderator, author, reviewer and scribe. The manager responsibilities in formal review include all except one of the following:

Planning the review (correct responsibility)

Determines if the review objectives have been met (incorrect responsibility)

Decide on the execution of reviews (correct responsibility)

Allocate time for review (correct responsibility) The responsibility of determining if the review objectives have been met belongs to the moderator role, not to the manager role. Verified References: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer], Chapter 3, page 28-29.

In Agile development, an informal review, often referred to as a "buddy check," is a common review type. Informal reviews are unstructured and involve a pair of colleagues reviewing each other’s work to identify defects early and provide immediate feedback. This type of review is less formal than inspections or walkthroughs and is particularly suitable for Agile environments where rapid feedback and flexibility are essential.