Practice Free CTFL_SYLL_4.0 Exam Online Questions
Question #11
First timeslot should have a 10% discount.
Which of the following is the BEST example of a test case for this user story?
- A . Logon to the site and book an exam for the 8 AM (GMT) timeslot. Expected result: You should get 10% discounted price. Change the time to any other timeslot. Expected result: Discount should be removed
- B . Logon to the site. Book 5 exams for the current date. Expected result: Exams should be booked. Book 6th timeslot for the same date. Expected result: The exam should be booked but no discount should be given.
- C . Logon to the site. Expected result: Default 8 AM (GMT) timeslot should be selected. Change the time to any other timeslot. Expected result: New slot should be booked
- D . Logon to the site. Book an exam for the current date. Expected result: timeslots should be shown. Change the time to any other date prior to the selected date. Expected result: New slot should become visible.
Correct Answer: A
A
Explanation:
The best example of a test case for this user story should cover the acceptance criteria comprehensively.
Option A addresses the critical aspects of the acceptance criteria:
Verifying the discount for the first timeslot (8 AM GMT) – ensuring it provides a 10% discount.
Verifying that changing the time slot removes the discount – ensuring the discount logic is correctly applied.
This test case effectively validates the functionality related to both the discount and the ability to change time slots, which are key parts of the user story’s requirements.
A
Explanation:
The best example of a test case for this user story should cover the acceptance criteria comprehensively.
Option A addresses the critical aspects of the acceptance criteria:
Verifying the discount for the first timeslot (8 AM GMT) – ensuring it provides a 10% discount.
Verifying that changing the time slot removes the discount – ensuring the discount logic is correctly applied.
This test case effectively validates the functionality related to both the discount and the ability to change time slots, which are key parts of the user story’s requirements.
Question #12
A requirement specifies that a certain identifier (ID) must be between 5 and 10 characters long, must contain only alphanumeric characters, and its first character must be a letter. As a tester, you want to apply one-dimensional equivalence partitioning to test this ID. This means that you have to apply equivalence partitioning individually: to the length of the ID, the type of characters contained within the ID, and the type of the first character of the ID.
What is the number of partitions to cover?
- A . 7
- B . 6
- C . 5
- D . 3
Correct Answer: A
A
Explanation:
To determine the number of partitions using one-dimensional equivalence partitioning, we need to consider each aspect of the ID requirement individually.
Length of the ID:
Valid partitions: 5 to 10 characters (1 partition)
Invalid partitions: Less than 5 characters, more than 10 characters (2 partitions)
Type of characters:
Valid partitions: Alphanumeric characters (1 partition)
Invalid partitions: Non-alphanumeric characters (1 partition)
Type of first character:
Valid partitions: First character is a letter (1 partition)
Invalid partitions: First character is not a letter (1 partition)
Adding these together, we have a total of 1 (valid length) + 2 (invalid lengths) + 1 (valid type) + 1 (invalid type) + 1 (valid first character) + 1 (invalid first character) = 7 partitions.
Reference: ISTQB CTFL Syllabus, section on equivalence partitioning and test design techniques.
A
Explanation:
To determine the number of partitions using one-dimensional equivalence partitioning, we need to consider each aspect of the ID requirement individually.
Length of the ID:
Valid partitions: 5 to 10 characters (1 partition)
Invalid partitions: Less than 5 characters, more than 10 characters (2 partitions)
Type of characters:
Valid partitions: Alphanumeric characters (1 partition)
Invalid partitions: Non-alphanumeric characters (1 partition)
Type of first character:
Valid partitions: First character is a letter (1 partition)
Invalid partitions: First character is not a letter (1 partition)
Adding these together, we have a total of 1 (valid length) + 2 (invalid lengths) + 1 (valid type) + 1 (invalid type) + 1 (valid first character) + 1 (invalid first character) = 7 partitions.
Reference: ISTQB CTFL Syllabus, section on equivalence partitioning and test design techniques.
Question #13
Who of the following has the best knowledge to decide what tests in a test project should be automated?
- A . The developer
- B . The customer
- C . The development manager
- D . The test leader
Correct Answer: D
D
Explanation:
The test leader is the person who is responsible for planning, monitoring, and controlling the test activities and resources in a test project. The test leader should have the best knowledge of the test objectives, scope, risks, resources, schedule, and quality criteria. The test leader should also be aware of the test automation criteria, such as the execution frequency, the test support, the team education, the roles and responsibilities, and the devs and testers collaboration1. Based on these factors, the test leader can decide which tests are suitable for automation and which are not, and prioritize them accordingly. The test leader can also coordinate with the test automation engineers, the developers, and the stakeholders to ensure the alignment of the test automation strategy with the test project goals and expectations. Reference = ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Chapter 2, Section 2.3.1, Page 152; ISTQB Glossary of Testing Terms v4.0, Page 403; ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Chapter 6, Section 6.1.1, Page 514; Top 8 Test Automation Criteria You Need To Fulfill – QAMIND1
D
Explanation:
The test leader is the person who is responsible for planning, monitoring, and controlling the test activities and resources in a test project. The test leader should have the best knowledge of the test objectives, scope, risks, resources, schedule, and quality criteria. The test leader should also be aware of the test automation criteria, such as the execution frequency, the test support, the team education, the roles and responsibilities, and the devs and testers collaboration1. Based on these factors, the test leader can decide which tests are suitable for automation and which are not, and prioritize them accordingly. The test leader can also coordinate with the test automation engineers, the developers, and the stakeholders to ensure the alignment of the test automation strategy with the test project goals and expectations. Reference = ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Chapter 2, Section 2.3.1, Page 152; ISTQB Glossary of Testing Terms v4.0, Page 403; ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Chapter 6, Section 6.1.1, Page 514; Top 8 Test Automation Criteria You Need To Fulfill – QAMIND1
Question #14
Test automation allows you to:
- A . demonstrate the absence of defects
- B . produce tests that are less subject to human errors
- C . avoid performing exploratory testing
- D . increase test process efficiency by facilitating management of defects
Correct Answer: B
B
Explanation:
Test automation allows you to produce tests that are less subject to human errors, as they can execute predefined test scripts or test cases with consistent inputs, outputs, and expected results. Test automation can also reduce the manual effort and time required to execute repetitive or tedious tests, such as regression tests, performance tests, or data-driven tests. Test automation does not demonstrate the absence of defects, as it can only verify the expected behavior of the system under test, not the unexpected or unknown behavior. Test automation does not avoid performing exploratory testing, as exploratory testing is a valuable technique to discover new information, risks, or defects that are not covered by automated tests. Test automation does not increase test process efficiency by facilitating management of defects, as defect management is a separate activity that involves reporting, tracking, analyzing, and resolving defects, which may or may not be related to automated tests.
Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 3.3.1, Test Automation1 ISTQB® Glossary of Testing Terms v4.0, Test Automation2
B
Explanation:
Test automation allows you to produce tests that are less subject to human errors, as they can execute predefined test scripts or test cases with consistent inputs, outputs, and expected results. Test automation can also reduce the manual effort and time required to execute repetitive or tedious tests, such as regression tests, performance tests, or data-driven tests. Test automation does not demonstrate the absence of defects, as it can only verify the expected behavior of the system under test, not the unexpected or unknown behavior. Test automation does not avoid performing exploratory testing, as exploratory testing is a valuable technique to discover new information, risks, or defects that are not covered by automated tests. Test automation does not increase test process efficiency by facilitating management of defects, as defect management is a separate activity that involves reporting, tracking, analyzing, and resolving defects, which may or may not be related to automated tests.
Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 3.3.1, Test Automation1 ISTQB® Glossary of Testing Terms v4.0, Test Automation2
Question #15
Can "cost" be regarded as Exit criteria?
- A . Yes. Spending too much money on test ng will result in an unprofitable product, and having cost as an exit criterion helps avoid this
- B . No. The financial value of product quality cannot be estimated, so it is incorrect to use cost as an exit criterion
- C . Yes. Going by cost as an exit criterion constrains the testing project which will hello achieve the desired quality level defined for the project
- D . No The cost of testing cannot be measured effectively, so it is incorrect to use cost as an exit criterion
Correct Answer: A
A
Explanation:
Cost can be regarded as an exit criterion for testing, because it is a factor that affects the profitability and feasibility of the software product. Testing is an investment that aims to improve the quality and reliability of the software product, but it also consumes resources, such as time, money, and human effort. Therefore, testing should be planned and executed in a way that balances the cost and benefit of testing activities. Having cost as an exit criterion helps to avoid spending too much money on testing, which may result in an unprofitable product or a loss of competitive advantage. Cost can also help to prioritize and focus the testing efforts on the most critical and valuable features and functions of the software product. However, cost should not be the only exit criterion for testing, as it may not reflect the true quality and risk level of the software product. Other exit criteria, such as defect rate, test coverage, user satisfaction, etc., should also be considered and defined in the test plan.
The other options are incorrect, because they either deny the importance of cost as an exit criterion, or they make false or unrealistic assumptions about the cost of testing.
Option B is incorrect, because the financial value of product quality can be estimated, for example, by using cost-benefit analysis, return on investment, or cost of quality models.
Option C is incorrect, because going by cost as an exit criterion does not necessarily constrain the testing project or help achieve the desired quality level. Cost is a relative and variable factor that depends on the scope, complexity, and context of the software product and the testing project.
Option D is incorrect, because the cost of testing can be measured effectively, for example, by using metrics, such as test effort, test resources, test tools, test environment, etc.
A
Explanation:
Cost can be regarded as an exit criterion for testing, because it is a factor that affects the profitability and feasibility of the software product. Testing is an investment that aims to improve the quality and reliability of the software product, but it also consumes resources, such as time, money, and human effort. Therefore, testing should be planned and executed in a way that balances the cost and benefit of testing activities. Having cost as an exit criterion helps to avoid spending too much money on testing, which may result in an unprofitable product or a loss of competitive advantage. Cost can also help to prioritize and focus the testing efforts on the most critical and valuable features and functions of the software product. However, cost should not be the only exit criterion for testing, as it may not reflect the true quality and risk level of the software product. Other exit criteria, such as defect rate, test coverage, user satisfaction, etc., should also be considered and defined in the test plan.
The other options are incorrect, because they either deny the importance of cost as an exit criterion, or they make false or unrealistic assumptions about the cost of testing.
Option B is incorrect, because the financial value of product quality can be estimated, for example, by using cost-benefit analysis, return on investment, or cost of quality models.
Option C is incorrect, because going by cost as an exit criterion does not necessarily constrain the testing project or help achieve the desired quality level. Cost is a relative and variable factor that depends on the scope, complexity, and context of the software product and the testing project.
Option D is incorrect, because the cost of testing can be measured effectively, for example, by using metrics, such as test effort, test resources, test tools, test environment, etc.
Question #16
Which of the following statements about white-box test techniques is true?
- A . Achieving full statement coverage and full branch coverage for a software product means that such software product has been fully tested and there are no remaining bugs within the code
- B . Code-related white-box test techniques are not required to measure the actual code coverage achieved by black-box testing, as code coverage can be measured using the coverage criteria associated with black-box test techniques
- C . Branch coverage is the most thorough code-related white-box test technique, and therefore applicable standards prescribe achieving full branch coverage at the highest safety levels for safety-critical systems
- D . Code-related white-box test techniques provide an objective measure of coverage and can be used to complement black-box test techniques to increase confidence in the code
Correct Answer: D
D
Explanation:
This answer is correct because code-related white-box test techniques are test design techniques that use the structure of the code to derive test cases. They provide an objective measure of coverage, such as statement coverage, branch coverage, or path coverage, which indicate how much of the code has been exercised by the test cases. Code-related white-box test techniques can be used to complement black-box test techniques, which are test design techniques that use the functional or non-functional requirements of the system or component to derive test cases. By combining both types of techniques, testers can increase their confidence in the code and find more defects.
Reference: ISTQB Glossary of Testing Terms v4.0, ISTQB Foundation Level Syllabus v4.0, Section 2.3.2.2
D
Explanation:
This answer is correct because code-related white-box test techniques are test design techniques that use the structure of the code to derive test cases. They provide an objective measure of coverage, such as statement coverage, branch coverage, or path coverage, which indicate how much of the code has been exercised by the test cases. Code-related white-box test techniques can be used to complement black-box test techniques, which are test design techniques that use the functional or non-functional requirements of the system or component to derive test cases. By combining both types of techniques, testers can increase their confidence in the code and find more defects.
Reference: ISTQB Glossary of Testing Terms v4.0, ISTQB Foundation Level Syllabus v4.0, Section 2.3.2.2
Question #17
Which of the following statements about checklist-based testing is true?
- A . Checklist-based testing is a technique for managing the review meeting that can be applied in those reviews where the use of checklists is mandatory, as is often the case in formal reviews
- B . Checklist-based testing is a review technique that can be used in a formal review process where reviewers, during individual review, try to detect issues within the work product based on a checklist
- C . In checklist-based testing, using checklists at a high level of detail is more likely to produce test cases that are easier to reproduce than those using checklists at a low level of detail
- D . Checklists used in checklist-based testing should be reviewed periodically for updates as, over time, test cases designed using the same checklist may become less effective at finding defects
Correct Answer: B
B
Explanation:
Checklist-based testing, as defined in the ISTQB CTFL syllabus, is indeed a review technique used within formal review processes. During these reviews, reviewers individually inspect work products to identify defects based on predefined checklists. These checklists serve as guidelines to ensure thorough examination and to cover important aspects consistently.
The other options do not accurately describe the checklist-based testing technique.
Option A describes a technique for managing review meetings rather than the checklist-based testing itself.
Option C incorrectly emphasizes the level of detail in checklists as a factor in reproducibility of test cases, which is not the primary focus of checklist-based testing.
Option D, while true about the necessity of periodic review, is not the core aspect of the checklist-based testing technique itself.
Reference: ISTQB CTFL Syllabus, section on static testing and review techniques.
B
Explanation:
Checklist-based testing, as defined in the ISTQB CTFL syllabus, is indeed a review technique used within formal review processes. During these reviews, reviewers individually inspect work products to identify defects based on predefined checklists. These checklists serve as guidelines to ensure thorough examination and to cover important aspects consistently.
The other options do not accurately describe the checklist-based testing technique.
Option A describes a technique for managing review meetings rather than the checklist-based testing itself.
Option C incorrectly emphasizes the level of detail in checklists as a factor in reproducibility of test cases, which is not the primary focus of checklist-based testing.
Option D, while true about the necessity of periodic review, is not the core aspect of the checklist-based testing technique itself.
Reference: ISTQB CTFL Syllabus, section on static testing and review techniques.
Question #18
Which of the following statements about traceability is false?
- A . Traceability between test basis items and the test cases designed to cover them, makes it possible to determine which test basis items have been covered by the executed test cases
- B . Traceability between test basis items and the test cases designed to cover them, enables experience-based test techniques to be applied
- C . Traceability between test basis items and the test cases designed to cover them, enables identification of which test cases will be affected by changes to the test basis items
- D . Traceability can be established and maintained through all test documentation for a given test level, such as from test conditions through test cases to test scripts
Correct Answer: B
B
Explanation:
Traceability is an essential aspect of software testing that ensures each test case can be traced back to its corresponding test basis items, such as requirements, design documents, or user stories. This linkage helps in determining which test basis items have been covered by executed test cases, identifying the impact of changes, and maintaining overall test documentation. However, the statement that traceability enables experience-based test techniques to be applied is false, as experience-based test techniques, such as exploratory testing, rely on the tester’s skills and experience rather than documented traceability.
Reference: ISTQB® CTFL Syllabus 4.0, Chapter 1.4.4, page 19: Importance of Traceability
B
Explanation:
Traceability is an essential aspect of software testing that ensures each test case can be traced back to its corresponding test basis items, such as requirements, design documents, or user stories. This linkage helps in determining which test basis items have been covered by executed test cases, identifying the impact of changes, and maintaining overall test documentation. However, the statement that traceability enables experience-based test techniques to be applied is false, as experience-based test techniques, such as exploratory testing, rely on the tester’s skills and experience rather than documented traceability.
Reference: ISTQB® CTFL Syllabus 4.0, Chapter 1.4.4, page 19: Importance of Traceability
Question #19
Which of the following statements about the typical activities of a formal review process is true?
- A . Individual review is only mandatory when the size of the work product under review is too large to cover at the review meeting
- B . Various review techniques that may be applied by participants during individual review are described in the ISO/IEC/IEEE 29119-3 standard
- C . Choosing which standards to follow during the review process is usually made during review planning
- D . One of the main goals of the review meeting is to make sure that all participants are aware of their roles and responsibilities in the review process
Correct Answer: C
C
Explanation:
During the review planning phase of a formal review process, decisions are made regarding which standards and procedures will be followed. This planning ensures that the review process is structured, consistent, and aligned with organizational or project-specific guidelines, thereby enhancing the effectiveness and reliability of the review outcomes.
C
Explanation:
During the review planning phase of a formal review process, decisions are made regarding which standards and procedures will be followed. This planning ensures that the review process is structured, consistent, and aligned with organizational or project-specific guidelines, thereby enhancing the effectiveness and reliability of the review outcomes.
Question #20
A software company decides to invest in reviews of various types. The thought process they have is that each artifact needs to be reviewed using only one of the review methods depending on the criticality of the artifact.
- A . The thought process is incorrect. The whole company should adopt same standard for review of all artifacts.
- B . The thought process is correct. The whole company should decide or the review method based on their CMM level.
- C . The thought process is incorrect. Same artifact can be reviewed using different review methods
- D . The thought process is correct. It wastes time to review same artifact using efferent review methods
Correct Answer: C
C
Explanation:
The thought process of the software company is incorrect, because it assumes that each artifact can be reviewed using only one review method, and that the review method depends solely on the criticality of the artifact. This is a simplistic and rigid approach that does not consider the benefits and limitations of different review methods, the context and purpose of the review, and the feedback and improvement opportunities that can be gained from multiple reviews. According to the CTFL 4.0 Syllabus, the selection of review methods should be based on several factors, such as the type and level of detail of the artifact, the availability and competence of the reviewers, the time and budget constraints, the expected defects and risks, and the desired outcomes and quality criteria. Moreover, the same artifact can be reviewed using different review methods at different stages of the development lifecycle, to ensure that the artifact meets the changing requirements, standards, and expectations of the stakeholders.
For example, a requirement specification can be reviewed using an informal review method, such as a walkthrough, to get an initial feedback from the users and developers, and then using a formal review method, such as an inspection, to verify the completeness, correctness, and consistency of the specification. Therefore, the software company should adopt a more flexible and context-sensitive approach to selecting and applying review methods for different artifacts, rather than following a fixed and arbitrary rule.
Reference = CTFL 4.0 Syllabus, Section 3.2.1, page 31-32; Section 3.2.2, page 33-34; Section 3.2.3, page 35-36.
C
Explanation:
The thought process of the software company is incorrect, because it assumes that each artifact can be reviewed using only one review method, and that the review method depends solely on the criticality of the artifact. This is a simplistic and rigid approach that does not consider the benefits and limitations of different review methods, the context and purpose of the review, and the feedback and improvement opportunities that can be gained from multiple reviews. According to the CTFL 4.0 Syllabus, the selection of review methods should be based on several factors, such as the type and level of detail of the artifact, the availability and competence of the reviewers, the time and budget constraints, the expected defects and risks, and the desired outcomes and quality criteria. Moreover, the same artifact can be reviewed using different review methods at different stages of the development lifecycle, to ensure that the artifact meets the changing requirements, standards, and expectations of the stakeholders.
For example, a requirement specification can be reviewed using an informal review method, such as a walkthrough, to get an initial feedback from the users and developers, and then using a formal review method, such as an inspection, to verify the completeness, correctness, and consistency of the specification. Therefore, the software company should adopt a more flexible and context-sensitive approach to selecting and applying review methods for different artifacts, rather than following a fixed and arbitrary rule.
Reference = CTFL 4.0 Syllabus, Section 3.2.1, page 31-32; Section 3.2.2, page 33-34; Section 3.2.3, page 35-36.