実践サンプルと問題集と指導には2024年最新のCTFL_Syll_4.0有効なテスト問題集 [Q38-Q61]

実践サンプルと問題集と指導には2024年最新のCTFL_Syll_4.0有効なテスト問題集

最新 [2024年11月07日] 100%合格率保証付きの素晴らしいCTFL_Syll_4.0試験問題PDF

質問 # 38
The whole-team approach:

A. is mostly adopted in projects aimed at developing safety-critical systems, as it ensures the highest level of testing independence
B. is a consensus-based approach that engages the whole team in estimating the user stories
C. promotes the idea that all team members should have a thorough understanding of test techniques
D. promotes the idea that all team members should be responsible for the quality of the product

正解：D

解説：
This answer is correct because the whole-team approach is a way of working in agile projects where all team members share the responsibility for the quality of the product, and collaborate on delivering value to the customer. The whole-team approach involves testers, developers, business analysts, product owners, and other stakeholders in planning, designing, developing, testing, and delivering the product. The whole-team approach fosters communication, feedback, learning, and continuous improvement within the team. References: ISTQB Glossary of Testing Terms v4.0, ISTQB Foundation Level Syllabus v4.0, Section 3.1.1.1

質問 # 39
Which of the following statements is true?

A. Some of the most common test basis used by white-box test techniques include user stories, use cases and business processes
B. Experience-based test techniques are often useful to detect hidden defects that have not been targeted by black-box test techniques
C. Experience-based test techniques rely on the experience of testers to identify the root causes of defects found by black-box test techniques
D. The primary goal of experience-based test techniques is to design test cases that can be easily automated using a GUI-based test automation tool

正解：B

解説：
Experience-based test techniques are test design techniques that rely on the experience, knowledge, intuition, and creativity of the testers to identify and execute test cases that are likely to find defects in the software system. Experience-based test techniques are often useful to detect hidden defects that have not been targeted by black-box test techniques, which are test design techniques that use the external behavior and specifications of the software system as the test basis, without considering its internal structure or implementation. Experience-based test techniques can complement black-box test techniques by covering aspects that are not explicitly specified, such as usability, security, reliability, performance, etc. The other statements are false, because:
Experience-based test techniques do not rely on the experience of testers to identify the root causes of defects found by black-box test techniques, but rather to identify the potential sources of defects based on their own insights, heuristics, or exploratory testing. The root causes of defects are usually identified by debugging or root cause analysis, which are activities that involve examining the code or the development process to find and fix the errors that led to the defects.
Some of the most common test basis used by white-box test techniques include the source code, the design documents, the architecture diagrams, and the control flow graphs of the software system. White-box test techniques are test design techniques that use the internal structure and implementation of the software system as the test basis, and aim to achieve a certain level of test coverage based on the code elements, such as statements, branches, paths, etc. User stories, use cases, and business processes are examples of test basis used by black-box test techniques, as they describe the functional and non-functional requirements of the software system from the perspective of the users or the stakeholders.
The primary goal of experience-based test techniques is not to design test cases that can be easily automated using a GUI-based test automation tool, but rather to design test cases that can reveal defects that are not easily detected by other test techniques, such as boundary value analysis, equivalence partitioning, state transition testing, etc. Test automation is the use of software tools to execute test cases and compare actual results with expected results, without human intervention. Test automation can be applied to different types of test techniques, depending on the test objectives, the test levels, the test tools, and the test resources. However, test automation is not always feasible or beneficial, especially for test cases that require human judgment, creativity, or exploration, such as those designed by experience-based test techniques. Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.2.1, Black-box Test Design Techniques ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.2.2, White-box Test Design Techniques ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.2.3, Experience-based Test Design Techniques ISTQB® Glossary of Testing Terms v4.0, Experience-based Test Technique, Black-box Test Technique, White-box Test Technique, Test Basis, Test Coverage, Test Automation

質問 # 40
Which of the following statements is true?

A. Both in Agile software development and in sequential development models, such as the V-model, test levels tend to overlap since they do not usually have defined entry and exit criteria
B. Sequential development models impose the use of systematic test techniques and do not allow the use of experience-based test techniques
C. In Agile software development, the first iterations are exclusively dedicated to testing activities, as testing will be used to drive development, which will be performed in the subsequent iterations
D. In Agile software development, work product documentation tends to be lightweight and manual tests tend to be often unscripted as they are often produced using experience-based test techniques

