[更新されたのは2023年]ISTQB ISTQB-CTFL問題準備には無料サンプルのPDF [Q25-Q49]

[更新されたのは2023年]ISTQB ISTQB-CTFL問題準備には無料サンプルのPDF

2023年最新の認定サンプル問題ISTQB-CTFL問題集と練習試験合格させます

質問 # 25
Which sequence of state transition stated in the answer choices is correct in accordance with the following figure depicting me life-cycle of a defect?

• A. S0->S1->S2->S3->S5->S3->S4
• B. S0->S1->S2->S3->S5^>S1
• C. S0->S1->S2->S3->S4
• D. S0->S1->S2->S3->S5->S1->S2->S3

正解：D

解説：
The figure depicts the life-cycle of a defect using state transition testing. State transition testing is a technique that models how a system transitions from one state to another depending on events or conditions. The figure shows six states (S0 to S5) and seven transitions (T0 to T6). The correct sequence of state transitions that follows the figure is S0->S1->S2->S3->S5->S1->S2->S3. This sequence represents the following scenario:
S0: The defect is not yet detected (initial state).
T0: The defect is detected by testing (event).
S1: The defect is reported and registered (state).
T1: The defect is assigned to a developer for fixing (event).
S2: The defect is being fixed by the developer (state).
T2: The developer fixes the defect and delivers a new version (event).
S3: The defect is verified by testing (state).
T5: The testing fails to confirm that the defect is fixed (event).
S5: The defect is rejected by testing (state).
T6: The defect is reassigned to a developer for fixing (event).
S1: The defect is reported and registered (state).
T1: The defect is assigned to a developer for fixing (event).
S2: The defect is being fixed by the developer (state).
T2: The developer fixes the defect and delivers a new version (event).
S3: The defect is verified by testing (state). The other sequences are incorrect, as they do not follow the transitions shown in the figure. Verified Reference: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer], Chapter 4, page 40-41.

質問 # 26
Which of the following is NOT an experience-based technique?

• A. Exploratory testing
• B. Fault attack
• C. Boundary value analysis.
• D. Error guessing

正解：C

解説：
Boundary value analysis is not an experience-based technique, but rather a specification-based technique (also known as black-box technique). Experience-based techniques are techniques that rely on the tester's knowledge and intuition to derive and select test cases based on their experience with similar systems, technologies, domains, risks, etc. Some examples of experience-based techniques are error guessing, exploratory testing, fault attack, checklist-based testing, etc. Specification-based techniques are techniques that rely on the tester's analysis and interpretation of the requirements or specifications of the system under test to derive and select test cases based on some criteria or rules. Some examples of specification-based techniques are equivalence partitioning, boundary value analysis, decision table testing, state transition testing, etc. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 31.

質問 # 27
A team's test strategy was to invest equal effort in testing each of a system's modules. After running one test cycle, it turned out that most of the critical bugs were detected in one of the system's modules.
Which testing principal suggests a change to the current test strategy for the next test cycle?

• A. Defect clustering
• B. Early testing
• C. Absence-of-errors fallacy
• D. Pesticide Paradox

正解：A

解説：
Defect clustering is a testing principle that states that a small number of modules contain most of the defects detected during pre-release testing, or are responsible for most of the operational failures. Defect clustering can be explained by Pareto's principle (also known as the 80-20 rule), which states that approximately 80% of the problems are found in 20% of the modules. Defect clustering suggests a change to the current test strategy for the next test cycle, as it implies that more effort should be allocated to test the modules that have shown high defect density or criticality. Pesticide paradox is another testing principle that states that if the same tests are repeated over and over again, eventually they will no longer find any new defects. Pesticide paradox suggests a change to the current test strategy for the next test cycle, but not based on defect clustering, but rather on test diversity and coverage. Early testing is a testing principle that states that testing activities should start as early as possible in the software development life cycle and should be focused on defined objectives. Early testing does not suggest a change to the current test strategy for the next test cycle, but rather a proactive approach to prevent defects from occurring or propagating. Absence-of-errors fallacy is a testing principle that states that finding and fixing defects does not help if the system built is unusable and does not fulfill the users' needs and expectations. Absence-of-errors fallacy does not suggest a change to the current test strategy for the next test cycle, but rather a focus on quality attributes and user requirements. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, Chapter 1, page 9-10.

