Practice Free CTFL_SYLL_4.0 Exam Online Questions
Question #1
Determining the schedule for each testing activity and test milestones for a test project, using activity estimates, available resources, and other constraints is a typical task performed during:
- A . test execution
- B . test design
- C . test analysis
- D . test planning
Correct Answer: D
D
Explanation:
Test planning is a critical phase in the software testing life cycle where the schedule for each testing activity and test milestones for a test project are determined. This involves using activity estimates, available resources, and other constraints to outline a comprehensive plan for the entire testing process. The main objective of test planning is to ensure that all testing activities are well-coordinated and that the testing process is efficient and effective. This phase sets the foundation for subsequent phases such as test analysis, test design, and test execution by providing a clear roadmap and allocation of resources.
Reference: ISTQB® CTFL Syllabus 4.0, Chapter 5.1, page 47: Test Planning
D
Explanation:
Test planning is a critical phase in the software testing life cycle where the schedule for each testing activity and test milestones for a test project are determined. This involves using activity estimates, available resources, and other constraints to outline a comprehensive plan for the entire testing process. The main objective of test planning is to ensure that all testing activities are well-coordinated and that the testing process is efficient and effective. This phase sets the foundation for subsequent phases such as test analysis, test design, and test execution by providing a clear roadmap and allocation of resources.
Reference: ISTQB® CTFL Syllabus 4.0, Chapter 5.1, page 47: Test Planning
Question #2
Which of the following statements is true?
- A . Experience-based test techniques rely on the experience of testers to identify the root causes of defects found by black-box test techniques
- B . Some of the most common test basis used by white-box test techniques include user stories, use cases and business processes
- C . Experience-based test techniques are often useful to detect hidden defects that have not been targeted by black-box test techniques
- D . The primary goal of experience-based test techniques is to design test cases that can be easily automated using a GUI-based test automation tool
Correct Answer: C
C
Explanation:
Experience-based test techniques are test design techniques that rely on the experience, knowledge, intuition, and creativity of the testers to identify and execute test cases that are likely to find defects in the software system. Experience-based test techniques are often useful to detect hidden defects that have not been targeted by black-box test techniques, which are test design techniques that use the external behavior and specifications of the software system as the test basis, without considering its internal structure or implementation. Experience-based test techniques can complement black-box test techniques by covering aspects that are not explicitly specified, such as usability, security, reliability, performance, etc.
The other statements are false, because:
– Experience-based test techniques do not rely on the experience of testers to identify the root causes of defects found by black-box test techniques, but rather to identify the potential sources of defects based on their own insights, heuristics, or exploratory testing. The root causes of defects are usually identified by debugging or root cause analysis, which are activities that involve examining the code or the development process to find and fix the errors that led to the defects.
– Some of the most common test basis used by white-box test techniques include the source code, the design documents, the architecture diagrams, and the control flow graphs of the software system. White-box test techniques are test design techniques that use the internal structure and implementation of the software system as the test basis, and aim to achieve a certain level of test coverage based on the code elements, such as statements, branches, paths, etc. User stories, use cases, and business processes are examples of test basis used by black-box test techniques, as they describe the functional and non-functional requirements of the software system from the perspective of the users or the stakeholders.
– The primary goal of experience-based test techniques is not to design test cases that can be easily automated using a GUI-based test automation tool, but rather to design test cases that can reveal defects that are not easily detected by other test techniques, such as boundary value analysis, equivalence partitioning, state transition testing, etc. Test automation is the use of software tools to execute test cases and compare actual results with expected results, without human intervention. Test automation can be applied to different types of test techniques, depending on the test objectives, the test levels, the test tools, and the test resources. However, test automation is not always feasible or beneficial, especially for test cases that require human judgment, creativity, or exploration, such as those designed by experience-based test techniques.
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 Techniques
– ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.2.2, White-box Test Design Techniques
– ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.2.3, Experience-based Test Design Techniques
– ISTQB® Glossary of Testing Terms v4.0, Experience-based Test Technique, Black-box Test Technique, White-box Test Technique, Test Basis, Test Coverage, Test Automation
C
Explanation:
Experience-based test techniques are test design techniques that rely on the experience, knowledge, intuition, and creativity of the testers to identify and execute test cases that are likely to find defects in the software system. Experience-based test techniques are often useful to detect hidden defects that have not been targeted by black-box test techniques, which are test design techniques that use the external behavior and specifications of the software system as the test basis, without considering its internal structure or implementation. Experience-based test techniques can complement black-box test techniques by covering aspects that are not explicitly specified, such as usability, security, reliability, performance, etc.
The other statements are false, because:
– Experience-based test techniques do not rely on the experience of testers to identify the root causes of defects found by black-box test techniques, but rather to identify the potential sources of defects based on their own insights, heuristics, or exploratory testing. The root causes of defects are usually identified by debugging or root cause analysis, which are activities that involve examining the code or the development process to find and fix the errors that led to the defects.
– Some of the most common test basis used by white-box test techniques include the source code, the design documents, the architecture diagrams, and the control flow graphs of the software system. White-box test techniques are test design techniques that use the internal structure and implementation of the software system as the test basis, and aim to achieve a certain level of test coverage based on the code elements, such as statements, branches, paths, etc. User stories, use cases, and business processes are examples of test basis used by black-box test techniques, as they describe the functional and non-functional requirements of the software system from the perspective of the users or the stakeholders.
– The primary goal of experience-based test techniques is not to design test cases that can be easily automated using a GUI-based test automation tool, but rather to design test cases that can reveal defects that are not easily detected by other test techniques, such as boundary value analysis, equivalence partitioning, state transition testing, etc. Test automation is the use of software tools to execute test cases and compare actual results with expected results, without human intervention. Test automation can be applied to different types of test techniques, depending on the test objectives, the test levels, the test tools, and the test resources. However, test automation is not always feasible or beneficial, especially for test cases that require human judgment, creativity, or exploration, such as those designed by experience-based test techniques.
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 Techniques
– ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.2.2, White-box Test Design Techniques
– ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.2.3, Experience-based Test Design Techniques
– ISTQB® Glossary of Testing Terms v4.0, Experience-based Test Technique, Black-box Test Technique, White-box Test Technique, Test Basis, Test Coverage, Test Automation
Question #3
You are a tester working on a critical project. Based on the risk analysis you need to decide on the order of test execution.
Which of the following lists the correct sequence of test execution? Priority 1 is the highest and Priority 3 is the lowest priority.
Test Case Priority Dependencies
Test A 3 –
Test B 1 Test D
Test C 2 Test A
Test D 3 •
- A . D-C-B-A
- B . D-B-A-C
- C . D-A-B-C
- D . C-B-A-D
Correct Answer: B
B
Explanation:
When deciding on the order of test execution based on priorities and dependencies, the correct sequence should consider both the priority levels and any dependencies between test cases.
Here’s the analysis:
Test B has the highest priority (1) and depends on Test D.
Test D should be executed before Test B.
Test C has a medium priority (2) and depends on Test A.
Test A can be executed at any time since it has no dependencies.
Considering these dependencies and priorities, Test D should be executed first, followed by Test B.
After that, Test A and finally Test C. Therefore, the correct sequence is D-B-A-C.
B
Explanation:
When deciding on the order of test execution based on priorities and dependencies, the correct sequence should consider both the priority levels and any dependencies between test cases.
Here’s the analysis:
Test B has the highest priority (1) and depends on Test D.
Test D should be executed before Test B.
Test C has a medium priority (2) and depends on Test A.
Test A can be executed at any time since it has no dependencies.
Considering these dependencies and priorities, Test D should be executed first, followed by Test B.
After that, Test A and finally Test C. Therefore, the correct sequence is D-B-A-C.
Question #4
A Test Manager conducts risk assessment for a project. One of the identified risks is: The sub-contractor may fail to meet his commitment". If this risk materializes. it will lead to delay in completion of testing required for the current cycle.
Which of the following sentences correctly describes the risk?
- A . It is a product risk since any risk associated with development timeline is a product risk.
- B . It is no longer a risk for the Test Manager since an independent party (the sub-contractor) is now managing it
- C . It is a object risk since successful completion of the object depends on successful and timely completion of the tests
- D . It is a product risk since default on part of the sub-contractor may lead to delay in release of the product
Correct Answer: D
D
Explanation:
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:
D
Explanation:
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:
Question #5
During component testing of a program if 100% decision coverage is achieved, which of the following coverage criteria is also guaranteed to be 100%?
- A . 100% Stale transition coverage
- B . 100% Equivalence class coverage
- C . 100% Boundary value coverage
- D . 100% Statement coverage
Correct Answer: D
D
Explanation:
Statement coverage is a structural coverage metric that measures the percentage of executable statements in the source code that are executed by a test suite1. Decision coverage is another structural coverage metric that measures the percentage of decision outcomes (such as branches or conditions) in the source code that are executed by a test suite1. Decision coverage is a stronger metric than statement coverage, because it requires that every possible outcome of each decision is tested, while statement coverage only requires that every statement is executed at least once2. Therefore, if a test suite achieves 100% decision coverage, it also implies that it achieves 100% statement coverage, because every statement in every branch or condition must have been executed. However, the converse is not true: 100% statement coverage does not guarantee 100% decision coverage, because some branches or conditions may have multiple outcomes that are not tested by the test suite2.
For example, consider the following pseudocode:
if (x > 0) then print(“Positive”) else print(“Non-positive”) end if
A test suite that executes this code with x = 1 and x = -1 will achieve 100% statement coverage, because both print statements are executed. However, it will not achieve 100% decision coverage, because the condition x > 0 has only been tested with two outcomes: true and false. The third possible outcome, x = 0, has not been tested by the test suite. Therefore, the test suite may miss a potential bug or error in the condition or the branch.
The other options, such as stale transition coverage, equivalence class coverage, and boundary value coverage, are not guaranteed to be 100% by achieving 100% decision coverage. Stale transition coverage is a structural coverage metric that measures the percentage of transitions between states in a state machine that are executed by a test suite3. Equivalence class coverage is a functional coverage metric that measures the percentage of equivalence classes (or partitions) of input or output values that are tested by a test suite4. Boundary value coverage is another functional coverage metric that measures the percentage of boundary values (or extreme values) of input or output ranges that are tested by a test suite4. These metrics are independent of decision coverage, because they are based on different aspects of the system under test, such as its behavior, functionality, or specification. Therefore, achieving 100% decision coverage does not imply achieving 100% of any of these metrics, and vice versa.
Reference = ISTQB® Certified Tester Foundation Level Syllabus v4.0, Test Coverage in Software Testing – Guru99, Structural Coverage Metrics – MATLAB & Simulink – MathWorks India, Test Design Coverage in Software Testing – GeeksforGeeks.
D
Explanation:
Statement coverage is a structural coverage metric that measures the percentage of executable statements in the source code that are executed by a test suite1. Decision coverage is another structural coverage metric that measures the percentage of decision outcomes (such as branches or conditions) in the source code that are executed by a test suite1. Decision coverage is a stronger metric than statement coverage, because it requires that every possible outcome of each decision is tested, while statement coverage only requires that every statement is executed at least once2. Therefore, if a test suite achieves 100% decision coverage, it also implies that it achieves 100% statement coverage, because every statement in every branch or condition must have been executed. However, the converse is not true: 100% statement coverage does not guarantee 100% decision coverage, because some branches or conditions may have multiple outcomes that are not tested by the test suite2.
For example, consider the following pseudocode:
if (x > 0) then print(“Positive”) else print(“Non-positive”) end if
A test suite that executes this code with x = 1 and x = -1 will achieve 100% statement coverage, because both print statements are executed. However, it will not achieve 100% decision coverage, because the condition x > 0 has only been tested with two outcomes: true and false. The third possible outcome, x = 0, has not been tested by the test suite. Therefore, the test suite may miss a potential bug or error in the condition or the branch.
The other options, such as stale transition coverage, equivalence class coverage, and boundary value coverage, are not guaranteed to be 100% by achieving 100% decision coverage. Stale transition coverage is a structural coverage metric that measures the percentage of transitions between states in a state machine that are executed by a test suite3. Equivalence class coverage is a functional coverage metric that measures the percentage of equivalence classes (or partitions) of input or output values that are tested by a test suite4. Boundary value coverage is another functional coverage metric that measures the percentage of boundary values (or extreme values) of input or output ranges that are tested by a test suite4. These metrics are independent of decision coverage, because they are based on different aspects of the system under test, such as its behavior, functionality, or specification. Therefore, achieving 100% decision coverage does not imply achieving 100% of any of these metrics, and vice versa.
Reference = ISTQB® Certified Tester Foundation Level Syllabus v4.0, Test Coverage in Software Testing – Guru99, Structural Coverage Metrics – MATLAB & Simulink – MathWorks India, Test Design Coverage in Software Testing – GeeksforGeeks.
Question #6
You are testing a room upgrade system for a hotel. The system accepts three differed types of room (increasing order of luxury): Platinum. Silver and Gold Luxury. ONLY a Preferred Guest Card holder s eligible for an upgrade.
Below you can find the decision table defining the upgrade eligibility:
What is the expected result for each of the following test cases?
Customer A: Preference Guest Card holder, holding a Silver room
Customer B: Non Preferred Guest Card holder, holding a Platinum room
- A . Customer A; doesn’t offer any upgrade; Customer B: offers upgrade to Gold luxury room
- B . Customer A: doesn’t offer any upgrade; Customer B: doesn’t offer any upgrade.
- C . Customer A: offers upgrade to Gold Luxury room; Customer B: doesn’t offer any upgrade
- D . Customer A: offers upgrade to Silver room; Customer B: offers upgrade to Silver room.
Correct Answer: C
C
Explanation:
According to the decision table in the image, a Preferred Guest Card holder with a Silver room is eligible for an upgrade to Gold Luxury (YES), while a non-Preferred Guest Card holder, regardless of room type, is not eligible for any upgrade (NO). Therefore, Customer A (a Preferred Guest Card holder with a Silver room) would be offered an upgrade to Gold Luxury, and Customer B (a non-Preferred Guest Card holder with a Platinum room) would not be offered any upgrade. Reference = The answer is derived directly from the decision table provided in the image; specific ISTQB Certified Tester Foundation Level (CTFL) v4.0 documents are not referenced.
C
Explanation:
According to the decision table in the image, a Preferred Guest Card holder with a Silver room is eligible for an upgrade to Gold Luxury (YES), while a non-Preferred Guest Card holder, regardless of room type, is not eligible for any upgrade (NO). Therefore, Customer A (a Preferred Guest Card holder with a Silver room) would be offered an upgrade to Gold Luxury, and Customer B (a non-Preferred Guest Card holder with a Platinum room) would not be offered any upgrade. Reference = The answer is derived directly from the decision table provided in the image; specific ISTQB Certified Tester Foundation Level (CTFL) v4.0 documents are not referenced.
Question #7
Which of the following about typical information found within a test plan is false?
- A . The need to temporarily have additional test personnel available for specific test phases and/or test activities
- B . The conditions that must be met in order for the test execution activities to be considered completed
- C . The list of the product risks which have not been fully mitigated at the end of test execution
- D . The conditions that must be met for part of all the planned activities to be suspended and resumed
Correct Answer: C
C
Explanation:
A test plan is a document detailing the objectives, resources, schedule, and scope of testing activities. It also outlines the test strategy, environment, tools, and criteria for test completion and suspension.
Option A: Correct as it indicates resource planning which is a crucial part of a test plan.
Option B: Correct as it describes exit criteria which are essential for test completion.
Option C: Incorrect because a test plan typically addresses known risks and mitigation strategies but does not list unmitigated risks post-test execution.
Option D: Correct as it mentions suspension criteria which are also a part of a test plan.
Therefore, option C is false as it does not reflect the typical information found within a test plan.
C
Explanation:
A test plan is a document detailing the objectives, resources, schedule, and scope of testing activities. It also outlines the test strategy, environment, tools, and criteria for test completion and suspension.
Option A: Correct as it indicates resource planning which is a crucial part of a test plan.
Option B: Correct as it describes exit criteria which are essential for test completion.
Option C: Incorrect because a test plan typically addresses known risks and mitigation strategies but does not list unmitigated risks post-test execution.
Option D: Correct as it mentions suspension criteria which are also a part of a test plan.
Therefore, option C is false as it does not reflect the typical information found within a test plan.
Question #8
Which of the following statements about white-box testing is false?
- A . Static testing can benefit from using code-related white-box test techniques during code reviews
- B . White-box testing allows suggesting test cases for increasing coverage levels which are based on objective measures
- C . Achieving full code coverage for a component or a system ensures that it has been fully tested
- D . Black-box testing can benefit from using code-related white-box test techniques to increase confidence in the code
Correct Answer: C
C
Explanation:
The statement "Achieving full code coverage for a component or a system ensures that it has been fully tested" is false because achieving full code coverage does not necessarily mean that all possible defects have been identified or that the system is free of bugs. Code coverage metrics, such as statement coverage, branch coverage, or path coverage, only measure the extent to which the source code has been executed during testing, but they do not guarantee that all logical paths or use cases have been exercised or that the code behaves correctly under all conditions.
Full code coverage indicates that every line of code has been executed at least once, but it does not account for the quality of the test cases or their ability to detect defects. There can still be issues related to performance, usability, security, and other non-functional aspects that are not addressed by code coverage alone.
Reference: The official ISTQB® CTFL syllabus outlines the limitations of code coverage and emphasizes that while it is an important metric, it does not guarantee the absence of defects or that the software is fully tested.
C
Explanation:
The statement "Achieving full code coverage for a component or a system ensures that it has been fully tested" is false because achieving full code coverage does not necessarily mean that all possible defects have been identified or that the system is free of bugs. Code coverage metrics, such as statement coverage, branch coverage, or path coverage, only measure the extent to which the source code has been executed during testing, but they do not guarantee that all logical paths or use cases have been exercised or that the code behaves correctly under all conditions.
Full code coverage indicates that every line of code has been executed at least once, but it does not account for the quality of the test cases or their ability to detect defects. There can still be issues related to performance, usability, security, and other non-functional aspects that are not addressed by code coverage alone.
Reference: The official ISTQB® CTFL syllabus outlines the limitations of code coverage and emphasizes that while it is an important metric, it does not guarantee the absence of defects or that the software is fully tested.
Question #9
The tests at the bottom layer of the test pyramid:
- A . run faster than the tests at the top layer of the pyramid
- B . cover larger pieces of functionalities than the tests at the top layer of the pyramid
- C . are defined as ‘Ul Tests’ or ‘End-To-End tests’ in the different models of the pyramid
- D . are unscripted tests produced by experience-based test techniques
Correct Answer: A
A
Explanation:
The tests at the bottom layer of the test pyramid run faster than the tests at the top layer of the pyramid because they are more focused, isolated, and atomic. They usually test individual units or components of the software system, such as classes, methods, or functions. They are also easier to maintain and execute, as they have fewer dependencies and interactions with other parts of the system. The tests at the top layer of the test pyramid, on the other hand, are slower because they cover larger pieces of functionalities, such as user interfaces, workflows, or end-to-end scenarios. They also have more dependencies and interactions with other systems, such as databases, networks, or external services. They are more complex and costly to maintain and execute, as they require more setup and teardown procedures, test data, and test environments.
Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 3.2.1, Test Pyramid1
ISTQB® Glossary of Testing Terms v4.0, Test Pyramid2
A
Explanation:
The tests at the bottom layer of the test pyramid run faster than the tests at the top layer of the pyramid because they are more focused, isolated, and atomic. They usually test individual units or components of the software system, such as classes, methods, or functions. They are also easier to maintain and execute, as they have fewer dependencies and interactions with other parts of the system. The tests at the top layer of the test pyramid, on the other hand, are slower because they cover larger pieces of functionalities, such as user interfaces, workflows, or end-to-end scenarios. They also have more dependencies and interactions with other systems, such as databases, networks, or external services. They are more complex and costly to maintain and execute, as they require more setup and teardown procedures, test data, and test environments.
Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 3.2.1, Test Pyramid1
ISTQB® Glossary of Testing Terms v4.0, Test Pyramid2
Question #10
For each test case to be executed, the following table specifies its dependencies and the required configuration of the test environment for running such test case:
Assume that CONF1 is the initial configuration of the test environment.
Based on this assumption, which of the following is a test execution schedule that is compatible with the specified dependencies and allows minimizing the number of switches between the different configurations of the test environment?
- A . TC4, TC3, TC2, TC1.TC5
- B . TC1.TC5.TC4. TC3, TC2
- C . TC4, TC3. TC2, TC5, TC1
- D . TC4.TC1, TC5. TC2.TC3
Correct Answer: A
A
Explanation:
To determine the correct execution order that minimizes the number of configuration switches and respects the dependencies, we need to consider the following:
Initial Configuration: CONF1.
Dependencies:
TC1 depends on nothing.
TC2 depends on TC4.
TC3 depends on TC4.
TC4 depends on nothing.
TC5 depends on TC1.
Configuration Requirements:
TC1 requires CONF2.
TC2 requires CONF2.
TC3 requires CONF1.
TC4 requires CONF1.
TC5 requires CONF2.
Given the initial configuration is CONF1, start with test cases that can run on CONF1 and respect the dependencies. Then switch to CONF2 only when necessary.
The optimal order to minimize configuration switches is:
Start with TC4 (no dependencies, CONF1).
Continue with TC3 (depends on TC4, CONF1).
Switch to CONF2.
Execute TC2 (depends on TC4, CONF2).
Continue with TC1 (no dependencies, CONF2).
Finally, execute TC5 (depends on TC1, CONF2).
Therefore, the correct order is:
TC4 (CONF1)
TC3 (CONF1)
TC2 (CONF2)
TC1 (CONF2)
TC5 (CONF2)
Thus, the answer is A. TC4, TC3, TC2, TC1, TC5.
A
Explanation:
To determine the correct execution order that minimizes the number of configuration switches and respects the dependencies, we need to consider the following:
Initial Configuration: CONF1.
Dependencies:
TC1 depends on nothing.
TC2 depends on TC4.
TC3 depends on TC4.
TC4 depends on nothing.
TC5 depends on TC1.
Configuration Requirements:
TC1 requires CONF2.
TC2 requires CONF2.
TC3 requires CONF1.
TC4 requires CONF1.
TC5 requires CONF2.
Given the initial configuration is CONF1, start with test cases that can run on CONF1 and respect the dependencies. Then switch to CONF2 only when necessary.
The optimal order to minimize configuration switches is:
Start with TC4 (no dependencies, CONF1).
Continue with TC3 (depends on TC4, CONF1).
Switch to CONF2.
Execute TC2 (depends on TC4, CONF2).
Continue with TC1 (no dependencies, CONF2).
Finally, execute TC5 (depends on TC1, CONF2).
Therefore, the correct order is:
TC4 (CONF1)
TC3 (CONF1)
TC2 (CONF2)
TC1 (CONF2)
TC5 (CONF2)
Thus, the answer is A. TC4, TC3, TC2, TC1, TC5.