正解：D

解説：
Explanation
This answer is correct because in Agile software development, work product documentation, such as user stories, acceptance criteria, or test cases, tends to be lightweight and concise, as the focus is on working software and frequent communication rather than comprehensive documentation. Manual tests tend to be often unscripted, as they are often produced using experience-based test techniques, such as error guessing or exploratory testing, which rely onthe tester's skills, knowledge, and creativity to find defects and provide feedback. References: ISTQB Foundation Level Syllabus v4.0, Section 3.1.1.2, Section 3.2.1.2

質問 # 41
A Test Manager conducts risk assessment for a project. One of the identified risks is: The sub-contractor may fail to meet his commitment". If this risk materializes. it will lead to delay in completion of testing required for the current cycle.
Which of the following sentences correctly describes the risk?

A. It is a product risk since default on part of the sub-contractor may lead to delay in release of the product
B. It is a object risk since successful completion of the object depends on successful and timely completion of the tests
C. It is a product risk since any risk associated with development timeline is a product risk.
D. It is no longer a risk for the Test Manager since an independent party (the sub-contractor) is now managing it

正解：A

解説：
* A product risk is a risk that affects the quality or timeliness of the software product being developed or tested1. Product risks are related to the requirements, design, implementation, verification, and maintenance of the software product2.
* The risk of the sub-contractor failing to meet his commitment is a product risk, as it could cause a delay in the completion of the testing required for the current cycle, which in turn could affect the release date of the product. The release date is an important aspect of the product quality, as it reflects the customer satisfaction and the market competitiveness of the product3.
* The other options are not correct because:
* A. It is not true that any risk associated with development timeline is a product risk. Some risks could be project risks, which are risks that affect the management or control of the software project, such as budget, resources, schedule, or communication1. For example, a risk of losing a key project stakeholder is a project risk, not a product risk.
* B. It is not true that the risk is no longer a risk for the Test Manager since an independent party is managing it. The Test Manager is still responsible for ensuring that the testing activities are completed according to the test plan and the quality objectives4. The Test Manager should monitor and control the sub-contractor's performance and communicate with him regularly to identify and mitigate any potential issues or deviations5.
* C. It is not clear what is meant by "object" in this option, but it could be interpreted as the software system under test or the test object6. In any case, the risk is not an object risk, as it does not affect the successful completion of the object, but rather the successful completion of the testing of the object. An object risk could be a risk that affects the functionality, reliability, usability, efficiency, maintainability, or portability of the software system under test2. For example, a risk of the software system having a high complexity or a low testability is an object risk, not a product risk.
References =
* 1 ISTQB Certified Tester Foundation Level Syllabus v4.0, 2023, p. 97
* 2 ISTQB Certified Tester Foundation Level Syllabus v4.0, 2023, p. 98
* 3 ISTQB Certified Tester Foundation Level Syllabus v4.0, 2023, p. 99
* 4 ISTQB Certified Tester Foundation Level Syllabus v4.0, 2023, p. 100
* 5 ISTQB Certified Tester Foundation Level Syllabus v4.0, 2023, p. 101
* 6 ISTQB Certified Tester Foundation Level Syllabus v4.0, 2023, p. 102

質問 # 42
Which of the following statements about the shift-left approach is true?

A. Performance testing performed during component testing, is a form of shift-left in testing that avoids planning and executing costly end-to-end testing at the system test level in a production-like environment
B. Continuous integration supports shift-left in testing as it can reduce the time between the introduction of a defect and its detection, thereby reducing the cost to fix it
C. Shift-left in testing can be implemented in several ways to find functional defects early in the lifecycle, but it cannot be relied upon to find defects associated with non-functional characteristics
D. Shift-left in testing can be implemented only in Agile/DevOps frameworks, as it relies completely on automated testing activities performed within a continuous integration process

正解：B

