The Renovate Guide To CTFL4 Preparation Labs

NEW QUESTION 1
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

Answer: 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 requirementsspecification 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. References = ISTQB® Certified Tester Foundation Level Syllabus v4.0, Entry and Exit Criteria in Software Testing | Baeldung onComputer 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).

NEW QUESTION 2
What type of testing measures its effectiveness by tracking which lines of code were executed by the tests?

• A. Acceptance testing
• B. Structural testing
• C. Integration testing
• D. Exploratory testing

Answer: B

Explanation:
Structural testing is a type of testing that measures its effectiveness by tracking which lines of code were executed by the tests. Structural testing, also known as white-box testing or glass-box testing, is based on the internal structure, design, or implementation of the software. Structural testing aims to verify that the software meets the specified quality attributes, such as performance, security, reliability, or maintainability, by exercising the code paths, branches, statements, conditions, or data flows. Structural testing uses various coverage metrics, such as function coverage, line coverage, branch coverage, or statement coverage, to determine how much of the code has been tested and to identify any untested or unreachable parts of the code. Structural testing can be applied at any level of testing, such as unit testing, integration testing, system testing, or acceptance testing, but it is more commonly used at lower levels, where the testers have access to the source code.
The other options are not correct because they are not types of testing that measure their effectiveness by tracking which lines of code were executed by the tests. Acceptance testing is a type of testing that verifies that the software meets the acceptance criteria and the user requirements. Acceptance testing is usually performed by the end-users or customers, who may not have access to the source code or the technical details of the software. Acceptance testing is more concerned with the functionality, usability, or suitability of the software, rather than its internal structure or implementation. Integration testing is a type of testing that verifies that the software components or subsystems work together as expected. Integration testing is usually performed by the developers or testers, who may use both structural and functional testing techniques to check the interfaces, interactions, or dependencies between the componentsor subsystems. Integration testing is more concerned with the integration logic, data flow, or communication of the software, rather than its individual lines of code. Exploratory testing is a type of testing that involves simultaneous learning, test design, and test execution. Exploratory testing is usually performed by the testers, who use their creativity, intuition, or experience to explore the software and discover any defects, risks, or opportunities for improvement. Exploratory testing is more concerned with the behavior, quality, or value of the software, rather than its internal structure or implementation. References = ISTQB Certified Tester Foundation Level (CTFL) v4.0 syllabus, Chapter 4: Test Techniques, Section 4.3: Structural Testing Techniques, Pages 51-54; Chapter 1: Fundamentals of Testing, Section 1.4: Testing Throughout the Software Development Lifecycle, Pages 11-13; Chapter 3: Static Testing, Section 3.4: Exploratory Testing, Pages 40-41.

NEW QUESTION 3
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

Answer: 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. References = 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.

NEW QUESTION 4
Exploratory testing is an experience-based test technique

• A. Where a developer and a tester work together on the same workstation while the developer actively writes code, the tester explores the code to find defects.
• B. That can be organised into sessions guided by test charters outlining test objectives that will guide the testers' exploration
• C. Where a team of testers explores all possible test techniques in order to determine the most suitable combination of these techniques to apply for a test project.
• D. That aims at finding defects by designing tests that exercise all possible combinations ofinput values and preconditions

Answer: B

Explanation:
Exploratory testing is an experience-based test technique where testers actively engage with the software, learning about its behavior while simultaneously designing and executing tests. According to the ISTQB CTFL syllabus, exploratory testing can be structured into sessions guided by test charters, which outline the test objectives and provide direction for the testers' exploration. This method is particularly useful in situations where test documentation is limited or where rapid feedback is needed. Thus, option B correctly describes how exploratory testing can be organized.

NEW QUESTION 5
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

Answer: 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. References = 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.

