Practice Free CTFL_SYLL_4.0 Exam Online Questions
Question #21
Which of the following are the phases of the ISTQB fundamental test process?
- A . Test planning and control, Test analysis and design, Test implementation and execution, Evaluating ex t criteria and reporting. Test closure activities
- B . Test planning, Test analysis and design. Test implementation and control. Checking test coverage and reporting, Test closure activities
- C . Test planning and control, Test specification and design. Test implementation and execution, Evaluating test coverage and reporting, Retesting and regression testing, Test closure activities
- D . Test planning. Test specification and design. Test implementation and execution. Evaluating exit criteria and reporting. Retesting and test closure activities
Correct Answer: A
A
Explanation:
The ISTQB fundamental test process consists of five main phases, as described in the ISTQB Foundation Level Syllabus, Version 4.0, 2018, Section 2.2, page 15:
Test planning and control: This phase involves defining the test objectives, scope, strategy, resources, schedule, risks, and metrics, as well as monitoring and controlling the test activities and results throughout the test process.
Test analysis and design: This phase involves analyzing the test basis (such as requirements, specifications, or user stories) to identify test conditions (such as features, functions, or scenarios) that need to be tested, and designing test cases and test procedures (such as inputs, expected outcomes, and execution steps) to cover the test conditions. This phase also involves evaluating the testability of the test basis and the test items (such as software or system components), and selecting and implementing test techniques (such as equivalence partitioning, boundary value analysis, or state transition testing) to achieve the test objectives and optimize the test coverage and efficiency.
Test implementation and execution: This phase involves preparing the test environment (such as hardware, software, data, or tools) and testware (such as test cases, test procedures, test data, or test scripts) for test execution, and executing the test procedures or scripts according to the test plan and schedule. This phase also involves logging the outcome of test execution, comparing the actual results with the expected results, and reporting any discrepancies as incidents (such as defects, errors, or failures).
Evaluating exit criteria and reporting: This phase involves checking if the planned test activities have been completed and the exit criteria (such as quality, coverage, or risk levels) have been met, and reporting the test results and outcomes to the stakeholders. This phase also involves making recommendations for the release or acceptance decision based on the test results and outcomes, and identifying any residual risks (such as known defects or untested areas) that need to be addressed or mitigated.
Test closure activities: This phase involves finalizing and archiving the testware and test environment for future reuse, and evaluating the test process and the test project against the test objectives and the test plan. This phase also involves identifying any lessons learned and best practices, and communicating the findings and suggestions for improvement to the relevant parties.
Reference = ISTQB Certified Tester Foundation Level Syllabus, Version 4.0, 2018, Section 2.2, page 15; ISTQB Glossary of Testing Terms, Version 4.0, 2018, pages 37-38; ISTQB CTFL 4.0 – Sample Exam – Answers, Version 1.1, 2023, Question 88, page 32.
A
Explanation:
The ISTQB fundamental test process consists of five main phases, as described in the ISTQB Foundation Level Syllabus, Version 4.0, 2018, Section 2.2, page 15:
Test planning and control: This phase involves defining the test objectives, scope, strategy, resources, schedule, risks, and metrics, as well as monitoring and controlling the test activities and results throughout the test process.
Test analysis and design: This phase involves analyzing the test basis (such as requirements, specifications, or user stories) to identify test conditions (such as features, functions, or scenarios) that need to be tested, and designing test cases and test procedures (such as inputs, expected outcomes, and execution steps) to cover the test conditions. This phase also involves evaluating the testability of the test basis and the test items (such as software or system components), and selecting and implementing test techniques (such as equivalence partitioning, boundary value analysis, or state transition testing) to achieve the test objectives and optimize the test coverage and efficiency.
Test implementation and execution: This phase involves preparing the test environment (such as hardware, software, data, or tools) and testware (such as test cases, test procedures, test data, or test scripts) for test execution, and executing the test procedures or scripts according to the test plan and schedule. This phase also involves logging the outcome of test execution, comparing the actual results with the expected results, and reporting any discrepancies as incidents (such as defects, errors, or failures).
Evaluating exit criteria and reporting: This phase involves checking if the planned test activities have been completed and the exit criteria (such as quality, coverage, or risk levels) have been met, and reporting the test results and outcomes to the stakeholders. This phase also involves making recommendations for the release or acceptance decision based on the test results and outcomes, and identifying any residual risks (such as known defects or untested areas) that need to be addressed or mitigated.
Test closure activities: This phase involves finalizing and archiving the testware and test environment for future reuse, and evaluating the test process and the test project against the test objectives and the test plan. This phase also involves identifying any lessons learned and best practices, and communicating the findings and suggestions for improvement to the relevant parties.
Reference = ISTQB Certified Tester Foundation Level Syllabus, Version 4.0, 2018, Section 2.2, page 15; ISTQB Glossary of Testing Terms, Version 4.0, 2018, pages 37-38; ISTQB CTFL 4.0 – Sample Exam – Answers, Version 1.1, 2023, Question 88, page 32.
Question #22
Which ONE of the following statements is correct?
- A . Static analysis can be used against a work product containing unstructured artifacts
- B . Test cases can be tested using static testing techniques but not the models
- C . There may be legal issues in performing static testing on a commercially available executable library.
- D . Difficult to interpret work products are best tested using static analysis.
Correct Answer: C
C
Explanation:
Performing static testing on a commercially available executable library can raise legal issues, primarily related to the ownership and licensing of the software. These libraries are often proprietary, and analyzing them without permission may violate software licenses or intellectual property laws. Static testing typically involves analyzing source code, which may not be accessible for such libraries without appropriate permissions.
Reference: ISTQB CTFL Syllabus V4.0, Section 3.2.2 on legal and ethical considerations in static testing.
C
Explanation:
Performing static testing on a commercially available executable library can raise legal issues, primarily related to the ownership and licensing of the software. These libraries are often proprietary, and analyzing them without permission may violate software licenses or intellectual property laws. Static testing typically involves analyzing source code, which may not be accessible for such libraries without appropriate permissions.
Reference: ISTQB CTFL Syllabus V4.0, Section 3.2.2 on legal and ethical considerations in static testing.
Question #23
The acceptance criteria associated with a user story:
- A . are often written in a rule-oriented format using the template referred to as "Given/When/Then"
- B . are often documented following in rule-oriented format using the following template: "As a [role], I want [feature], so that I can [benefit]"
- C . can be written in different formats and represent an aspect of a user story referred to as confirmation’ of the so called "3 C’s"
- D . must be written in one of the two following formats: scenario-oriented or rule-oriented
Correct Answer: C
C
Explanation:
The acceptance criteria associated with a user story are the conditions that must be met for the user story to be considered done and to deliver the expected value to the user. They are often written in different formats, such as rule-oriented, scenario-oriented, or table-oriented, depending on the nature and complexity of the user story. They represent an aspect of a user story referred to as confirmation, which is one of the so called “3 C’s” of user stories. The other two aspects are card and conversation. Card refers to the concise and informal description of the user story, usually following the template: “As a [role], I want [feature], so that I can [benefit]”. Conversation refers to the ongoing dialogue between the stakeholders and the team members to clarify and refine the user story and its acceptance criteria. Therefore, option C is the correct answer.
Reference: ISTQB® Certified Tester Foundation Level Syllabus v4.01, Section 3.2.2, page 35-36; ISTQB® Glossary v4.02, page 37.
C
Explanation:
The acceptance criteria associated with a user story are the conditions that must be met for the user story to be considered done and to deliver the expected value to the user. They are often written in different formats, such as rule-oriented, scenario-oriented, or table-oriented, depending on the nature and complexity of the user story. They represent an aspect of a user story referred to as confirmation, which is one of the so called “3 C’s” of user stories. The other two aspects are card and conversation. Card refers to the concise and informal description of the user story, usually following the template: “As a [role], I want [feature], so that I can [benefit]”. Conversation refers to the ongoing dialogue between the stakeholders and the team members to clarify and refine the user story and its acceptance criteria. Therefore, option C is the correct answer.
Reference: ISTQB® Certified Tester Foundation Level Syllabus v4.01, Section 3.2.2, page 35-36; ISTQB® Glossary v4.02, page 37.
Question #24
In which of the following test documents would you expect to find test exit criteria described9
- A . Test design specification
- B . Project plan
- C . Requirements specification
- D . Test plan
Correct Answer: D
D
Explanation:
Test exit criteria are the conditions that must be fulfilled before concluding a particular testing phase. These criteria act as a checkpoint to assess whether we have achieved the testing objectives and are done with testing1. Test exit criteria are typically defined in the test plan document, which is one of the outputs of the test planning phase. The test plan document describes the scope, approach, resources, and schedule of the testing activities. It also identifies the test items, the features to be tested, the testing tasks, the risks, and the test deliverables2. According to the ISTQB® Certified Tester Foundation Level Syllabus v4.0, the test plan document should include the following information related to the test exit criteria3:
The criteria for evaluating test completion, such as the percentage of test cases executed, the percentage of test coverage achieved, the number and severity of defects found and fixed, the quality and reliability of the software product, and the stakeholder satisfaction.
The criteria for evaluating test process improvement, such as the adherence to the test strategy, the efficiency and effectiveness of the testing activities, the lessons learned and best practices identified, and the recommendations for future improvements.
Therefore, the test plan document is the most appropriate test document to find the test exit criteria described. The other options, such as test design specification, project plan, and requirements specification, are not directly related to the test exit criteria. The test design specification describes the test cases and test procedures for a specific test level or test type3. The project plan describes the overall objectives, scope, assumptions, risks, and deliverables of the software project4. The requirements specification describes the functional and non-functional requirements of the software product5. None of these documents specify the conditions for ending the testing process or evaluating the testing outcomes. Reference = ISTQB® Certified Tester Foundation Level Syllabus
v4.0, Entry and Exit Criteria in Software Testing | Baeldung on Computer Science, Entry And Exit Criteria In Software Testing – Rishabh Software, Entry and Exit Criteria in Software Testing Life Cycle – STLC [2022 Updated] – Testsigma Blog, ISTQB® releases Certified Tester Foundation Level v4.0 (CTFL).
D
Explanation:
Test exit criteria are the conditions that must be fulfilled before concluding a particular testing phase. These criteria act as a checkpoint to assess whether we have achieved the testing objectives and are done with testing1. Test exit criteria are typically defined in the test plan document, which is one of the outputs of the test planning phase. The test plan document describes the scope, approach, resources, and schedule of the testing activities. It also identifies the test items, the features to be tested, the testing tasks, the risks, and the test deliverables2. According to the ISTQB® Certified Tester Foundation Level Syllabus v4.0, the test plan document should include the following information related to the test exit criteria3:
The criteria for evaluating test completion, such as the percentage of test cases executed, the percentage of test coverage achieved, the number and severity of defects found and fixed, the quality and reliability of the software product, and the stakeholder satisfaction.
The criteria for evaluating test process improvement, such as the adherence to the test strategy, the efficiency and effectiveness of the testing activities, the lessons learned and best practices identified, and the recommendations for future improvements.
Therefore, the test plan document is the most appropriate test document to find the test exit criteria described. The other options, such as test design specification, project plan, and requirements specification, are not directly related to the test exit criteria. The test design specification describes the test cases and test procedures for a specific test level or test type3. The project plan describes the overall objectives, scope, assumptions, risks, and deliverables of the software project4. The requirements specification describes the functional and non-functional requirements of the software product5. None of these documents specify the conditions for ending the testing process or evaluating the testing outcomes. Reference = ISTQB® Certified Tester Foundation Level Syllabus
v4.0, Entry and Exit Criteria in Software Testing | Baeldung on Computer Science, Entry And Exit Criteria In Software Testing – Rishabh Software, Entry and Exit Criteria in Software Testing Life Cycle – STLC [2022 Updated] – Testsigma Blog, ISTQB® releases Certified Tester Foundation Level v4.0 (CTFL).
Question #25
Consider the following user story about an e-commerce website’s registration feature that only allows registered users to make purchases:
“As a new user, I want to register to the website, so that I can start shopping online”
The following are some of the acceptance criteria defined for the user story:
[a] The registration form consists of the following fields: username, email address, first name, last name, date of birth, password and repeat password
[b] To submit the registration request, the new user must fill in all the fields of the registration form with valid values and must agree to the terms and conditions
[c] To be valid, the email address must not be provided by free online mail services that allow to create disposable email addresses. A dedicated error message must be presented to inform the new user when an invalid address is entered
[d] To be valid, the first name and last name must contain only alphabetic characters and must be between 2 and 80 characters long. A dedicated error message must be presented to inform the new user when an invalid first name and/or the last name is entered
[e] After submitting the registration request, the new user must receive an e-mail containing the confirmation link to the e-mail address specified in the registration form
Based only on the given information, which of the following ATDD tests is most likely to be written first?
- A . The new user enters valid values in the fields of the registration form, except for the email address, where he/she enters an e-mail address provided by a free online mail service that allow to create disposable email addresses. Then he/she is informed by the website about this issue
- B . The new user enters valid values in the fields of the registration form, except for the first name, where he/she enters a first name with 10 characters that contains a number. Then he/she is informed by the website about this issue
- C . The user accesses the website with username and password, and successfully places a purchase order for five items, paying by Mastercard credit card EV
- D . The new user enters valid values in all the fields of the registration form, confirms to accept all the terms and conditions, submits the registration request and then receives an e-mail containing the confirmation link to the e-mail address specified in the registration form
Correct Answer: D
D
Explanation:
Based on the given user story and acceptance criteria, the ATDD (Acceptance Test-Driven Development) approach focuses on defining acceptance tests before development begins. The first test written typically covers the "happy path" or the most straightforward scenario to ensure the primary functionality works as expected.
Given Acceptance Criteria:
The registration form must be filled with valid values.
The user must accept terms and conditions.
An email with a confirmation link must be sent after submission.
The most likely first ATDD test would ensure that a new user can successfully register by filling in all fields with valid data and confirming the registration through an email link. This ensures that the basic and most crucial functionality of the registration feature is working correctly before handling edge cases or error conditions.
Reference: ISTQB CTFL Syllabus Section 2.3 on acceptance test-driven development (ATDD).
D
Explanation:
Based on the given user story and acceptance criteria, the ATDD (Acceptance Test-Driven Development) approach focuses on defining acceptance tests before development begins. The first test written typically covers the "happy path" or the most straightforward scenario to ensure the primary functionality works as expected.
Given Acceptance Criteria:
The registration form must be filled with valid values.
The user must accept terms and conditions.
An email with a confirmation link must be sent after submission.
The most likely first ATDD test would ensure that a new user can successfully register by filling in all fields with valid data and confirming the registration through an email link. This ensures that the basic and most crucial functionality of the registration feature is working correctly before handling edge cases or error conditions.
Reference: ISTQB CTFL Syllabus Section 2.3 on acceptance test-driven development (ATDD).
Question #26
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
Correct Answer: D
D
Explanation:
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 is 4.
This is because there are 4 unique sequences of up to 3 states/2 transitions starting in the “Start” state and ending in the “End” state:
Start -> Bet -> End
Start -> Deal -> End
Start -> 1st Deal -> End
Start -> 2nd Deal -> End
Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents.
D
Explanation:
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 is 4.
This is because there are 4 unique sequences of up to 3 states/2 transitions starting in the “Start” state and ending in the “End” state:
Start -> Bet -> End
Start -> Deal -> End
Start -> 1st Deal -> End
Start -> 2nd Deal -> End
Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents.
Question #27
Which of the following applications will be the MOST suitable for testing by Use Cases
- A . Accuracy and usability of a new Navigation system compared with previous system
- B . A billing system used to calculate monthly charge based or large number of subscribers parameters
- C . The ability of an Anti virus package to detect and quarantine a new threat
- D . Suitability and performance of a Multi media (audio video based) system to a new operating system
Correct Answer: A
A
Explanation:
A new navigation system compared with a previous system is the most suitable application for testing by use cases, because it involves a high level of interaction between the user and the system, and the expected behavior and outcomes of the system are based on the user’s needs and goals. Use cases can help to specify the functional requirements of the new navigation system, such as the ability to enter a destination, select a route, follow the directions, receive alerts, etc. Use cases can also help to compare the accuracy and usability of the new system with the previous system, by defining the success and failure scenarios, the preconditions and postconditions, and the alternative flows of each use case. Use cases can also help to design and execute test cases that cover the main and exceptional paths of each use case, and to verify the satisfaction of the user’s expectations.
The other options are not the most suitable applications for testing by use cases, because they do not involve a high level of interaction between the user and the system, or the expected behavior and outcomes of the system are not based on the user’s needs and goals. A billing system used to calculate monthly charge based on a large number of subscriber parameters is more suitable for testing by data-driven testing, which is a technique for testing the functionality and performance of a system or component by using a large set of input and output data. The ability of an antivirus package to detect and quarantine a new threat is more suitable for testing by exploratory testing, which is a technique for testing the functionality and security of a system or component by using an informal and flexible approach, based on the tester’s experience and intuition. The suitability and performance of a multimedia (audio video based) system to a new operating system is more suitable for testing by compatibility testing, which is a technique for testing the functionality and performance of a system or component by using different hardware, software, or network environments.
Reference = CTFL 4.0 Syllabus, Section 3.1.1, page 28-29; Section 4.1.1, page 44-45; Section 4.2.1, page 47-48.
A
Explanation:
A new navigation system compared with a previous system is the most suitable application for testing by use cases, because it involves a high level of interaction between the user and the system, and the expected behavior and outcomes of the system are based on the user’s needs and goals. Use cases can help to specify the functional requirements of the new navigation system, such as the ability to enter a destination, select a route, follow the directions, receive alerts, etc. Use cases can also help to compare the accuracy and usability of the new system with the previous system, by defining the success and failure scenarios, the preconditions and postconditions, and the alternative flows of each use case. Use cases can also help to design and execute test cases that cover the main and exceptional paths of each use case, and to verify the satisfaction of the user’s expectations.
The other options are not the most suitable applications for testing by use cases, because they do not involve a high level of interaction between the user and the system, or the expected behavior and outcomes of the system are not based on the user’s needs and goals. A billing system used to calculate monthly charge based on a large number of subscriber parameters is more suitable for testing by data-driven testing, which is a technique for testing the functionality and performance of a system or component by using a large set of input and output data. The ability of an antivirus package to detect and quarantine a new threat is more suitable for testing by exploratory testing, which is a technique for testing the functionality and security of a system or component by using an informal and flexible approach, based on the tester’s experience and intuition. The suitability and performance of a multimedia (audio video based) system to a new operating system is more suitable for testing by compatibility testing, which is a technique for testing the functionality and performance of a system or component by using different hardware, software, or network environments.
Reference = CTFL 4.0 Syllabus, Section 3.1.1, page 28-29; Section 4.1.1, page 44-45; Section 4.2.1, page 47-48.
Question #28
Which of the following is a test task that usually occurs during test implementation?
- A . Make sure the planned test environment is ready to be delivered
- B . Find, analyze, and remove the causes of the failures highlighted by the tests
- C . Archive the testware for use in future test projects
- D . Gather the metrics that are used to guide the test project
Correct Answer: A
A
Explanation:
A test task that usually occurs during test implementation is to make sure the planned test environment is ready to be delivered. The test environment is the hardware and software configuration on which the tests are executed, and it should be as close as possible to the production environment where the software system will operate. The test environment should be planned, prepared, and verified before the test execution, to ensure that the test conditions, the test data, the test tools, and the test interfaces are available and functional.
The other options are not test tasks that usually occur during test implementation, but rather test tasks that occur during other test activities, such as:
Find, analyze, and remove the causes of the failures highlighted by the tests: This is a test task that usually occurs during test analysis and design, which is the activity of analyzing the test basis, designing the test cases, and identifying the test data. During this activity, the testers can use techniques such as root cause analysis, defect prevention, or defect analysis, to find, analyze, and remove the causes of the failures highlighted by the previous tests, and to prevent or reduce the occurrence of similar failures in the future tests.
Archive the testware for use in future test projects: This is a test task that usually occurs during test closure, which is the activity of finalizing and reporting the test results, evaluating the test process, and identifying the test improvement actions. During this activity, the testers can archive the testware, which are the test artifacts produced during the testing process, such as the test plan, the test cases, the test data, the test results, the defect reports, etc., for use in future test projects, such as regression testing, maintenance testing, or reuse testing.
Gather the metrics that are used to guide the test project: This is a test task that usually occurs during test monitoring and control, which is the activity of tracking and reviewing the test progress, status, and quality, and taking corrective actions when necessary. During this activity, the testers can gather the metrics, which are the measurements of the testing process, such as the test coverage, the defect density, the test effort, the test duration, etc., that are used to guide the test project, such as planning, estimating, scheduling, reporting, or improving the testing process.
Reference:
ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.1, Test Planning1
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.2, Test Monitoring and Control1
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.3, Test Analysis and Design1
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.4, Test Implementation1
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.5, Test Execution1
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.6, Test Closure1
ISTQB® Glossary of Testing Terms v4.0, Test Environment, Test Condition, Test Data, Test Tool, Test Interface, Failure, Root Cause Analysis, Defect Prevention, Defect Analysis, Testware, Regression Testing, Maintenance Testing, Reuse Testing, Test Coverage, Defect Density, Test Effort, Test Duration2
A
Explanation:
A test task that usually occurs during test implementation is to make sure the planned test environment is ready to be delivered. The test environment is the hardware and software configuration on which the tests are executed, and it should be as close as possible to the production environment where the software system will operate. The test environment should be planned, prepared, and verified before the test execution, to ensure that the test conditions, the test data, the test tools, and the test interfaces are available and functional.
The other options are not test tasks that usually occur during test implementation, but rather test tasks that occur during other test activities, such as:
Find, analyze, and remove the causes of the failures highlighted by the tests: This is a test task that usually occurs during test analysis and design, which is the activity of analyzing the test basis, designing the test cases, and identifying the test data. During this activity, the testers can use techniques such as root cause analysis, defect prevention, or defect analysis, to find, analyze, and remove the causes of the failures highlighted by the previous tests, and to prevent or reduce the occurrence of similar failures in the future tests.
Archive the testware for use in future test projects: This is a test task that usually occurs during test closure, which is the activity of finalizing and reporting the test results, evaluating the test process, and identifying the test improvement actions. During this activity, the testers can archive the testware, which are the test artifacts produced during the testing process, such as the test plan, the test cases, the test data, the test results, the defect reports, etc., for use in future test projects, such as regression testing, maintenance testing, or reuse testing.
Gather the metrics that are used to guide the test project: This is a test task that usually occurs during test monitoring and control, which is the activity of tracking and reviewing the test progress, status, and quality, and taking corrective actions when necessary. During this activity, the testers can gather the metrics, which are the measurements of the testing process, such as the test coverage, the defect density, the test effort, the test duration, etc., that are used to guide the test project, such as planning, estimating, scheduling, reporting, or improving the testing process.
Reference:
ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.1, Test Planning1
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.2, Test Monitoring and Control1
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.3, Test Analysis and Design1
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.4, Test Implementation1
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.5, Test Execution1
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.6, Test Closure1
ISTQB® Glossary of Testing Terms v4.0, Test Environment, Test Condition, Test Data, Test Tool, Test Interface, Failure, Root Cause Analysis, Defect Prevention, Defect Analysis, Testware, Regression Testing, Maintenance Testing, Reuse Testing, Test Coverage, Defect Density, Test Effort, Test Duration2
Question #29
An application is subjected to a constant load for an extended period of time as part of a performance test. While running this test, the response time of the application steadily slows down, which results in a requirement not being met. This slowdown is caused by a memory leak where the application code does not properly release some of the dynamically allocated memory when it is no longer needed.
Which of the following statements is true?
- A . The slowdown is a failure while the memory leak is a defect
- B . The slowdown is a defect while the memory leak is an error
- C . The slowdown is an error the memory leak is a defect
- D . The slowdown is a defect the memory leak is a failure
Correct Answer: A
A
Explanation:
In the ISTQB terminology:
A defect (also known as a bug or fault) is an issue in the code that can cause a failure.
A failure is the observable incorrect behavior or output of the software due to a defect.
In this scenario, the memory leak is the defect in the application code that causes the application not to release dynamically allocated memory properly. The observable effect of this defect, which is the slowdown in response time, is considered a failure because it is the manifestation of the defect that prevents the application from meeting its performance requirements.
A
Explanation:
In the ISTQB terminology:
A defect (also known as a bug or fault) is an issue in the code that can cause a failure.
A failure is the observable incorrect behavior or output of the software due to a defect.
In this scenario, the memory leak is the defect in the application code that causes the application not to release dynamically allocated memory properly. The observable effect of this defect, which is the slowdown in response time, is considered a failure because it is the manifestation of the defect that prevents the application from meeting its performance requirements.
Question #30
Which of the following statements about branch coverage is true?
- A . The minimum number of test cases needed to achieve full branch coverage, is usually lower than that needed to achieve full statement coverage
- B . If full branch coverage has been achieved, then all unconditional branches within the code have surely been exercised
- C . If full branch coverage has been achieved, then all combinations of conditions in a decision table have surely been exercised
- D . Exercising at least one of the decision outcomes for all decisions within the code, ensures achieving full branch coverage
Correct Answer: D
D
Explanation:
Exercising at least one of the decision outcomes for all decisions within the code, ensures achieving full branch coverage, which is a test coverage criterion that requires that all branches in the control flow of the code are executed at least once by the test cases. A branch is a basic block of code that has a single entry point and a single exit point, and a decision is a point in the code where the control flow can take more than one direction, such as an if-then-else statement, a switch-case statement, a loop statement, etc. The decision outcomes are the possible paths that can be taken from a decision, such as the then branch or the else branch, the case branch or the default branch, the loop body or the loop exit, etc.
The other statements are false, because:
The minimum number of test cases needed to achieve full branch coverage, is usually higher than that needed to achieve full statement coverage, which is a test coverage criterion that requires that all executable statements in the code are executed at least once by the test cases. This is because branch coverage is a stronger criterion than statement coverage, as it implies statement coverage, but not vice versa. For example, a single test case can achieve full statement coverage for an if-then-else statement, but two test cases are needed to achieve full branch coverage, as both the then branch and the else branch need to be exercised.
If full branch coverage has been achieved, then all unconditional branches within the code have not necessarily been exercised, as unconditional branches are branches that do not depend on any decision, and are always executed, such as a goto statement, a break statement, a return statement, etc. Unconditional branches are not part of the branch coverage criterion, as they do not represent different paths in the control flow of the code. However, they are part of the statement coverage criterion, as they are executable statements in the code.
If full branch coverage has been achieved, then all combinations of conditions in a decision table have not necessarily been exercised, as a decision table is a test design technique that represents the logical relationships between multiple conditions and their corresponding actions, in a tabular format. A decision table can have more combinations of conditions than the number of decision outcomes in the code, as each condition can have two or more possible values, such as true or false, yes or no, etc. For example, a decision table with four conditions can have 16 combinations of conditions, but the corresponding code may have only two decision outcomes, such as pass or fail. To exercise all combinations of conditions in a decision table, a stronger test coverage criterion is needed, such as condition combination coverage, which requires that all possible combinations of condition outcomes in the code are executed at least once by the test cases.
Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.3.1, Test Coverage Criteria Based on the Structure of the Software
ISTQB® Glossary of Testing Terms v4.0, Branch Coverage, Statement Coverage, Branch, Decision, Decision Outcome, Unconditional Branch, Decision Table, Condition Combination Coverage
D
Explanation:
Exercising at least one of the decision outcomes for all decisions within the code, ensures achieving full branch coverage, which is a test coverage criterion that requires that all branches in the control flow of the code are executed at least once by the test cases. A branch is a basic block of code that has a single entry point and a single exit point, and a decision is a point in the code where the control flow can take more than one direction, such as an if-then-else statement, a switch-case statement, a loop statement, etc. The decision outcomes are the possible paths that can be taken from a decision, such as the then branch or the else branch, the case branch or the default branch, the loop body or the loop exit, etc.
The other statements are false, because:
The minimum number of test cases needed to achieve full branch coverage, is usually higher than that needed to achieve full statement coverage, which is a test coverage criterion that requires that all executable statements in the code are executed at least once by the test cases. This is because branch coverage is a stronger criterion than statement coverage, as it implies statement coverage, but not vice versa. For example, a single test case can achieve full statement coverage for an if-then-else statement, but two test cases are needed to achieve full branch coverage, as both the then branch and the else branch need to be exercised.
If full branch coverage has been achieved, then all unconditional branches within the code have not necessarily been exercised, as unconditional branches are branches that do not depend on any decision, and are always executed, such as a goto statement, a break statement, a return statement, etc. Unconditional branches are not part of the branch coverage criterion, as they do not represent different paths in the control flow of the code. However, they are part of the statement coverage criterion, as they are executable statements in the code.
If full branch coverage has been achieved, then all combinations of conditions in a decision table have not necessarily been exercised, as a decision table is a test design technique that represents the logical relationships between multiple conditions and their corresponding actions, in a tabular format. A decision table can have more combinations of conditions than the number of decision outcomes in the code, as each condition can have two or more possible values, such as true or false, yes or no, etc. For example, a decision table with four conditions can have 16 combinations of conditions, but the corresponding code may have only two decision outcomes, such as pass or fail. To exercise all combinations of conditions in a decision table, a stronger test coverage criterion is needed, such as condition combination coverage, which requires that all possible combinations of condition outcomes in the code are executed at least once by the test cases.
Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.3.1, Test Coverage Criteria Based on the Structure of the Software
ISTQB® Glossary of Testing Terms v4.0, Branch Coverage, Statement Coverage, Branch, Decision, Decision Outcome, Unconditional Branch, Decision Table, Condition Combination Coverage