解説：
This answer is correct because shift-left in testing is an approach that aims to perform testing activities as early as possible in the software development lifecycle, in order to find and fix defects faster and cheaper, and to improve the quality of the software product. Continuous integration is a practice that supports shift-left in testing, as it involves integrating and testing the software components frequently, usually several times a day, using automated tools and processes. Continuous integration can reduce the time between the introduction of a defect and its detection, thereby reducing the cost to fix it and the risk of accumulating defects that could affect the functionality or performance of the software product. Reference: ISTQB Foundation Level Syllabus v4.0, Section 3.1.1.3, Section 3.2.1.3

質問 # 43
A typical generic skill required for the role of tester is the ability to:

A. use tools to make the execution of repetitive testing tasks more efficient
B. take on the role of developer to meet challenging project deadlines
C. determine the corrective actions to get a test project on track in case of deviations from the test plan
D. assume leadership aimed at imposing decisions on the rest of the team

正解：A

解説：
One of the generic skills required for the role of a tester is the ability to use tools to make the execution of repetitive testing tasks more efficient. This includes using various test automation tools to streamline the testing process, reduce manual effort, and improve the consistency and accuracy of test results. Testers should be proficient in leveraging these tools to enhance productivity and ensure comprehensive test coverage.
References:
* ISTQB CTFL Syllabus 4.0, Chapter 1.5.1, page 20: General Skills Required for Testing

質問 # 44
Which of the following statements is an example of testing contributing to higher quality?

A. A project manager asks to a test leader to estimate the test effort
B. A test leader writes a test summary report
C. A tester installs a test ten in the lest environment
D. A tester finds a bug which is resolved prior to release

正解：D

解説：
* The question is about identifying an example of testing contributing to higher quality. Quality is the degree to which a component, system or process meets specified requirements and/or user/customer needs and expectations1. Testing is the process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects2.
* Therefore, testing contributes to higher quality by verifying and validating that the software products and related work products meet the specified requirements, are fit for purpose and have no defects, or at least have a reduced number of defects. Testing also provides information about the quality of the software products and related work products to the stakeholders, who can make informed decisions based on the test results3.
* Out of the four given statements, only option D is an example of testing contributing to higher quality, as it shows that testing has detected a defect (a flaw in a component or system that can cause the component or system to fail to perform its required function4) and that the defect has been resolved (fixed and confirmed) prior to release (delivery of the software product to the customer or end user).
This means that testing has prevented a potential failure (an event in which a component or system does not perform a required function within specified limits) from occurring in the operational environment, and thus has improved the quality of the software product.
* Option A is not an example of testing contributing to higher quality, as it is a reporting activity that summarizes the test results and evaluates the test objectives, but does not directly affect the quality of the software product or related work products. A test summary report is a document that records and communicates the outcomes of testing activities, including test completion criteria, test results, incident reports, test summary and evaluation, and lessons learned.
* Option B is not an example of testing contributing to higher quality, as it is a planning activity that estimates the resources and time needed for testing activities, but does not directly affect the quality of the software product or related work products. A test effort estimate is an approximation of the amount of work and/or the duration of time required to perform testing activities.
* Option C is not an example of testing contributing to higher quality, as it is a preparation activity that sets up the test environment (an environment containing hardware, instrumentation, simulators, software tools, and other support elements needed to conduct a test), but does not directly affect the quality of the software product or related work products. A test environment installation is a process of installing and configuring the test environment according to the test environment specification.
References:
* 1: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 10
* 2: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 11
* 3: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 12
* 4: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 13
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 13
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 77
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 78
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 79
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 80
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 81
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 82
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 83
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 84
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 85
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 86
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 87
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 88
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 89
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 90
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 91
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 92
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 93
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 94
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 95
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 96
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 97
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 98
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 99
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 100
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 101
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 102
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 103
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 104
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 105
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 106
* : ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 107

質問 # 45
Which of the following statements about exploratory testing is true?

A. Exploratory testing is an experience-based test technique used by testers during informal code reviews to find defects by exploring the source code
B. In exploratory testing, testers usually produce scripted tests and establish bidirectional traceability between these tests and the items of the test basis
C. Exploratory testing is an experience-based test technique in which testers explore the requirements specification to detect non testable requirements
D. When exploratory testing is conducted following a session-based approach, the issues detected by the testers can be documented in session sheets

正解：D