質問 # 28
Manager responsibilities in formal review includes ad except one of the following:

• A. Determines if the review objectives have been met
• B. Allocate time for review
• C. Planning the review
• D. Decide on the execution of reviews

正解：A

解説：
A formal review is a type of review that follows a defined process with formal entry and exit criteria and roles and responsibilities for participants. A formal review can have various roles involved, such as manager, moderator, author, reviewer and scribe. The manager responsibilities in formal review include all except one of the following:
Planning the review (correct responsibility)
Determines if the review objectives have been met (incorrect responsibility) Decide on the execution of reviews (correct responsibility) Allocate time for review (correct responsibility) The responsibility of determining if the review objectives have been met belongs to the moderator role, not to the manager role. Verified Reference: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer], Chapter 3, page 28-29.

質問 # 29
An Incident Management tool implements the following defect states; Open, Assigned, Solved, Closed Consider the following defect report:
Id T000561
Test Object "Warehouse Management' application
Tester name; John Bishop
Date: 10th. April 2010
Test Case MRT558I
Status OPEN
Severity Serious
Priority
Problem- After inputting the Total Quantity item = 450 in the SV034 screen, the system shows an unexpected Error message=47 Correction:
Developer name:
Closing date:
Which of the following is a valid criticism of this report?

• A. The description is not highlighting the source of the problem
• B. There is no link to the applicable requirement (traceability)
• C. The version of the application is missing
• D. The Priority, the Correction description and the Developer name are missing

正解：C

解説：
A valid criticism of this report is that the version of the application is missing. The version of the application is an important piece of information that should be included in a defect report, as it helps to identify which release or build of the software product contains the defect. The version of the application can also help to reproduce and debug the defect, as different versions may have different behaviors or features. The other options are not valid criticisms of this report. The priority, the correction description and the developer name are not missing, but rather not applicable for this report. The priority is a measure of how urgently a defect needs to be fixed, which can be assigned by the project manager or the defect tracking system, not by the tester who reports the defect. The correction description and the developer name are information that are added after the defect has been resolved, not when it has been reported. There is no link to the applicable requirement (traceability) is not a valid criticism of this report, because traceability is not a mandatory attribute of a defect report, but rather an optional one. Traceability is a relationship between two or more entities (such as requirements, test cases, defects, etc.) that shows how they are related or dependent on each other. Traceability can help to verify that the requirements are met by the test cases and defects, but it is not essential for reporting a defect. The description is not highlighting the source of the problem is not a valid criticism of this report, because highlighting the source of the problem is not a responsibility of the tester who reports the defect, but rather of the developer who fixes the defect. The description should provide enough information to describe what happened when the defect occurred, such as input values, expected results, actual results, error messages, screenshots, etc., but it does not need to explain why or how it happened. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 140.

質問 # 30
Which of the following is an example of black-box dynamic testing?

• A. Code inspection
• B. Checking memory leaks for a program by executing it
• C. Functional Testing
• D. Coverage analysis

正解：C

解説：
Functional testing is an example of black-box dynamic testing. Black-box testing (also known as specification-based testing) is a type of testing that does not consider the internal structure or implementation of the system under test, but rather its external behavior or functionality. Dynamic testing is a type of testing that involves executing the system under test with various inputs and observing its outputs. Functional testing is a type of black-box dynamic testing that verifies that the system under test performs its intended functions according to its requirements or specifications. Functional testing can be performed at various levels and scopes depending on the objectives and criteria of testing. The other options are not examples of black-box dynamic testing. Code inspection is an example of white-box static testing. White-box testing (also known as structure-based testing) is a type of testing that considers the internal structure or implementation of the system under test. Static testing is a type of testing that does not involve executing the system under test, but rather analyzing it for defects, errors, or violations of standards. Code inspection is a type of white-box static testing that involves examining the source code of the system under test for quality, readability, maintainability, etc. Checking memory leaks for a program by executing it is an example of white-box dynamic testing. Memory leaks are defects that occur when a program fails to release memory that it has allocated but no longer needs. Checking memory leaks for a program by executing it requires knowledge and access to the internal structure or implementation of the program, such as memory allocation and deallocation mechanisms, pointers, references, etc. Coverage analysis is an example of white-box static testing. Coverage analysis is a technique that measures how much of the code or structure of the system under test has been exercised by a test suite. Coverage analysis requires knowledge and access to the internal structure or implementation of the system under test, such as statements, branches, paths, conditions, etc. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 7.

