Free Access to ISTQB.ISTQB-CTFL.v2026-04-09.q129 with Valid Practice Test (Page 13)

Question 56

Match each objective to the correct test level
Objective:
A)Verifying whetherthe functionalandnon-functlonalbehaviorsof the system are as designed andspecified.
B)Verifying whetherthe functionalandnon-functlonalbehaviorsof the interfaces are as designed.
C)Verifying whetherthe functionalandnon-functionalbehaviorsof the components are as designedand specified.
D)Establishing confidence in the quality of the systemas a whole.
Test Level:
1.Component testing.
2.Integration testing.
3.System testing.
4.Acceptance testing.

A.A3, B2. C4. D1
B.A2, B3, Cl, D4
C.A3. B2. C1. D4

Question 57

Which of the following statements is true?

A.A defect does not always produce a failure, while a bug always produces a failure
B.A defect may cause a failure which, when occurring, always causes an error
C.Failures can be caused by defects, but also by environmental conditions
D.Bugs are defects found during component testing, while failures are defects found at higher test levels

Correct Answer: C

Failures can be caused by defects, but also by environmental conditions. A failure is an event in which the software system does not perform a required function or performs a function incorrectly, according to the expected behavior. A defect is a flaw in the software system or a deviation from the requirements or the specifications, that may cause a failure. However, not all failures are caused by defects, as some failures may be caused by environmental conditions, such as hardware malfunctions, network interruptions, power outages, incompatible configurations, etc. Environmental conditions are factors that affect the operation of the software system, but are not part of the software system itself. The other statements are false, because:
A defect does not always produce a failure, while a bug always produces a failure. This statement is false, because a defect may or may not produce a failure, depending on the inputs, the outputs, the states, or the scenarios of the software system, and a bug is just another term for a defect, so it has the same possibility of producing a failure as a defect. For example, a defect in a rarely used feature or a hidden branch of the code may never produce a failure, while a defect in a frequently used feature or a critical path of the code may produce a failure often. A bug is not a different concept from a defect, but rather a synonym or a colloquial term for a defect, so it has the same definition and implications as a defect.
A defect may cause a failure which, when occurring, always causes an error. This statement is false, because an error is not a consequence of a failure, but rather a cause of a defect. An error is a human action or a mistake that produces a defect in the software system, such as a typo, a logic flaw, a requirement misunderstanding, etc. An error is not observable in the software system, but rather in the human mind or the human work products, such as the code, the design, the documentation, etc. A failure is not a cause of an error, but rather a result of a defect, which is a result of an error. For example, an error in the code may cause a defect in the software system, which may cause a failure in the software behavior.
Bugs are defects found during component testing, while failures are defects found at higher test levels. This statement is false, because bugs and failures are not different types of defects, but rather different terms for defects and their manifestations. As mentioned before, bugs are just another word for defects, and failures are the events in which the software system does not perform as expected due to defects. Bugs and failures can be found at any test level, not only at component testing or higher test levels. 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. Defects and failures can occur and be detected at any test level, depending on the test objectives, the test basis, the test techniques, and the test environment. Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:
ISTQBCertified Tester Foundation Level Syllabus v4.0, Chapter 1.1.2, Testing and Quality1 ISTQBCertified Tester Foundation Level Syllabus v4.0, Chapter 1.2.1, Testing Principles1 ISTQBCertified Tester Foundation Level Syllabus v4.0, Chapter 1.3.1, Testing in Software Development Lifecycles1 ISTQBGlossary of Testing Terms v4.0, Failure, Defect, Bug, Environmental Condition, Error, Test Level2

Question 58

For withdrawing money tram an Automated Teller Machine (ATM), the following conditions are required:
- The bank card is valid
- The PIN code is correct
- Money is available in the user's account
The following are some possible interactions between the user and the ATM:
- The entered card is invalid The card is rejected
- The PIN code is wrong The ATM asks for another PIN code
- The requested amount is more than available in the user's account: The ATM asks for another amount
- The requested amount is available in the user's account The ATM dispenses the money Which test design technique should be used to cover all possible combinations of the in put conditions?

A.Use case based testing
B.Decision table
C.Boundary value analysis
D.Equivalence class partitioning

Correct Answer: B

A decision table is a technique that should be used to cover all possible combinations of input conditions for withdrawing money from an Automated Teller Machine (ATM). A decision table shows combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects). A decision table consists of four quadrants: conditions (inputs), actions (outputs), condition entries (values) and action entries (results). A decision table can be used to test components that have multiple inputs and outputs that depend on logical combinations of conditions. For example, for testing the ATM, we can identify three input conditions: the bank card is valid, the PIN code is correct, and money is available in the user's account. We can also identify four output actions: the card is rejected, the ATM asks for another PIN code, the ATM asks for another amount, and the ATM dispenses the money. A decision table can show all possible combinations of these conditions and actions in a systematic way.
Use case based testing is not a technique that can cover all possible combinations of input conditions for withdrawing money from an ATM. Use case based testing is a technique that verifies that a software product or system meets its specified requirements or user stories by executing realistic scenarios or workflows. Use case based testing can be used to test components that have complex or dynamic interactions with users or other systems. For example, for testing the ATM, we can identify several use cases, such as withdraw money, check balance, transfer money, etc.Each use case can have one or more scenarios that describe the steps and outcomes of the interaction. However, use case based testing may not cover all possible combinations of input conditions, as some scenarios may be omitted or overlooked.
Boundary value analysis is not a technique that can cover all possible combinations of input conditions for withdrawing money from an ATM. 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 test components that have input values that can be divided into partitions of equivalent data. For example, for testing the ATM, we can identify boundary values for the input amount, such as the minimum and maximum amount allowed by the system or the user's account. However, boundary value analysis may not cover all possible combinations of input conditions, as some conditions may not have boundary values or may not be related to input values.
Equivalence class partitioning is not a technique that can cover all possible combinations of input conditions for withdrawing money from an ATM. Equivalence class 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 class partitioning can be used to test components that have input values that can be divided into partitions of equivalent data. For example, for testing the ATM, we can identify equivalence partitions for the input amount, such as valid amount (within the range allowed by the system and the user's account) and invalid amount (outside the range allowed by the system or the user's account). However, equivalence class partitioning may not cover all possible combinations of input conditions, as some conditions may not be related to input values or may have more than two partitions. Verified References: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer], Chapter 4, page 34-46.

Question 59

Consider the following simplified version of a state transition diagram that specifies the behavior of a video poker game:

What Is 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?

A.1
B.2
C.3
D.4

Question 60

Which of the following best describes the relationship between a test progress report and a test summary report?

A.The test report prepared during a test activity may be referred to as a test summary report, while a test report prepared at the end of a test activity may be referred to as a test progress report.
B.There is no difference between a test progress report and a test summary report.
C.Both the test progress report and the test summary report should always be generated via an automated tool.
D.The test report prepared during a test activity may be referred to as a test progress report, while a test report prepared at the end of a test activity may be referred to as a test summary report.

Question 56

Question 57

Question 58

Question 59

Question 60

Download PDF File