解説：
Exploratory testing is an experience-based test technique in which testers dynamically design and execute tests based on their knowledge, intuition, and learning of the software system, without following predefined test scripts or test cases. Exploratory testing can be conducted following a session-based approach, which is a structured way of managing and measuring exploratory testing. In a session-based approach, the testers perform uninterrupted test sessions, usually lasting between 60 and 120 minutes, with a specific charter or goal, and document the issues detected, the test coverage achieved, and the time spent in session sheets.
Session sheets are records of the test activities, results, and observations during a test session, which can be used for reporting, debriefing, and learning purposes. The other statements are false, because:
* Exploratory testing is not a test technique in which testers explore the requirements specification to detect non testable requirements, but rather a test technique in which testers explore the software system to detect functional and non-functional defects, as well as to learn new information, risks, or opportunities. Non testable requirements are requirements that are ambiguous, incomplete, inconsistent, or not verifiable, which can affect the quality and effectiveness of the testing process. Non testable requirements can be detected by applying static testing techniques, such as reviews or inspections, to the requirements specification, before the software system is developed or tested.
* Exploratory testing is not a test technique used by testers during informal code reviews to find defects by exploring the source code, but rather a test technique used by testers during dynamic testing to find defects by exploring the behavior and performance of the software system, without examining the source code. Informal code reviews are static testing techniques, in which the source code is analyzed by one or more reviewers, without following a formal process or using a checklist, to identify defects,
* violations, or improvements. Informal code reviews are usually performed by developers or peers, not by testers.
* In exploratory testing, testers usually do not produce scripted tests and establish bidirectional traceability between these tests and the items of the test basis, but rather produce unscripted tests and adapt them based on the feedback and the findings of the testing process. Scripted tests are tests that are designed and documented in advance, with predefined inputs, outputs, and expected results, and are executed according to a test plan or a test procedure. Bidirectional traceability is the ability to trace both forward and backward the relationships between the items of the test basis, such as the requirements, the design, the risks, etc., and the test artifacts, such as the test cases, the test results, the defects, etc.
Scripted tests and bidirectional traceability are usually associated with more formal and structured testing approaches, such as specification-based or structure-based test techniques, not with exploratory testing. References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:
* ISTQB Certified Tester Foundation Level Syllabus v4.0, Chapter 2.2.3, Experience-based Test Design Techniques1
* ISTQB Glossary of Testing Terms v4.0, Exploratory Testing, Session-based Testing, Session Sheet, Non Testable Requirement, Static Testing, Informal Review, Dynamic Testing, Scripted Testing, Bidirectional Traceability2

質問 # 46
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. Branch Coverage
C. Data flow coverage
D. Statement coverage

正解：B

解説：
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 is a 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.

質問 # 47
An organization is working on updating test cases for a particular module of their software.
Sam updated a set of test cases yesterday and saved the new version on his PC.
Unfortunately, the hard disk of his PC crashed, and his work was lost.
The IT department of the organization restored the contents of his hard disk with the last available back-up - from the previous morning. However, the changes made by him yesterday were lost forever.
Which of the following tools, had it been used, would have prevented the loss of Sam's updates?

A. Incident Management Tool
B. Configuration Management Tool
C. Test Execution tool
D. Backup tool

正解：B

解説：
A configuration management tool helps in maintaining and managing changes to software, including test cases. It ensures that changes are tracked and can be retrieved if needed. In this scenario, using a configuration management tool would have allowed Sam's updates to be stored in a central repository, preventing the loss of his work even if his PC's hard disk crashed.
References:
* ISTQB CTFL Syllabus V4.0, Section 5.4 on configuration management, which describes the role of configuration management tools in maintaining control over changes.

質問 # 48
What is test oracle?

A. The source for the actual results
B. The source of expected results
C. The source of lest objectives
D. The source of input conditions

正解：B

解説：
A test oracle is a mechanism or principle that can be used to determine whether the observed behavior or output of a system under test is correct or not1. A test oracle can be based on various sources of expected results, such as specifications, user expectations, previous versions, comparable systems, etc2. References:
ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Section 1.2.1, Page 91; ISTQB Glossary of Testing Terms, Version 4.0, Page 332.