質問 # 31
Which of the following is the most important task of a typical test leader?

• A. To automate tests.
• B. To set up the test environment.
• C. To prepare and acquire test data.
• D. To coordinate the test strategy with project managers.

正解：D

解説：
The most important task of a typical test leader is to coordinate the test strategy with project managers. The test strategy is a high-level document that defines the general approach and objectives of testing for a project or an organization. The test leader is responsible for defining, documenting, communicating, and implementing the test strategy in alignment with the project goals and constraints. The test leader also needs to coordinate with project managers and other stakeholders to ensure that the test strategy is feasible, effective, and efficient. The other options are not the most important tasks of a typical test leader. To automate tests is a task of a test automation engineer or a test automation specialist. To prepare and acquire test data is a task of a test analyst or a test engineer. To set up the test environment is a task of a test environment manager or a test environment specialist. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 13.

質問 # 32
Which of the following would be the LEAST likely to be used as the basis for a test exit criteria?

• A. Test schedules
• B. Cost of testing performed so far
• C. Number of unfixed defects
• D. Confidence of testers in tested code

正解：A

解説：
Test exit criteria are the conditions or requirements that must be met before testing can be concluded. Test exit criteria are usually defined in the test plan and agreed by the stakeholders. Test exit criteria can be based on various factors, such as test coverage, defect status, quality level, risk level, etc. Test schedules would be the least likely to be used as the basis for test exit criteria, because test schedules are not directly related to the quality or performance of the software product, but rather to the time or resources allocated for testing. Test schedules can be used as the basis for test entry criteria, which are the conditions or requirements that must be met before testing can start. The other options are more likely to be used as the basis for test exit criteria. Cost of testing performed so far can be used as a basis for test exit criteria, because it can indicate the return on investment or the cost-benefit ratio of testing. Confidence of testers in tested code can be used as a basis for test exit criteria, because it can reflect the level of satisfaction or assurance of the testers about the quality or reliability of the software product. Number of unfixed defects can be used as a basis for test exit criteria, because it can indicate the level of risk or impact of the remaining defects on the software product. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 13.

質問 # 33
Which of the following tools is most likely to detect defects in functions or methods in source code?

• A. monitoring tool
• B. unit test framework tool
• C. configuration management tool
• D. test design tool

正解：B

解説：
A unit test framework tool is a tool that supports the creation, execution, and reporting of unit tests, which are tests that verify the functionality and quality of individual software components (such as functions or methods) in source code. A unit test framework tool can help to detect defects in functions or methods in source code by providing features such as test case generation, test case execution, test result comparison, test coverage measurement, etc. Some examples of unit test framework tools are JUnit, NUnit, TestNG, etc. The other options are not tools that are likely to detect defects in functions or methods in source code. A configuration management tool is a tool that supports the management and control of different versions and variants of software products or components. A test design tool is a tool that supports the design and generation of test cases based on some criteria or rules. A monitoring tool is a tool that monitors the behavior or performance of a system or component under test. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 10.

質問 # 34
Why it is essential that defects found in a review be reported objectively?

• A. In order to allow the review moderator to easily understand them, and assign them to the right developer for fixing
• B. In order to facilitate easy entry of detected defects in a OTS (Defect Tracking System)
• C. In order to allow augmentation of existing checklists used for reviewing the work product (S)
• D. In order to allow the author of reviewed work product(S) to take the feedback positively as an effort at improving the product (S) and not as a personal assault

