Free Practice Questions for ISTQB CTFL-Foundation Exam

A valuable objective for a test team is to cause as many failures as possible so that faults can be identified and corrected. This approach is essential because the primary goal of testing is to uncover defects that could potentially lead to failures in the software. By intentionally causing failures, testers can identify and document faults, which can then be fixed to improve the overall quality of the software.

The ISTQB CTFL Syllabus, version 4.0, emphasizes that finding and fixing defects is a core purpose of testing. It is more important to identify and address issues than to prove the absence of defects. Therefore, causing failures to find faults aligns with the fundamental objectives of software testing​​.

The three decisions are in sequence and the conditions are all mutually exclusive (if any one is true the others must be false). Hence a test case that makes the first decision true will make the second and third decisions false and so on.

So test case 1 (say Time = 6) would exercise the path True, False, False, test case 2 (say Time = 15) would exercise the path False, True, False. Test case 3 would have to be Time = 12. This combination achieves 100 per cent decision coverage because each decision has been exercised through its true and its false outcomes.

Fault masking occurs when one defect prevents the detection of another defect. In other words, an error condition hides another error condition, making it more difficult to identify and correct all defects. This can happen in various scenarios, such as when a certain path of code execution is blocked by an existing error, preventing other potential errors from being executed and detected. Reference: ISTQB CTFL Syllabus V4.0, Section 1.5.5​​.

Structure-based testing, also known as white-box testing, uses information about the software’s internal structure to derive test cases. This method often involves measuring coverage, such as statement coverage or decision coverage, to ensure that different parts of the code are exercised by the tests. These techniques require a deep understanding of the software's construction and are used to validate the implementation rather than the functionality. Reference: ISTQB CTFL Syllabus V4.0, Section 4.3.1​​.

In a review meeting, the moderator is responsible for ensuring the meeting runs smoothly, mediating between participants, and managing time effectively. The moderator's role includes facilitating communication and making sure all participants have the opportunity to contribute. Taking minutes of the meeting is typically done by a recorder or scribe, not the moderator. Reference: ISTQB CTFL Syllabus V4.0, Section 3.2.4​​.

Regression testing serves to demonstrate that unchanged areas of the software have not been unintentionally affected by changes. The ISTQB CTFL syllabus v4.0 states that while regression testing can be carried out at various stages of the lifecycle and is often automated, its primary purpose is to ensure that existing functionality remains unaffected after changes​​.

A key principle of software testing is that it is usually impossible to test all possible input and output combinations for a software system. This principle, highlighted in the ISTQB CTFL Syllabus, acknowledges the practical limitations of testing. Instead, risk-based testing and prioritization techniques are employed to focus on the most critical areas. This approach ensures effective and efficient testing without attempting the infeasible task of exhaustive testing​​.

Structure-based (white-box) test case design techniques involve deriving test cases systematically from the delivered code. The ISTQB CTFL syllabus v4.0 describes that these techniques focus on the internal structure of the software, using knowledge of the code to create test cases that ensure comprehensive coverage of the code's pathways and logic​​.

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​​.

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​​.