Free ISTQB-CTFL-FOUNDATION Practice Test

The principle of "early testing" is a fundamental concept in software testing that applies universally, regardless of the software development lifecycle model. Involving testers in the review of work products, such as requirements and design documents, as early as possible helps to identify defects before code is even written. Finding and fixing defects at this early stage is significantly cheaper and more efficient than finding them later in the development cycle. This practice improves the quality of the work products and prevents defect propagation into the final product.

A. Writing executable tests before code is a practice specific to methodologies like Test-Driven Development (TDD), which is not applied in all models.
B. A strict sequential handoff between test levels, where one's exit criteria feed the next's entry criteria, is characteristic of sequential models, not all models.
C. Test objectives are distinct for each test level (e.g., component testing focuses on code units, while system testing focuses on end-to-end behavior).

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Section 1.1.3, Testing Principle 1, "Testing activities should start as early as possible in the software development lifecycle... Early testing... helps to reduce the cost of changes".

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Section 3.2.2, "Testers can contribute significantly to reviews... by bringing a testing perspective... This early involvement... is a key factor for the success of the project".

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Section 2.2.1, describes how test objectives differ across test levels.

In a risk‐based selection, every test case with “very high” priority must appear in the schedule together with every test it depends on. TC01 and TC02 are very-high; TC02 depends on TC01, TC03 depends on TC02, and TC04 depends on TC03, so TC01-TC04 must stay. TC05 and TC06 have only medium/low priority and are not predecessors of any very-high-priority test, therefore they can be dropped. Removing only TC05 and TC06 yields the smallest executable set that still satisfies both the priority rule and every stated dependency.

A. Deleting TC04 breaks the dependency chain that TC03 (and therefore TC02) needs.
C. TC04 is a required predecessor; deleting it violates dependencies.
D. TC03 is a required predecessor for TC04/TC02; deleting it invalidates the chain.

1. ISTQB® Certified Tester Foundation Level Syllabus v4.0, Sect. 4.2 “Planning and Prioritizing Tests”, pp. 86-88.

2. ISTQB® CTFL Glossary v3.4, definition of “dependency” and “risk-based testing”, pp. 13, 29.

The testing quadrants model, developed by Brian Marick and promoted by Lisa Crispin and Janet Gregory, is a heuristic tool used primarily in Agile contexts. It categorizes different types of tests across four quadrants to help teams plan and ensure comprehensive test coverage. The model's axes (business-facing vs. technology-facing and supporting the team vs. critiquing the product) provide a clear framework for differentiating tests. This categorization is highly effective for communicating the testing strategy and the purpose of various test types to all stakeholders, including non-technical ones.

B. The testing quadrants model is associated with Agile development, not the V-model. It does not map test types to V-model test levels.
C. The model's axes are typically "Business Facing vs. Technology Facing" and "Supporting the Team vs. Critiquing the Product," not "business-oriented vs. product-oriented."
D. The model encourages performing tests from all four quadrants throughout the project lifecycle, not assigning a single quadrant to a specific iteration.

- ISTQB Certified Tester Foundation Level Syllabus V4.0, Section 2.1.2, Testing in the Context of a Development Lifecycle. The syllabus states, "The testing quadrants model... is a useful way to differentiate and describe types of tests."

Behavior-Driven Development (BDD) is an extension of Test-Driven Development (TDD) that emphasizes collaboration among developers, testers, and business stakeholders. It focuses on defining the desired behavior of a system from the user's perspective using a shared, understandable language. This collaborative approach ensures that all parties have a common understanding of the requirements before and during development, making option A the most accurate and comprehensive description of the BDD philosophy.

B. Using the Given-When-Then format is a key practice within BDD, but BDD itself is the overarching collaborative approach, not just the syntax.
C. This describes Test-Driven Development (TDD), where automated tests are written before the code they are meant to validate.
D. This is incorrect. BDD concerns the behavior of the software application, not the psychological behavior of the development team.

ISTQB® Certified Tester Foundation Level Syllabus V4.0, 2023. Section 2.2.3 Test-Driven Development and Behavior-Driven Development, p. 25. "BDD enhances TDD by writing test cases in a natural language that non-technical stakeholders can understand... BDD is a collaborative approach."

ISTQB® Glossary of Testing Terms V4.0, 2023. Definition for "behavior-driven development (BDD)", p. 7. "A collaborative test development approach..."

The statement "If new defects are to be found we should run the same test set more often" directly contradicts the "Pesticide paradox" testing principle. This principle states that if the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new defects. To overcome this, test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to find new defects.

A. This statement aligns with the "Defects cluster together" principle, which is a valid testing principle.
C. This statement aligns with the "Early testing saves time and money" principle, a valid testing principle.
D. This statement aligns with the "Testing is context dependent" principle, which is a valid testing principle.

ISTQB® Certified Tester Foundation Level Syllabus V4.0, 2023; Section 1.3, "Seven Testing Principles (K2)", Principle 6: Pesticide paradox, p. 12.

ISTQB® Glossary of Testing Terms v4.0, 2023; Entry for "pesticide paradox", p. 45.

Maintenance testing includes activities related to system retirement or decommissioning. In this scenario, there is a legal requirement to archive all documents. This necessitates a data migration from the operational system to a state archive. Testing this migration process is essential to ensure the data is transferred completely, accurately, and remains accessible for the required 20-year period. This activity falls under the scope of maintenance testing for system retirement.