NEW QUESTION 6
The following rules determine the annual bonus to be paid to a salesman of a company based on the total annual amount of the sales made (referred to as TAS).
If the TAS is between 50k€ and 80k€, the bonus is 10%. If the TAS exceeds 80k€ by a value not greater than 40k€, the bonus is 15%. Finally, if the TAS exceeds the maximum threshold which entitles to a 15% bonus, the bonus is 22%. Consider applying equivalence partitioning to the TAS (Note: 1k€ = 1000 euros). Which one of the following answers contain only test cases that belong to the same equivalence partition?

• A. TC1 = 81 k€ TC2= 97k€ TC3=111k€ TC4=118k€
• B. TC1 = 40k€ TC2= 46k€ TC3=51k€ TC4=53k€
• C. TC1 = 79k€ TC2= 80k€ TC3=81k€ TC4=82k€
• D. TC1 = 90k€ TC2= 110k€ TC3=125k€: TC4=140k€

Answer: A

Explanation:
This answer is correct because equivalence partitioning is a test design technique that divides the input domain of a system or component into partitions of equivalent data, such that each partition is expected to produce the same output or behavior. Equivalence partitioning aims to reduce the number of test cases by selecting one representative value from each partition. In this case, the input domain of the TAS can be divided into four partitions based on the bonus rules: less than 50k€, between 50k€ and 80k€, between 80k€ and 120k€, and more than 120k€. The test cases in the answer belong to the same partition, which is between 80k€ and 120k€, and they are expected to produce the same output, which is a bonus of 15%. References: ISTQB Glossary of Testing Terms v4.0, ISTQB Foundation Level Syllabus v4.0, Section 2.3.2.1

NEW QUESTION 7
Which of the following statements is NOT true about Configuration management and software testing?

• A. Configuration management helps maintain consistent versions of software artifacts.
• B. Configuration management supports the build process, which is essential for delivering a test release into the test environment.
• C. When testers report defects, they need to reference version-controlled items.
• D. Version controlled test ware increases the chances of finding defects in the software under test.

Answer: D

Explanation:
Reference:ISTQB CTFL Syllabus V4.0, Section 5.4

NEW QUESTION 8
A program is used to control a manufacturing line (turn machines on and off. start and stop conveyer belts, add raw materials to the flow. etc.). Not all actions are possible at all times. For example, there are certain manufacturing stages that cannot be stopped - unless there is an emergency. A tester attempts to evaluate if all such cases (where a specific action is not allowed) are covered by the tests.
Which coverage metric will provide the needed information for this analysis?

• A. Code coverage
• B. Data flow coverage
• C. Statement coverage
• D. Branch Coverage

Answer: D

Explanation:
Branch coverage is a type of structural coverage metric that measures the percentage of branches or decision outcomes that are executed by the test cases. A branch is a point in the code where the control flow can take two or more alternative paths based on a condition. For example, an if-else statement is a branch that can execute either the if-block or the else-block depending on the evaluation of the condition. Branch coverage ensures that each branch is taken at least once by the test cases, and thus reveals the behavior of the software under different scenarios. Branch coverage is also known as decision coverage or all-edges coverage.
Branch coverage is suitable for testing the cases where a specific action is not allowed, because it can verify that the test cases cover all the possible outcomes of the conditions that determine the action. For example, if the program has a condition that checks if the manufacturing stage can be stopped, then branch coverage can ensure that the test cases cover both the cases where the stage can be stopped and where it cannot be stopped. This way, branch coverage can help identify any missing or incorrect branches that may lead to undesired or unsafe actions.
The other options are not correct because they are not suitable for testing the cases where a specific action is not allowed. Code coverage is a general term that encompasses various types of coverage metrics, such as statement coverage, branch coverage, data flow coverage, etc. Code coverage does not specify which type of coverage metric is used for the analysis. Data flow coverage is a type of structural coverage metric that measures the percentage of data flow paths that are executed by the test cases. A data flow path is a sequence of statements that define, use, or kill a variable. Data flow coverage is useful for testing the correctness and completeness of the data manipulation in the software, but not for testing the conditions that determine the actions. Statement coverage is a type of structural coverage metric that measures the percentage of statements or lines of code that are executed by the test cases. Statement coverage ensures that each statement is executed at least once by the test cases, but it does not reveal the behavior of the software under different scenarios. Statement coverage isa weaker criterion than branch coverage, because it does not account for the branches or decision outcomes in the code. References = ISTQB Certified Tester Foundation Level (CTFL) v4.0 syllabus, Chapter 4: Test Techniques, Section 4.3: Structural Testing Techniques, Pages 51-54.