正解：D

解説：
The purpose of a review is to find defects and improve the quality of the work product, not to criticize or blame the author. Reporting defects objectively means describing them factually and constructively, without using negative or emotional language that could offend the author or damage their motivation. This way, the author can take the feedback positively as an effort at improving the product and not as a personal assault. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 138.

質問 # 35
For withdrawing money tram an Automated Teller Machine (ATM), the following conditions are required:
- The bank card is valid
- The PIN code is correct
- Money is available in the user's account
The following are some possible interactions between the user and the ATM:
- The entered card is invalid The card is rejected
- The PIN code is wrong The ATM asks for another PIN code
- The requested amount is more than available in the user's account: The ATM asks for another amount
- The requested amount is available in the user's account The ATM dispenses the money Which test design technique should be used to cover all possible combinations of the input conditions?

• A. Boundary value analysis
• B. Use case based testing
• C. Equivalence class partitioning
• D. Decision table

正解：D

解説：
A decision table is a technique that should be used to cover all possible combinations of input conditions for withdrawing money from an Automated Teller Machine (ATM). A decision table shows combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects). A decision table consists of four quadrants: conditions (inputs), actions (outputs), condition entries (values) and action entries (results). A decision table can be used to test components that have multiple inputs and outputs that depend on logical combinations of conditions. For example, for testing the ATM, we can identify three input conditions: the bank card is valid, the PIN code is correct, and money is available in the user's account. We can also identify four output actions: the card is rejected, the ATM asks for another PIN code, the ATM asks for another amount, and the ATM dispenses the money. A decision table can show all possible combinations of these conditions and actions in a systematic way.
Use case based testing is not a technique that can cover all possible combinations of input conditions for withdrawing money from an ATM. Use case based testing is a technique that verifies that a software product or system meets its specified requirements or user stories by executing realistic scenarios or workflows. Use case based testing can be used to test components that have complex or dynamic interactions with users or other systems. For example, for testing the ATM, we can identify several use cases, such as withdraw money, check balance, transfer money, etc. Each use case can have one or more scenarios that describe the steps and outcomes of the interaction. However, use case based testing may not cover all possible combinations of input conditions, as some scenarios may be omitted or overlooked.
Boundary value analysis is not a technique that can cover all possible combinations of input conditions for withdrawing money from an ATM. Boundary value analysis is a technique that tests boundary values between partitions of equivalent data. Boundary values are values at the edge of an equivalence partition or at the smallest incremental distance on either side of an edge. Boundary value analysis can be used to test components that have input values that can be divided into partitions of equivalent data. For example, for testing the ATM, we can identify boundary values for the input amount, such as the minimum and maximum amount allowed by the system or the user's account. However, boundary value analysis may not cover all possible combinations of input conditions, as some conditions may not have boundary values or may not be related to input values.
Equivalence class partitioning is not a technique that can cover all possible combinations of input conditions for withdrawing money from an ATM. Equivalence class partitioning is a technique that divides the input data and output results of a software component into partitions of equivalent data. Each partition should contain data that is treated in the same way by the component. Equivalence class partitioning can be used to test components that have input values that can be divided into partitions of equivalent data. For example, for testing the ATM, we can identify equivalence partitions for the input amount, such as valid amount (within the range allowed by the system and the user's account) and invalid amount (outside the range allowed by the system or the user's account). However, equivalence class partitioning may not cover all possible combinations of input conditions, as some conditions may not be related to input values or may have more than two partitions. Verified Reference: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer], Chapter 4, page 34-46.

質問 # 36
Which type of software development product can undergo static testing?

• A. Static testing is done only on the requirements You need to execute the software in order to find defects in the code.
• B. Static tests should be performed on the installation and user guide documents as these documents are used by the end user.
• C. Static testing is done only on the code as part of the "code review" sessions Other documents are reviewed, but not by static testing.
• D. Any software development product can undergo static testing, including requirements specifications, design specifications and code.