A. Maintenance testing is required for system retirement, especially when data archiving or migration is involved, as stated in the syllabus.
C. Confirmation testing verifies that a specific defect has been fixed. Decommissioning is a planned lifecycle event, not a defect fix.
D. Regression testing checks for unintended side effects in unchanged parts of a system. Since the system is being retired, this is not the primary testing concern.

ISTQB® Certified Tester Foundation Level Syllabus V4.0, Section 2.3, page 23: "Triggers for maintenance testing include... Retirement of a system (e.g., decommissioning), which may require testing of data migration or archiving if long data-retention periods are required."

ISTQB® Glossary of Testing Terms v4.0, Definition of "maintenance testing": "Testing the changes to an operational system or the impact of a changed environment on an operational system."

Entry criteria are conditions that must be met before a testing phase can begin, while exit criteria are conditions that must be met before a testing phase can be considered complete.
- Entry Criteria: Items 2, 4, and 5 are prerequisites. Testing cannot start effectively until the tool is ready (2), the environment is available (4), and the requirements are testable (5).
- Exit Criteria: Items 1, 3, and 6 define the completion of testing. Testing is considered done when code coverage targets are met (1), the defect count is acceptably low (3), or the budget is exhausted (6).

B. This option incorrectly classifies code coverage (1) and defect limits (3) as entry criteria, and tool setup (2) and defined user stories (5) as exit criteria.
C. This option incorrectly classifies defined user stories (5) as an exit criterion; it is a prerequisite for starting testing (entry criterion).
D. This option incorrectly classifies the budget being spent (6) as an entry criterion; it is a condition for stopping testing (exit criterion).

ISTQB® Certified Tester Foundation Level Syllabus V4.0, 2023, Section 5.3.1, "Test Planning Activities". This section defines entry criteria as "conditions for officially starting a defined task" and exit criteria as "conditions for officially completing a defined task".

ISTQB® Glossary of Testing Terms v4.0, 2023. The definitions for "entry criteria" and "exit criteria" support this categorization of prerequisites versus completion conditions.

Testing's primary contribution to quality is providing information to stakeholders about the quality level of the software. By executing tests and finding defects, testing measures the current state of the product against its requirements. This measurement allows project stakeholders to make informed decisions, such as whether to release the software or to perform more development and testing to improve its quality. Testing identifies where the quality is low, which is the first step toward improving it.

B. Documenting remaining defects is a result of testing, but it's part of the broader activity of measuring and reporting on quality, making option A more fundamental.
C. Testing finds defects, but debugging is the activity that removes the underlying errors (faults) from the code. Testers do not typically fix the software.
D. Testing can identify and help manage risks by finding defects, but it cannot prove the absence of all defects and therefore cannot eliminate all risks.

ISTQB® Certified Tester Foundation Level Syllabus V4.0, Section 1.1.1, What is Testing?: "Testing can also measure the quality of software in terms of defects found, for characteristics such as reliability, security, or performance."

ISTQB® Certified Tester Foundation Level Syllabus V4.0, Section 1.1.2, Testing Objectives: A common objective is "Evaluating a work product to determine whether it satisfies specified requirements," which is a form of measurement.

ISTQB® Certified Tester Foundation Level Syllabus V4.0, Section 1.2.2, Testing and Debugging: "Testing and debugging are different. Executing tests can show failures that are caused by defects in the software. Debugging is the development activity that analyzes and removes the cause of the failure."

The ISTQB fundamental test process consists of several main activity groups. Option A correctly lists these groups, allowing for common combinations. The process includes: Test planning and monitoring/control; Test analysis and design; Test implementation and execution; and Test completion activities. The test completion phase is correctly broken down into its key components: "Evaluating exit criteria and reporting" and "Test closure activities." This option accurately reflects the structure and terminology of the fundamental test process as defined by ISTQB.

B. "Test implementation and control" is an incorrect grouping; control is a continuous activity that runs parallel to all other phases, not just implementation.
C. "Retesting and regression testing" are test types or activities performed during test execution, not distinct top-level phases of the fundamental test process.
D. "Test specification" is not a formal phase name in the ISTQB model, and "Retesting" is an activity within execution, not a separate phase.

ISTQB CTFL Syllabus v4.0, 2023, Section 1.3, The Fundamental Test Process. This section outlines the main test activities: Test Planning, Test Monitoring and Control, Test Analysis, Test Design, Test Implementation, Test Execution, and Test Completion.

ISTQB CTFL Syllabus v4.0, 2023, Figure 1.3-1, The Fundamental Test Process and its Test Activities. This diagram visually represents the phases listed in option A.

ISTQB Glossary of Testing Terms v4.0, 2023. Defines each of the terms used in option A as part of the fundamental test process.

The question asks for the statement that is NOT correct. Static testing is performed early in the software development lifecycle to find defects in work products like requirements, design, and code without executing them. Finding and fixing defects at this early stage is significantly cheaper and faster than finding them later during dynamic testing. Consequently, static testing helps to reduce overall development costs and time, making the statement that it increases them incorrect.

A. A primary benefit of static testing is finding defects early, often long before any code is executed in dynamic testing.
B. By enabling early defect detection and correction, static testing significantly reduces the cost and time associated with rework later in the project.
D. Static testing can find certain types of defects, such as dead code or non-adherence to coding standards, that are difficult to detect with dynamic testing.

- ISTQB® Certified Tester Foundation Level Syllabus V4.0, 2023. Section 3.1.2, page 29: "By finding defects early, static testing reduces the cost of quality... Rework costs are reduced, which means that development productivity is increased, and timescales are reduced."