NEW QUESTION 9
Which of the following best describes the way in which statement coverage is measured?

• A. Measured as the number of decision outcomes executed by the tests, divided by the total number of decision outcomes in the test object.
• B. It is not possible to accurately measure statement coverage.
• C. Measured as the number of statements executed by the tests, divided by the total number of executable statements in the code.
• D. Measured as the number of lines of code executed by the test, divided by the total number of lines of code in the test object.

Answer: C

Explanation:
Statement coverage is a metric used in white-box testing that measures the percentage of executable statements in the code that have been executed by the test cases. It is calculated as the number of statements executed by the tests divided by the total number of executable statements in the code, providing an indication of how much of the code has been tested.

NEW QUESTION 10
A typical objective of testing is to ensure that:

• A. testing is used to drive the development of a software
• B. a software has been tested using a combination of test techniques
• C. there are no defects in a software that is about to be released
• D. a software has been properly covered

Answer: B

Explanation:
This answer is correct because a typical objective of testing is to ensure that a software has been tested using a combination of test techniques, such as black-box, white-box, or experience-based techniques, that are appropriate for the test objectives, test levels, and test types. Testing using a combination of test techniques can increase the effectiveness and efficiency of testing, as different techniques can target different aspects of the software quality, such as functionality, usability, performance, security, reliability, etc. Testing using a combination of test techniques can also reduce the risk of missing defects that could be detected by one technique but not by another. References: ISTQB Foundation Level Syllabus v4.0, Section 2.3.1.1, Section 2.3.2

NEW QUESTION 11
You are testing a system that is used in motor vehicles to warn the driver of an obstacle when re-versing. Output is provided by a series of LED lights (green, yellow, and red), each illuminated based on clearly defined conditions.
The following summary describes the functionality:
•Object within 10 metres, green LED lit.
•Object within 5 metres, yellow LED lit.
•Object within 1 metre, red LED lit.
•Setting sensitivity mode to "ON" will result in only the red LED being lit when the object is within 1 metre.
The following decision table describes the rules associated with the functioning of this proximity warning system:

Which intended functionality is tested by Rule 5 in the decision table?

• A. Object is within 5 metres of the vehicle and the sensitivity mode is switched "off", resulting in the yellow LED being lit.
• B. Object is within 5 metres of the vehicle and the sensitivity mode is switched "on", resulting in the yellow LED being lit.
• C. Object is within 5 metres of the vehicle and the sensitivity mode is switched "off", resulting in no LED being lit.
• D. Object is within 5 metres of the vehicle and the sensitivity mode is switched "on", resulting in no LED being lit.

Answer: D

Explanation:
Rule 5 in the decision table indicates that when the object is within 5 metres of the vehicle and the sensitivity mode is switched "on", no LED is lit. This matches the conditions and actions described in the decision table provided, ensuring that only the red LED is lit when the sensitivity mode is on and the object is within 1 metre, otherwise no LED is lit .

NEW QUESTION 12
Which of the following issues cannot be identified by static analysis tools?

• A. Very low MTBF (Mean Time Between failure)
• B. Potentially endless loops
• C. Referencing a variable with an undefined value
• D. Security vulnerabilities

Answer: A