正解：D

解説：
Static testing is a form of testing that does not involve executing the software, but rather analyzing it for defects, errors, or violations of standards. Static testing can be applied to any software development product, including requirements specifications, design specifications, code, test cases, test plans, user manuals, etc. Static testing can be done by using various techniques such as reviews, inspections, walkthroughs, checklists, static analysis tools, etc. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 7.

質問 # 37
Which of the following statements about decision tables are TRUE?
I Generally, decision tables are generated for low risk test items.
II Test cases derived from decision tables can be used for component tests.
III Several test cases can be selected for each column of the decision table.
IV The conditions in the decision table represent negative tests generally.

• A. II. Ill
• B. Generally, decision tables are generated for low risk test items. Decision tables are not related to risk level, but rather to complexity level. Decision tables are generated for test items that have complex logic or multiple conditions and actions that need to be tested.
• C. I. Ill
• D. II. IV
• E. I. IV

正解：A

解説：
IV. The conditions in the decision table represent negative tests generally. The conditions in the decision table represent both positive and negative tests, depending on whether they are valid or invalid inputs for the test item. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, Chapter 4, page 42-43.
Explanation:
A decision table is a technique that shows combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects). A decision table consists of four quadrants: conditions (inputs), actions (outputs), condition entries (values) and action entries (results). The following statements about decision tables are true:
II. Test cases derived from decision tables can be used for component tests. Decision tables can be used to test components that have multiple inputs and outputs that depend on logical combinations of conditions. Decision tables can help cover all possible combinations or scenarios in a systematic way.
III. Several test cases can be selected for each column of the decision table. A column of a decision table represents a unique combination of condition entries and action entries. Several test cases can be selected for each column by varying other input values or expected results that are not part of the decision table. The following statements about decision tables are false:

質問 # 38
A QA manager of a start-up company needs to implement within a week a low cost incident management tool. Which of the following is the best option?

• A. Manage the incidents through E-mails and phone calls
• B. Manage the incidents in a spreadsheet posted on the intranet
• C. Purchase and deploy an incident management tool
• D. Document incidents on a large board in the lab

正解：B

解説：
An incident is any event that occurs during testing that requires investigation. An incident management tool is a software tool that supports recording and tracking incidents throughout their life cycle. A QA manager of a start-up company needs to implement within a week a low cost incident management tool. The best option for this case is to manage the incidents in a spreadsheet posted on the intranet. This option has several advantages over other options:
It is low cost, as it does not require purchasing any additional software or hardware.
It is easy to implement within a week, as it does not require installing or configuring any complex software or hardware.
It is accessible and transparent, as it can be viewed and updated by anyone who has access to the intranet.
It is structured and organized, as it can store and display various information about incidents, such as identifier, summary, description, severity, priority, status, resolution, etc. The other options are not suitable for this case, as they have several disadvantages over the chosen option:
Documenting incidents on a large board in the lab is not a good option, as it is not accessible or transparent to anyone who is not physically present in the lab. It is also not structured or organized, as it may not store or display all the necessary information about incidents.
Purchasing and deploying an incident management tool is not a good option, as it is not low cost or easy to implement within a week. It may require spending a significant amount of money and time on acquiring, installing and configuring the software or hardware.
Managing the incidents through emails and phone calls is not a good option, as it is not structured or organized. It may lead to confusion, inconsistency or loss of information about incidents. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, Chapter 3, page 32-33.

質問 # 39
Which of the following options cover the test types performed during typical system testing phase:
I Usability
II Requirements based scenarios
III Testing parts of the code in isolation
IV Correct order of parameters in API calls

• A. I. II
• B. II. IV
• C. I, Ill
• D. III. IV

正解：A