質問 # 49
What type of testing measures its effectiveness by tracking which lines of code were executed by the tests?

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

正解：A

解説：
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 components or 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.

質問 # 50
Following a risk-based testing approach you have designed 10 tests to cover a product risk with a high-risk level. You want to estimate, adopting the three-point test estimation technique, the test effort required to reduce the risk level to zero by executing those 10 tests. You made the following three initial estimates:
* most optimistic = 6 person hours
* most likely = 30 person hours
* most pessimistic = 54 person hours
Based only on the given information, which of the following answers about the three-point test estimation technique applied to this problem is true?

A. The final estimate is exactly 30 person hours because the technique uses the arithmetic mean of the three initial estimates as the final estimate
B. The final estimate is between 22 person hours and 38 person hours
C. The final estimate is between 6 person hours and 54 person hours
D. The final estimate is exactly 30 person hours because the technique uses the initial most likely estimate as the final estimate

正解：B

解説：
The three-point test estimation technique is a method of estimating the test effort based on three initial estimates: the most optimistic, the most likely, and the most pessimistic. The technique uses a weighted average of these three estimates to calculate the final estimate, which is also known as the expected value. The formula for the expected value is:
Expected value = (most optimistic + 4 * most likely + most pessimistic) / 6 Using the given values, the expected value is:
Expected value = (6 + 4 * 30 + 54) / 6 Expected value = 30 person hours However, the expected value is not the only factor to consider when estimating the test effort. The technique also calculates the standard deviation, which is a measure of the variability or uncertainty of the estimates. The formula for the standard deviation is:
Standard deviation = (most pessimistic - most optimistic) / 6
Using the given values, the standard deviation is:
Standard deviation = (54 - 6) / 6 Standard deviation = 8 person hours
The standard deviation can be used to determine a range of possible values for the test effort, based on a certain level of confidence. For example, using a 68% confidence level, the range is:
Expected value ± standard deviation
Using the calculated values, the range is:
30 ± 8 person hours
Therefore, the final estimate is between 22 person hours and 38 person hours, which is option A.
References: ISTQB Certified Tester Foundation Level Syllabus v4.01, Section 2.3.2, page 24-25; ISTQB Glossary v4.02, page 33.

質問 # 51
Which of the following s the most correct statement about state testing techniques?

A. Static techniques can be used by inexperienced users.
B. Static techniques can be used before all code is ready for execution
C. Static techniques are always cheaper than dynamic techniques.
D. Static techniques find more detects then dynamic techniques.

正解：B

解説：
State testing techniques are a type of dynamic testing techniques that are based on the behavior of the system under test for different input conditions and events. Dynamic testing techniques require the system to be executed with test cases, whereas static testing techniques do not. Static testing techniques can be applied before the code is ready for execution, such as reviews, inspections, walkthroughs, and static analysis. Static testing techniques can help find defects early in the development process, improve the quality of the code, and reduce the cost and effort of dynamic testing. Reference = ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Chapter 4, Section 4.2.1, Page 281; ISTQB Glossary of Testing Terms v4.0, Page 292

質問 # 52
Which of the following statements refers to good testing practice to be applied regardless of the chosen software development model?

A. Test objectives should be the same for all test levels, although the number of tests designed at various levels can vary significantly
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. Involvement of testers in work product reviews should occur as early as possible to take advantage of the early testing principle
D. Tests should be written in executable format before the code is written and should act as executable specifications that drive coding

正解：C

解説：
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 of the 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 ensure that 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. Reference: 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

質問 # 53
A test manager decided to skip static testing since he believes bugs can be found easily by doing dynamic testing. Was this decision right or wrong?

A. The decision was wrong. Ensuring quality mandates that static testing is performed after performing the dynamic testing.
B. The decision was right. Most of the bugs are easier to identify during the dynamic testing.
C. The decision was wrong. Static testing can find defects early in the development process, reducing the overall cost of testing and development
D. The decision was right. Static testing is usually redundant if a product is planned to go through a full-cycle of dynamic testing.

正解：C

