Free CTFL-FOUNDATION Practice Test Questions and Answers (2026)

Testing provides valuable information about the quality of the software by identifying defects and

issues before the software is released. It helps stakeholders make informed decisions about the

release and deployment of the software. While testing can identify defects and provide confidence in

the quality of the software, it cannot guarantee the absence of defects or ensure that the software

quality will inherently increase. The primary goal of testing is to reveal problems and provide an

indication of the software's current state of quality.

Reference: ISTQB CTFL Syllabus V4.0 - Section 1.2.1, The Contribution of Testing to Success

Quality in software testing is best defined as conformance to requirements. The ISTQB CTFL syllabus

v4.0 states that quality is the degree to which a component, system, or process meets specified

requirements and/or user/customer needs and expectations​​.

A failure is defined as the incorrect program behavior caused by a fault (defect) in the program. This

means that when a defect is executed, it leads to the system not performing as expected, which is

observed as a failure. This concept is clearly defined in the ISTQB CTFL Syllabus, where it

distinguishes between defects (faults) and the resulting failures, emphasizing that failures are the

manifestation of defects during the execution of the software​​.

The implementation and execution phase of the fundamental test process involves the execution of

the tests according to the test plan, where the main task is to compare the actual results of the test

execution against the expected results. This phase ensures that the tests are carried out and the

discrepancies between the actual and expected outcomes are identified and documented. This

information is critical to determining whether the software behaves as intended and meets the

specified requirements.

Reference: ISTQB CTFL Syllabus V4.0 - Section 1.4.1, Test Activities and Tasks

Using equivalence partitioning, we divide the temperature ranges into the following partitions:

Fragile fabrics: 15–30

Normal fabrics: 31–60

Heavily soiled and tough fabrics: 61–100

In set C (25, 45, 75), each value belongs to a different equivalence partition:

25 (Fragile fabrics)

45 (Normal fabrics)

75 (Heavily soiled and tough fabrics)

Reference: ISTQB CTFL Syllabus V4.0, Section 4.2.1​​.

McCabe’s Cyclomatic Complexity is a metric used to measure the complexity of a program. It is

calculated using the formula:

Cyclomatic​Complexity=E−N+2P\text{Cyclomatic Complexity} = E - N +

2PCyclomatic​Complexity=E−N+2P

where:

E = number of edges in the flow graph

N = number of nodes in the flow graph

P = number of connected components (usually 1 for a single program)

In the given program, there are 2 decision points (IF and THEN). The cyclomatic complexity is

calculated as:

Cyclomatic​Complexity=2−1+2=3\text{Cyclomatic Complexity} = 2 - 1 + 2 =

3Cyclomatic​Complexity=2−1+2=3

Hence, the answer is B. Reference: ISTQB CTFL Syllabus V4.0, Section 4.3.2​​.

:

If the project isn't big enough to justify extensive testing, using risk-based analysis to find out which

areas need to be tested is the best approach. Risk-based testing prioritizes testing activities based on

the risk of failure and the impact of those failures, ensuring that critical areas of the application are

tested thoroughly even with limited resources. This approach helps in focusing testing efforts where

they are most needed. Reference: ISTQB CTFL Syllabus V4.0, Section 5.2.3​​.

Incremental testing approaches involve testing components of the software in increments or steps,

allowing for integration and testing of parts of the system progressively. According to the ISTQB CTFL

Syllabus, version 4.0, the common types of incremental testing approaches include:

Top-down: Testing starts from the top of the module hierarchy and progresses downwards.

Bottom-up: Testing begins with the lower-level modules and progresses upwards.

Functional incrementation: Adding and testing one function at a time.

Big-bang testing, however, is not an incremental approach. In big-bang testing, all components or

modules are integrated simultaneously, and the system is tested as a whole. This approach does not

allow for incremental testing and integration and is therefore not considered a type of incremental

testing approach​​.

A disadvantage of independent testing is that developers might lose a sense of responsibility for the

quality of their work. When developers rely too much on independent testers to find defects, they

may become less diligent in their own testing and quality assurance efforts. The ISTQB CTFL Syllabus