解説：
System testing is a level of testing performed to evaluate the behavior and quality of a whole software product or system. System testing can include various types of testing, such as:
I) Usability testing: A type of testing that evaluates how easy, efficient and satisfying it is to use the software product or system from the user's perspective.
II) Requirements based scenarios testing: A type of testing that verifies that the software product or system meets its specified requirements or user stories by executing realistic scenarios or workflows. System testing does not include the following types of testing, as they are more suitable for lower levels of testing, such as unit testing or integration testing:
III) Testing parts of the code in isolation: A type of testing that verifies the functionality and quality of individual software components or units by isolating them from other components or units.
IV) Correct order of parameters in API calls: A type of testing that verifies the functionality and quality of software components or units that communicate with each other through application programming interfaces (APIs) by checking the correct order and format of parameters in API calls. Verified Reference: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer], Chapter 2, page 20-21; Chapter 4, page 34-35.

質問 # 40
Why should you choose a test technique?

• A. Because this way you cover the full scope of the product's functionality
• B. Because choosing a test technique is a common practice in software testing
• C. Because of the time constraints that usually accompany a test project
• D. Because you need to match the way you test to the content of the product under test

正解：D

解説：
You should choose a test technique because you need to match the way you test to the content of the product under test. A test technique is a method or process for deriving and selecting test cases based on some criteria or rules. Different test techniques are suitable for different types of software products, depending on their characteristics, functionalities, requirements, specifications, risks, etc. Choosing a test technique helps to ensure that the test cases are relevant, effective, and efficient for the product under test. The other options are not correct reasons to choose a test technique. Time constraints are not a factor for choosing a test technique, but rather for prioritizing or optimizing testing activities. Covering the full scope of the product's functionality is not a guarantee of choosing a test technique, but rather a goal of testing. Choosing a test technique is not a common practice in software testing, but rather a professional skill and responsibility. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 31.

質問 # 41
Which of the following statements regarding inspection is NOT true?

• A. The main purpose of an inspection is to find solutions to the problems.
• B. An inspection may be led by a trained moderator who shall not be the author.
• C. An inspection shall follow a formal process based on rules and checklists with entry and exit criteria
• D. An inspection can be performed by peers.

正解：A

解説：
An inspection is a type of review that follows a defined process with formal entry and exit criteria and roles and responsibilities for participants. An inspection can be performed by peers with different roles, such as moderator, author, reviewer and scribe. The following statement about inspection is not true:
B) The main purpose of an inspection is to find solutions to the problems. This statement is not true, as the main purpose of an inspection is to find defects or issues in a work product, not to find solutions to the problems. Finding solutions to the problems is a debugging or problem-solving activity that is usually performed by the author or developer after receiving the inspection report. The following statements about inspection are true:
A) An inspection may be led by a trained moderator who shall not be the author. This statement is true, as an inspection requires a moderator role who leads the inspection process and ensures that it follows the rules and standards. The moderator should be trained in inspection techniques and should not be the author of the work product under inspection, in order to avoid bias or conflict of interest.
C) An inspection can be performed by peers. This statement is true, as an inspection involves peer review, which means that the work product under inspection is evaluated by people who have similar roles or expertise as the author, but who are not directly involved in creating or modifying the work product.
D) An inspection shall follow a formal process based on rules and checklists with entry and exit criteria. This statement is true, as an inspection follows a formal process that consists of six main steps: planning, kick-off meeting, individual preparation, review meeting, rework and follow-up. Each step has defined rules and checklists to guide the participants and ensure consistency and quality. Each step also has entry and exit criteria to ensure that the prerequisites and objectives are met before moving to the next step. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, Chapter 3, page 28-29.

質問 # 42
During system testing phase of a word processor, a tester finds that on opening a file from a particular set of files, which are part of a critical workflow, the word processor crashes. Which of the following is the next step the tester should take poor to recording the deviation?

• A. Try to recreate the incident before reporting
• B. Send an email to the developer and not report the bug
• C. Try to identify the code fragment causing the problem
• D. Report the incident as is without any further action

正解：A