解説：
Static testing is a form of testing that does not involve executing the software or system under test. It includes activities such as reviews, inspections, walkthroughs, and analysis of documents, code, and models. Static testing can find defects early in the development process, before they become more expensive and difficult to fix in later stages. Static testing can also improve the quality of the software or system by preventing defects from being introduced in the first place. Static testing can complement dynamic testing, which involves executing the software or system under test and checking the results against expected outcomes. Dynamic testing can find defects that static testing may miss, such as performance, usability, or integration issues. However, dynamic testing alone is not sufficient to ensure quality, as it may not cover all possible scenarios, inputs, or paths. Therefore, a test manager who decides to skip static testing is making a wrong decision, as he or she is ignoring the benefits of static testing and relying solely on dynamic testing, which may not be effective or efficient enough to find and prevent defects. Reference = ISTQB Certified Tester Foundation Level Syllabus, Version 4.0, 2018, Section 2.1.1, page 14; ISTQB Glossary of Testing Terms, Version 4.0, 2018, page 36; ISTQB CTFL 4.0 - Sample Exam - Answers, Version 1.1, 2023, Question 3, page 9.

質問 # 54
Which of the following statement about the shift-left approach is false?

A. The shift-left approach can only be implemented with test automation
B. The shift-left approach can be supported by static analysis tools
C. The shift-left approach can involve security vulnerabilities
D. The shift-left approach in testing is compatible with DevOps practices

正解：A

解説：
The statement that the shift-left approach can only be implemented with test automation is false. The shift-left approach emphasizes early testing activities in the software development lifecycle to detect and address defects as soon as possible. While test automation can support shift-left practices, it is not the only method.
The shift-left approach can also involve practices such as static analysis, early requirement reviews, and integrating security vulnerability assessments early in the development process.

質問 # 55
Which of the following is a task the Author is responsible for, as part of a typical formal review?

A. Determining the people who will be involved in the review
B. Fixing the anomalies found in the work product under review
C. Identifying potential anomalies in the work product under review
D. Recording the anomalies found during the review meeting

正解：C

解説：
This answer is correct because identifying potential anomalies in the work product under review is one of the tasks the Author is responsible for, as part of a typical formal review. The Author is the person who creates the work product to be reviewed, such as a requirement specification, a design document, or a test case. The Author's tasks include preparing the work product for the review, identifying potential anomalies in the work product, and fixing the anomalies found in the work product after the review. References: ISTQB Glossary of Testing Terms v4.0, ISTQB Foundation Level Syllabus v4.0, Section 2.4.2.1

質問 # 56
Consider a review for a high-level architectural document written by a software architect. The architect does most of the review preparation work, including distributing the document to reviewers before the review meeting. However, reviewers are not required to analyze the document in advance, and during the review meeting the software architect explains the document step by step. The only goal of this review is to establish a common understanding of the software architecture that will be used in a software development project.
Which of the following review types does this review refer to?

A. Informal review
B. Audit
C. Inspection
D. Walkthrough

正解：D

解説：
This answer is correct because a walkthrough is a type of review where the author of the work product leads the review process and explains the work product to the reviewers. The reviewers are not required to prepare for the review in advance, and the main objective of the walkthrough is to establish a common understanding of the work product and to identify any major defects or issues. A walkthrough is usually informal and does not follow a defined process or roles. In this case, the review for a high-level architectural document written by a software architect matches the characteristics of a walkthrough. References: ISTQB Glossary of Testing Terms v4.0, ISTQB Foundation Level Syllabus v4.0, Section 2.4.2.2

質問 # 57
Which of the following is not an example of a typical content of a test completion report for a test project?

A. The residual risk level if a risk-based test approach was adopted
B. The unexpected test environment downtime that resulted in slower test execution
C. The additional effort spent on test execution compared to what was planned
D. The test procedures of all test cases that have been executed

正解：D

解説：
This answer is correct because the test procedures of all test cases that have been executed are not a typical content of a test completion report for a test project. A test completion report is a document that summarizes the test activities and results at the end of a test project. It usually includes information such as the test objectives, scope, approach, resources, schedule, results, deviations, issues, risks, lessons learned, and recommendations for improvement. The test procedures of all test cases that have been executed are part of the test documentation, but they are not relevant for the test completion report, as they do not provide a high-level overview of the test project outcomes and performance. References: ISTQB Foundation Level Syllabus v4.0, Section 2.5.3.2