points out that while independent testing can provide an unbiased perspective and identify defects

that might be missed by developers, it can also lead to potential downsides such as diminished

developer accountability​​.

The impossibility of complete testing has several significant consequences:

It means that we can never be completely sure that the software is free of bugs (A).

Without a definite stopping point, it becomes easier for some managers to justify minimal testing

efforts (B).

Since every testing task requires time and resources, it becomes challenging to determine which

tasks are always necessary (C).

These points highlight the need for a balanced and risk-based approach to testing, where priorities

are set based on the context and criticality of the software being tested​​.

Designing the tests is part of the Test Analysis and Design phase, not the Test Implementation and

Execution phase. The Test Implementation and Execution phase involves creating test suites,

executing test cases, and comparing actual results with expected outcomes to identify any

discrepancies​​.

Non-functional system testing evaluates various quality attributes of a system rather than specific

behaviors or functionalities. According to the ISTQB CTFL Syllabus, version 4.0, non-functional testing

encompasses several critical aspects:

Performance testing evaluates how the system performs under different conditions, such as load and

stress, to ensure it meets performance requirements.

Usability testing assesses the user-friendliness and overall user experience of the system, ensuring

that it is intuitive and accessible for end-users.

The syllabus outlines that non-functional system testing includes testing the quality attributes of the

system, which goes beyond just functionality and delves into performance, usability, reliability, and

other key attributes​​.

Statement coverage measures the percentage of executable statements in the code that have been

executed. However, it does not check for missing statements since these are not present in the code

to be executed in the first place. Statement coverage can identify unused branches, dead code, and

unused statements within the code. Reference: ISTQB CTFL Syllabus V4.0, Section 4.3.2​​.

Reviewing the test basis is a key activity in the Test Analysis and Design phase. This phase involves

analyzing the test basis documents (such as requirements, design specifications, and use cases) to

identify test conditions and design test cases. The ISTQB CTFL Syllabus explains that thorough review

of the test basis ensures that the tests are aligned with the specified requirements and design,

improving the accuracy and relevance of the tests​​.

Static analysis tools are used to detect certain types of defects without executing the code. According

to the ISTQB CTFL syllabus v4.0, typical defects found by static analysis tools include variables that

are never used, security vulnerabilities, and unreachable code. Poor performance and business

processes not followed are not typically identified by static analysis tools​​.

The fundamental test process consists of the following broad chronological steps:

Planning and control

Analysis and design

Implementation and execution

Evaluating exit criteria and reporting

Test closure activities

Option B correctly places three of these steps in the correct order: Analysis and design, followed by

Evaluating exit criteria and reporting, and finally Test closure activities. This order reflects the logical

sequence of performing detailed test analysis and design before executing tests and then evaluating

the results to determine if exit criteria have been met, followed by wrapping up the testing activities.

Reference: ISTQB CTFL Syllabus V4.0 - Section 1.4, The Test Process

The purpose of test completion criteria in a test plan is to define when to stop testing. These criteria

are used to determine if sufficient testing has been conducted to meet the test objectives and to

decide whether the product is ready for release. They typically include coverage goals, risk levels,

defect rates, and other quality indicators. According to the ISTQB CTFL Syllabus, defining test

completion criteria helps ensure that testing is both thorough and efficient, avoiding unnecessary

testing while ensuring the product meets quality standards​​.

The cost of fixing a fault increases as the software progresses through the development lifecycle.

Fixing defects identified early in the requirements or design phases is less expensive compared to

fixing those found later in testing or after the software has been deployed. This is due to the larger

impact on the system, more extensive rework required, and potential disruptions to the user

experience in later stages.

Reference: ISTQB CTFL Syllabus V4.0 - Section 1.2.1, The Cost of Defects

Testing should be stopped based on risk criteria defined for the system being tested. The ISTQB CTFL

syllabus v4.0 outlines that the decision to stop testing is influenced by risk levels, coverage achieved,

time and budget constraints, and the criticality of the system under test. Stopping criteria should

ensure that the risk of remaining defects is acceptable for the project stakeholders​​.