Explanation:
Static analysis tools are software tools that examine the source code of a program without executing it. They can detect various types of issues, such as syntax errors, coding standardsviolations, security vulnerabilities, and potential bugs12. However, static analysis tools cannot identify issues that depend on the runtime behavior or performance of the program, such as very low MTBF (Mean Time Between failure)3. MTBF is a measure of the reliability of a system or component. It is calculated by dividing the total operating time by the number of failures. MTBF reflects how often a system or component fails during its expected lifetime. Static analysis tools cannot measure MTBF because they do not run the program or observe its failures. MTBF can only be estimated by dynamic testing, which involves executing the program under various conditions and collecting data on its failures4. Therefore, very low MTBF is an issue that cannot be identified by static analysis tools. The other options, such as potentially endless loops, referencing a variable with an undefined value, and security vulnerabilities, are issues that can be identified by static analysis tools. Static analysis tools can detect potentially endless loops by analyzing the control flow and data flow of the program and checking for conditions that may never become false5. Static analysis tools can detect referencing a variable with an undefined value by checking the scope and initialization of variables and reporting any use of uninitialized variables6. Static analysis tools can detect security vulnerabilities by checking for common patterns of insecure code, such as buffer overflows, SQL injections, cross-site scripting, and weak encryption. References = What Is Static Analysis? Static Code Analysis Tools - Perforce Software, How Static Code Analysis Works | Perforce, Static CodeAnalysis: Techniques, Top 5 Benefits & 3 Challenges, What is MTBF? Mean Time Between Failures Explained | Perforce, Static analysis tools - Software Testing MCQs - CareerRide, ISTQB_Chapter3 | Quizizz, [Static Code Analysis for Security Vulnerabilities | Perforce].

NEW QUESTION 13
Testing Quadrants, as a model, is effective in aligning stakeholders within Agile teams. Which of the following examples demonstrates this?

• A. Using Testing Quadrants, the test manager is able to measure and communicate test coverage to all stakeholders.
• B. Using Testing Quadrants, the test manager is able to communicate potential product risk to all stakeholders.
• C. Using Testing Quadrant, the test manager is able to prioritize defects by linking these to a specific type of test.
• D. Using Testing Quadrants, the test manager is able to differentiate and describe the types of tests to all stakeholders.

Answer: D

Explanation:
The Testing Quadrants model helps Agile teams by categorizing different types of tests and their purposes. This differentiation helps test managers explain the testing strategy to all stakeholders, ensuring everyone understands the scope and objectives of each test type. This model aids in planning, executing, and tracking testing activities across different quadrants, making it easier to align with stakeholders' expectations and project goals.Reference:ISTQB CTFL Syllabus V4.0, Section 5.1.7

NEW QUESTION 14
Which ONE of the following statements does NOT describe how testing contributes to higher quality?

• A. Properly designed tests that pass reduce the level of risk in a system.
• B. The testing of software demonstrates the absence of defects.
• C. Software testing identifies defects, which can be used to improve development activities.
• D. Performing a review of the requirement specifications before implementing the system can enhance quality.

Answer: B

Explanation:
✑ The testing of software does not demonstrate the absence of defects, but rather the presence of defects or the conformance of the software to the specified requirements1. Testingcan never prove that the software is defect-free, as it is impossible to test all possible scenarios, inputs, outputs, and behaviors of the software2. Testing can only provide a level of confidence inthe quality of the software, based on the coverage, effectiveness, and efficiency of the testing activities3.
✑ The other options are correct because: References =
✑ 1 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 10
✑ 2 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 11
✑ 3 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 12
✑ 4 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 13
✑ 5 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 97
✑ 6 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 98
✑ 7 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 14
✑ [8] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 15
✑ [9] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 16
✑ [10] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 17
✑ [11] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 18
✑ [12] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 19

NEW QUESTION 15
The fact that defects are usually not evenly distributed among the various modules that make up a software application, but rather their distribution tend to reflect the Pareto principle:

• A. is a false myth
• B. is expressed by the testing principle referred to as Tests wear out'
• C. is expressed by the testing principle referred to as 'Defects cluster together'
• D. is expressed by the testing principle referred to as 'Bug prediction'

Answer: C