質問 # 58
Consider the following user story about the authentication functionality of an e-commerce website:
"As a logged-in user, I want to change my current password with a new one, so that I can make my account safer".
The following are some of the acceptance criteria defined for the user story:
[a] After the logged-in user has successfully changed his password, an email confirming the change must be sent to him
[b] To successfully change the password, the logged-in user must enter the current password, enter a new valid password, and finally confirm by pressing the 'Change Password' button
[c] To be valid, the new password entered by the logged-in user is not only required to meet the criteria related to the length and type of characters, but must also be different form the last 5 passwords of that user
[d] A dedicated error message must be presented to the logged-in user when he enters a wrong current password
[e] A dedicated error message must be presented to the logged-in user when he enters the correct current password, but enters an invalid password Based only on the given information, which of the following ATDD tests is most likely to be written first?

A. The logged-in user enters the correct current password, enters an invalid password, and finally views the dedicated error
B. The logged-in user submits a purchase order containing ten items, selects to pay with a Visa credit card, enters credit card information of a valid card, presses the 'Confirm' button, and finally views the dedicated message confirming that the purchase has been successful
C. The logged-in user enters the correct current password, enters a valid new password (different from the last 5 passwords), presses the Change Password' button, and finally receives the e-mail confirming that the password has been successfully changed
D. The logged-in user enters a wrong current password and views the dedicated error message

正解：C

解説：
ATDD stands for Acceptance Test-Driven Development, which is a collaborative approach to software development and testing, in which the acceptance criteria of a user story are defined and automated as executable tests before the implementation of the software system. ATDD tests are usually written in a Given-When-Then format, which describes the preconditions, the actions, and the expected outcomes of a test scenario. ATDD tests are intended to verify that the software system meets the expectations and the needs of the users and the stakeholders, as well as to provide feedback and guidance for the developers and the testers.
Based on the given information, the ATDD test that is most likely to be written first is the one that corresponds to option B, which is:
Given the logged-in user is on the Change Password page When the user enters the correct current password, enters a valid new password (different from the last 5 passwords), and presses the Change Password button Then the user receives an email confirming that the password has been successfully changed This ATDD test is most likely to be written first, because it covers the main functionality and the happy path of the user story, as well as the most important acceptance criterion [a]. It also verifies that the user can change the password with a valid new password that meets the criteria related to the length, the type of characters, and the history of the passwords, as specified in the acceptance criterion [c]. The other options are not likely to be written first, because they either cover less critical or less frequent scenarios, such as entering a wrong current password [d] or an invalid new password [e], or they are not related to the user story or the acceptance criteria at all, such as submitting a purchase order [d]. References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:
* ISTQB Certified Tester Foundation Level Syllabus v4.0, Chapter 1.3.1, Testing in Software Development Lifecycles1
* ISTQB Glossary of Testing Terms v4.0, Acceptance Test-Driven Development, User Story, Acceptance Criterion, Given-When-Then2

質問 # 59
Which of the following statements about how different types of test tools support testers is true?

A. The support offered by a test data preparation tool is often leveraged by testers to run automated regression test suites
B. The support offered by a bug prediction tool is often used by testers to track the bugs they found
C. The support offered by a performance testing tool is often leveraged by testers to run load tests
D. The support offered by a continuous integration tool is often leveraged by testers to automatically generate test cases from a model

正解：C