解説：
An incident is any event that occurs during testing that requires investigation. An incident report is a document that records the details of an incident. The next step the tester should take prior to recording the deviation is to try to recreate the incident before reporting. This can help confirm that the incident is reproducible and not caused by a random or external factor. This can also help gather more information about the incident, such as the steps to reproduce it, the expected and actual results, the severity and priority of the incident, or any screenshots or logs that can illustrate the incident. Trying to identify the code fragment causing the problem is not the next step the tester should take prior to recording the deviation, as this is a debugging activity that is usually performed by developers after receiving the incident report. Sending an email to the developer and not reporting the bug is not the next step the tester should take prior to recording the deviation, as this is an informal and unstructured way of communicating incidents that can lead to confusion, inconsistency or loss of information. Reporting the incident as is without any further action is not the next step the tester should take prior to recording the deviation, as this can result in incomplete or inaccurate incident reports that can hamper the investigation and resolution of incidents. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, Chapter 3, page 32-33.

質問 # 43
A software system checks age in order to determine which welcome screen to display. Age groups are:
Group I: 0-12
Group II; 13-18
Group III: over 18
Which of the below represent boundary values?

• A. (-1.0,11.12.13,14,18.19)
• B. (0.12.13.18.19)
• C. (4.5.15.20)
• D. (-1.0.12.13.18,19)

正解：D

解説：
A correct list of boundary values for the age input should include the minimum and maximum values of each age group (0, 12, 13, 18), as well as the values just below and above each boundary (-1, 19). Boundary value analysis is a test design technique that involves testing the values at or near the boundaries of an input domain or output range, as these values are more likely to cause errors than values in the middle. Option A satisfies this condition, as it has all six boundary values (-1, 0, 12, 13, 18, 19). Option B has two values from the same equivalence class (12 and 13), option C has only four boundary values (0, 12, 18, 19), and option D has no boundary values at all. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 34.

質問 # 44
Which of the following should be included in a test status report?
I Estimation details
II Total number of open and closed defects
III Actual effort spent
IV Defect reports
V Number of executed, failed, blocked tests

• A. III.V
• B. I. II. IV
• C. II, III
• D. II, III.V

正解：D

解説：
The following should be included in a test status report: total number of open and closed defects, actual effort spent, and number of executed, failed, and blocked tests. A test status report is a document that provides information on the results and status of testing activities for a given period or phase. A test status report should include information that is relevant, accurate, and timely for the intended audience and purpose. Some of the information that should be included in a test status report are: total number of open and closed defects, which can indicate the defect trend and defect density of the software product; actual effort spent, which can indicate the productivity and efficiency of the testing process; number of executed, failed, and blocked tests, which can indicate the test progress and test coverage of the software product. The following should not be included in a test status report: estimation details, defect reports, and impact analysis. Estimation details are not part of a test status report, but rather part of a test plan or a test estimation document. Estimation details provide information on the expected time, resources, and costs for testing activities, not on the actual results or status of testing activities. Defect reports are not part of a test status report, but rather separate documents that provide detailed information on individual defects found during testing. Defect reports include information such as defect description, defect severity, defect priority, defect status, defect resolution, etc. Defect reports can be referenced or summarized in a test status report, but not included in full. Impact analysis is not part of a test status report, but rather part of a risk assessment or prioritization process. Impact analysis provides information on the potential effects or consequences of a change or a defect on the software product or project. Impact analysis can be used to evaluate the amount or scope of testing to be performed, but not to report the results or status of testing activities. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 141.

質問 # 45
Which of the following statements about testware are correct?
I When closing the test activities, all the testware resources can be uninstalled and released II All the testware should be subject to Configuration Management III. The testware. at the end of the project, should be transferred to the organization responsible for maintenance IV The developers are responsible for the correct installation of the testware

• A. I, IV
• B. II, Ill
• C. I, Ill
• D. II, IV

正解：B