Explanation:
The fact that defects are usually not evenly distributed among the various modules that make up a software application, but rather their distribution tend to reflect the Pareto principle, is expressed by the testing principle referred to as ??Defects cluster together??. This principle states that a small number of modules contain most of the defects detected, or that a small number of causes are responsible for most of the defects. This principle can be used to guide the test analysis and design activities, by prioritizing the testing of the most critical or risky modules, or by applying more rigorous test techniques to them. Therefore, option C is the correct answer.
References: ISTQB® Certified Tester Foundation Level Syllabus v4.01, Section 1.2.1, page 11; ISTQB® Glossary v4.02, page 16.

NEW QUESTION 16
Which of the following statements best describes the way in which decision coverage is measured?

• A. Measured as the number of statements executed by the tests, divided by the total number of executable statements in the code.
• B. Measured as the number of lines of code executed by the tests, divided by the total number of lines of code in the test object.
• C. Measured as the number of decision outcomes executed by the tests, divided by the total number of decision outcomes in the test object.
• D. It is not possible to accurately measure decision coverage.

Answer: C

Explanation:
Reference:ISTQB CTFL Syllabus V4.0, Section 4.3.2

NEW QUESTION 17
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.

Answer: C

Explanation:
A typical test plan includes various elements, such as resource requirements, test completion criteria, and suspension/resumption criteria. However, the list of product risks that have not been fully mitigated is generally not included in the test plan but rather in the risk management documentation.
✑ The test plan focuses on planning and executing tests, including resource
allocation and defining criteria for test suspension and resumption.
✑ While risk management is crucial, unmitigated risks are typically documented in risk logs or separate risk management plans.
Reference: ISTQB CTFL Syllabus V4.0, Chapter 5.1.1, Test Planning.

NEW QUESTION 18
Confirmation testing is performed after:

• A. a defect is fixed and after other tests do not find any side-effect introduced in the software as a result of such fix
• B. a failed test, and aims to run that test again to confirm that the same behavior still occurs and thus appears to be reproducible
• C. the execution of an automated regression test suite to confirm the absence of false positives in the test results
• D. a defect is fixed, and if such testing is successful then the regression tests that are relevant for such fix can be executed

Answer: D

Explanation:
Confirmation testing is performed after a defect is fixed, and if such testing is successful then the regression tests that are relevant for such fix can be executed. Confirmation testing, also known as re-testing, is the process of verifying that a defect has been resolved by running the test case that originally detected the defect. Confirmation testing is usually done before regression testing, which is the process of verifying that no new defects have been introduced in the software as a result of changes or fixes. Therefore, option D is the correct answer.
References: ISTQB® Certified Tester Foundation Level Syllabus v4.01, Section 2.4.1, page 28; ISTQB® Glossary v4.02, page 15.

NEW QUESTION 19
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

Answer: 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.
References: ISTQB® Certified Tester Foundation Level Syllabus v4.01, Section 3.2.2, page 35-36; ISTQB® Glossary v4.02, page 37.

NEW QUESTION 20
Which of the following statements refers to good testing practice to be applied regardless of the chosen software development model?

• A. Tests should be written in executable format before the code is written and should act as executable specifications that drive coding
• B. Test levels should be defined such that the exit criteria of one level are part of the entry criteria for the next level
• C. Test objectives should be the same for all test levels, although the number of tests designed at various levels can vary significantly
• D. Involvement of testers in work product reviews should occur as early as possible to take advantage of the early testing principle

Answer: D