解説：
Explanation
The support offered by a performance testing tool is often leveraged by testers to run load tests, which are tests that simulate a large number of concurrent users or transactions on the system under test, in order to measure its performance, reliability, and scalability. Performance testing tools can help testers to generate realistic workloads, monitor system behavior, collect and analyze performance metrics, and identify performance bottlenecks. The other statements are false, because:
A test data preparation tool is a tool that helps testers to create, manage, and manipulate test data, which are the inputs and outputs of test cases. Test data preparation tools are not directly related to running automated regression test suites, which are test suites that verify that the system still works as expected after changes or modifications. Regression test suites are usually executed by test execution tools, which are tools that can automatically run test cases and compare actual results with expected results.
A bug prediction tool is a tool that uses machine learning or statistical techniques to predict the likelihood of defects in a software system, based on various factors such as code complexity, code churn, code coverage, code smells, etc. Bug prediction tools are not used by testers to track the bugs they found, which are the actual defects that have been detected and reported during testing. Bugs are usually tracked by defect management tools, which are tools that help testers to record, monitor, analyze, and resolve defects.
A continuous integration tool is a tool that enables the integration of code changes from multiple developers into a shared repository, and the execution of automated builds and tests, in order to ensure the quality and consistency of the software system. Continuous integration tools are not used by testers to automatically generate test cases from a model, which are test cases that are derived from a representation of the system under test, such as a state diagram, a decision table, a use case, etc. Test cases can be automatically generated by test design tools, which are tools that support the implementation and maintenance of test cases, based on test design specifications or test models.
References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:
ISTQB Certified Tester Foundation Level Syllabus v4.0, Chapter 3.4.1, Types of Test Tools ISTQB Glossary of Testing Terms v4.0, Performance Testing Tool, Test Data Preparation Tool, Bug Prediction Tool, Continuous Integration Tool, Test Execution Tool, Defect Management Tool, Test Design Tool

質問 # 60
Which of the following statements about the value of maintaining traceability between the test basis and test work products is not true?

A. Traceability can be useful to support the needs required by the auditing of testing
B. Traceability can be useful for assessing the impact of a change to a test basis item on the corresponding tests
C. Traceability can be useful for determining how many test basis items are covered by the corresponding tests
D. Traceability can be useful for determining the most suitable test techniques to be used in a testing project

正解：D

解説：
Explanation
Traceability is the ability to trace the relationships between the items of the test basis, such as the requirements, the design, the risks, etc., and the test artifacts, such as the test cases, the test results, the defects, etc. Traceability can provide various benefits for the testing process, such as improving the test coverage, the test quality, the test efficiency, and the test communication. However, not all the statements given are true about the value of maintaining traceability between the test basis and test work products. The statement that is not true is option C, which says that test objectives should be the same for all test levels, although the number of tests designed at various levels can vary significantly. This statement is false, because 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. Test objectives should not be the same for all test levels, as different test levels have different focuses, scopes, and perspectives of testing, such as component testing, integration testing, system testing, and acceptance testing. The other statements are true about the value of maintaining traceability between the test basis and test work products, such as:
Traceability can be useful for assessing the impact of a change to a test basis item on the corresponding tests: This statement is true, because traceability can help to identify which tests are affected by a change in the test basis, such as a new requirement, a modified design, a revised risk, etc., and to determine thenecessary actions to update, re-execute, or re-evaluate the tests. Traceability can also help to estimate the effort, the cost, and the time needed to implement the change and to verify its impact on the software system.
Traceability can be useful for determining how many test basis items are covered by the corresponding tests: This statement is true, because traceability can help to measure the test coverage, which is the degree to which the test basis is exercised by the test cases. Traceability can help to identify which test basis items are covered, partially covered, or not covered by the tests, and to evaluate the adequacy, the completeness, and the effectiveness of the testing process. Traceability can also help to identify the gaps, the overlaps, or the redundancies in the test coverage, and to prioritize, optimize, or improve the test cases.
Traceability can be useful to support the needs required by the auditing of testing: This statement is true, because traceability can help to provide evidence, documentation, and justification for the testing activities, results, and outcomes. Traceability can help to demonstrate that the testing process follows the standards, the regulations, the policies, and the best practices that are applicable to the software system, the project, or the organization. Traceability can also help to verify that the testing process meets the expectations, the needs, and the satisfaction of the users and the stakeholders. References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:
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 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 Glossary of Testing Terms v4.0, Traceability, Test Basis, Test Artifact, Test Objective, Test Level, Test Coverage, Test Quality, Test Risk, Test Cost, Test Time2

質問 # 61
......

CTFL_Syll_4.0時間限定！無料アクセス：https://www.passtest.jp/ISQI/CTFL_Syll_4.0-shiken.html

CTFL_Syll_4.0認定有効な試験問題集と解答学習ガイド：https://drive.google.com/open?id=1qP34NHJCSgqeSwqXB7ixjz7lfPaP_dR-

関するブログ

もっと

CTFL_Syll_4.0 無料問題集