解説：
Testware is a term that refers to all artifacts produced during the testing process, such as test plans, test cases, test scripts, test data, test results, defect reports, etc. The following statements about testware are correct:
II) All the testware should be subject to Configuration Management. Configuration management is a process that establishes and maintains consistency among work products throughout their life cycle. Configuration management applies to all testware, as it helps ensure their quality and consistency, track their changes and defects, control their versions and access rights, and link them to other artifacts.
III) The testware at the end of the project should be transferred to the organization responsible for maintenance. Maintenance testing is testing performed on a software product after delivery to correct defects or improve performance or other attributes. Maintenance testing requires testware from previous testing activities or phases, such as test cases, test data, test results, etc. Therefore, the testware at the end of the project should be transferred to the organization responsible for maintenance testing, such as support team or maintenance team. The following statements about testware are incorrect:
I) When closing the test activities, all the testware resources can be uninstalled and released. This statement is incorrect, as some testware resources may still be needed for future testing activities or phases, such as maintenance testing or regression testing. Therefore, when closing the test activities, some testware resources should be archived and stored for future use, while others can be uninstalled and released.
IV) The developers are responsible for the correct installation of the testware. This statement is incorrect, as the testers are responsible for the correct installation of the testware. The testers should ensure that they have access to all necessary testware resources and that they are installed and configured properly before starting the test execution. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, Chapter 6, page 58-61.

質問 # 46
A test manager defined the following test levels in her test plan; Component, System and Acceptance.
Which Software Development lifecycle is the Test Manager most likely following?

• A. Prototyping
• B. Waterfall
• C. V-Model
• D. Agile

正解：C

解説：
The test manager is most likely following the V-model for software development. The V-model is a software development model that defines four testing levels that correspond to four development phases: component testing corresponds to component design, integration testing corresponds to architectural design, system testing corresponds to system requirements specification, and acceptance testing corresponds to user requirements specification. The V-model also defines the test planning and test execution activities for each testing level. Agile is a software development model that follows an iterative and incremental approach, where testing is integrated into each iteration and adapts to changing requirements and feedback. Waterfall is a software development model that follows a sequential and linear approach, where testing is performed after the development phase is completed. Prototyping is a software development model that involves creating a simplified version of the software to elicit user feedback and validate requirements before developing the final product. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 18.

質問 # 47
For a mandatory input field "ZIP code" the following rules are given:
1 - The valid ZIP code format is 5 numeric digits.
2 - The code has to exist in the post office's official ZIP code list
Using equivalence classes partitioning, how many test cases are required to test this field?

• A. 0
• B. 1
• C. 2
• D. 3

正解：A

解説：
Equivalence classes partitioning is a technique that divides the input data and output results of a software component into partitions of equivalent data. Each partition should contain data that is treated in the same way by the component. Equivalence classes partitioning can be used to reduce the number of test cases by selecting one representative value from each partition. For the ZIP code field, there are four equivalence classes based on the given rules:
Valid ZIP code format and valid ZIP code value (e.g., 12345)
Valid ZIP code format and invalid ZIP code value (e.g., 99999)
Invalid ZIP code format and valid ZIP code value (e.g., 1234)
Invalid ZIP code format and invalid ZIP code value (e.g., ABCDE) Therefore, four test cases are required to test this field, one for each equivalence class. Verified Reference: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer], Chapter 4, page 37-38.

質問 # 48
Which of the following is NOT a product risk?

• A. Failure-prone software is delivered
• B. Software does not perform the intended functions
• C. Poor software usability
• D. Problems in defining the right requirements

正解：D

解説：
Problems in defining the right requirements is not a product risk, but rather a project risk. A product risk is a risk that affects the quality or performance of the software product itself, such as poor usability, failure-prone functionality, security vulnerabilities, compatibility issues, etc. A project risk is a risk that affects the management or delivery of the software project itself, such as unrealistic schedule, insufficient resources, unclear scope, changing requirements, etc. The other options are examples of product risks, as they relate to the software product's characteristics or features. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 12.

質問 # 49
......

ISTQB-CTFL豪華セット学習ガイドにはオンライン試験エンジン：https://www.jpntest.com/shiken/ISTQB-CTFL-mondaishu

ISTQB-CTFLテスト準備トレーニング練習試験問題練習テスト：https://drive.google.com/open?id=13OLZysEAcjZvWFoZhdl-xvld6sOhM-M3