Explanation:
The statement that refers to good testing practice to be applied regardless of the chosen software development model is option D, which says that involvement of testers in work product reviews should occur as early as possible to take advantage ofthe early testing principle. Work product reviews are static testing techniques, in which the work products of the software development process, such as the requirements, the design, the code, the test cases, etc., are examined by one or more reviewers, with or without the author, to identify defects, violations, or improvements. Involvement of testers in work product reviews can provide various benefits for the testing process, such as improving the test quality, the test efficiency, and the test communication. The early testing principle states that testing activities should start as early as possible in the software development lifecycle, and should be performed iteratively and continuously throughout the lifecycle. Applying the early testing principle can help to prevent, detect, and remove defects at an early stage, when they are easier, cheaper, and faster to fix, as well as to reduce the risk, the cost, and the time of the testing process. The other options are not good testing practices to be applied regardless of the chosen software development model, but rather specific testing practices that may or may not be applicable or beneficial for testing, depending on the context and the objectives of the testing activities, such as:
✑ Tests should be written in executable format before the code is written and should act as executable specifications that drive coding: This is a specific testing practice that is associated with test-driven development, which is an approach to software development and testing, in which the developers write automated unit tests before writing the source code, and then refactor the code until the tests pass. Test-driven development can help to improve the quality, the design, and the maintainability of the code, as well as to provide fast feedback and guidance for the developers. However, test-driven development is not a good testing practice to be applied regardless of the chosen software development model, as it may not be feasible, suitable, or effective for testing in some contexts or situations, such as when the requirements are unclear, unstable, or complex, when the test automation tools or skills are not available or adequate, when the testing objectives or levels are not aligned with the unit testing, etc.
✑ Test levels should be defined such that the exit criteria of one level are part of the entry criteria for the next level: This is a specific testing practice that is associated with sequential software development models, such as the waterfall model, the V- model, or the W-model, in which the software development and testing activities are performed in a linear and sequential order, with well-defined phases, deliverables, and dependencies. Test levels are the stages of testing that correspond to the levels of integration of the software system, such as component testing, integration testing, system testing, and acceptance testing. Test levels should have clear and measurable entry criteria and exit criteria, which are the conditions that must be met before starting or finishing a test level. In sequential software development models, the exit criteria of one test level are usually part of the entry criteria for the next test level, to ensurethat the software system is ready and stable for the next level of testing. However, this is not a good testing practice to be applied regardless of the chosen software development model, as it may not be relevant, flexible, or efficient for testing in some contexts or situations, such as when the software development and testing activities are performed in an iterative and incremental order, with frequent changes, feedback, and adaptations, as in agile software development models, such as Scrum, Kanban, or XP, when the test levels are not clearly defined or distinguished, or when the test levels are performed in parallel or concurrently, etc.
✑ Test objectives should be the same for all test levels, although the number of tests designed at various levels can vary significantly: This is a specific testing practice that is associated with uniform software development models, such as the spiral model, the incremental model, or the prototyping model, in which the software development and testing activities are performed in a cyclical and repetitive manner, with similar phases, deliverables, and processes. Test objectives are the goals or the purposes of testing, which can vary depending on the test level, the test type, the test technique, the test environment, the test stakeholder, etc. Test objectives can be defined in terms of the test basis, the test coverage, the test quality, the test risk, the test cost, the test time, etc. Test objectives should be specific, measurable, achievable, relevant, and time-bound, and they should be aligned with the project objectives and the quality characteristics. In uniform software development models, the test objectives may be the same for all test levels, as the testing process is repeated for each cycle or iteration, with similar focus, scope, and perspective of testing. However, this is not a good testing practice to be applied regardless of the chosen software development model, as it may not be appropriate, realistic, or effective for testing in some contexts or situations, such as when the software development and testing activities are performed in a hierarchical and modular manner, with different phases, deliverables, and dependencies, as in sequential software development models, such as the waterfall model, the V-model, or the W-model, when the test objectives vary according to the test levels, such as component testing, integration testing, system testing, and acceptance testing, or when the test objectives change according to the feedback, the learning, or the adaptation of the testing process, as in agile software development models, such as Scrum, Kanban, or XP, etc.References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:
✑ ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 1.1.1, Testing and the Software Development Lifecycle1
✑ ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 1.2.1, Testing Principles1
✑ ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 1.2.2, Testing Policies, Strategies, and Test Approaches1
✑ ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 1.3.1, Testing in Software Development Lifecycles1
✑ 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, Work Product Review, Static Testing, Early Testing, Test-driven Development, Test Level, Entry Criterion, Exit Criterion, Test Objective, Test Basis, Test Coverage, Test Quality, Test Risk, Test Cost, Test Time2

NEW QUESTION 21
......