2024年最新のお手軽に合格させるISTQB-CTFL試験にはこちらが提供する問題集PDFテストエンジン
ISTQB-CTFLのPDFで合格させるスゴ問題集でISTQB-CTFL最新のリアル試験問題
質問 # 44
Which of the following is a key characteristic of informal reviews?
- A. Low cost
- B. Individual preparation
- C. Kick-off meeting
- D. Metrics analysis
正解：A
解説：
A key characteristic of informal reviews is low cost. Informal reviews are a type of review that does not follow a formal process or have any formal documentation. Informal reviews are usually performed by individuals or small groups of peers or colleagues who have some knowledge or interest in the product under review. Informal reviews can be done at any time and for any purpose, such as checking for errors, clarifying doubts, sharing ideas, etc. Informal reviews have low cost, as they do not require much time, effort, or resources to conduct. The other options are not key characteristics of informal reviews. Kick-off meeting is a characteristic of formal reviews, such as inspections or walkthroughs. Kick-off meeting is a meeting that is held before the review process starts, where the roles and responsibilities of the participants are defined, the objectives and scope of the review are agreed, and the logistics and schedule of the review are planned. Individual preparation is a characteristic of formal reviews, such as inspections or walkthroughs. Individual preparation is an activity that is performed by the reviewers before the review meeting, where they examine the product under review and identify any issues or questions that need to be discussed or resolved during the review meeting. Metrics analysis is a characteristic of formal reviews, such as inspections or walkthroughs. Metrics analysis is an activity that is performed after the review process is completed, where the data and results of the review are collected and analyzed to measure the effectiveness and efficiency of the review, as well as to identify any improvement actions or lessons learned for future reviews. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 9.
質問 # 45
Which of the following are the phases of the ISTQB fundamental test process?
- A. Test planning and control, Test specification and design. Test implementation and execution, Evaluating test coverage and reporting, Retesting and regression testing, Test closure activities
- B. Test planning, Test analysis and design. Test implementation and control. Checking test coverage and reporting, Test closure activities
- C. Test planning. Test specification and design. Test implementation and execution. Evaluating exit criteria and reporting. Retesting and test closure activities
- D. Test planning and control, Test analysis and design, Test implementation and execution, Evaluating ex t criteria and reporting. Test closure activities
正解：D
解説：
The ISTQB fundamental test process consists of five main phases, as described in the ISTQB Foundation Level Syllabus, Version 4.0, 2018, Section 2.2, page 15:
* Test planning and control: This phase involves defining the test objectives, scope, strategy, resources, schedule, risks, and metrics, as well as monitoring and controlling the test activities and results throughout the test process.
* Test analysis and design: This phase involves analyzing the test basis (such as requirements, specifications, or user stories) to identify test conditions (such as features, functions, or scenarios) that need to be tested, and designing test cases and test procedures (such as inputs, expected outcomes, and execution steps) to cover the test conditions. This phase also involves evaluating the testability of the test basis and the test items (such as software or system components), and selecting and implementing test techniques (such as equivalence partitioning, boundary value analysis, or state transition testing) to achieve the test objectives and optimize the test coverage and efficiency.
* Test implementation and execution: This phase involves preparing the test environment (such as hardware, software, data, or tools) and testware (such as test cases, test procedures, test data, or test scripts) for test execution, and executing the test procedures or scripts according to the test plan and schedule. This phase also involves logging the outcome of test execution, comparing the actual results with the expected results, and reporting any discrepancies as incidents (such as defects, errors, or failures).
* Evaluating exit criteria and reporting: This phase involves checking if the planned test activities have been completed and the exit criteria (such as quality, coverage, or risk levels) have been met, and reporting the test results and outcomes to the stakeholders. This phase also involves making recommendations for the release or acceptance decision based on the test results and outcomes, and identifying any residual risks (such as known defects or untested areas) that need to be addressed or mitigated.
* Test closure activities: This phase involves finalizing and archiving the testware and test environment for future reuse, and evaluating the test process and the test project against the test objectives and the test plan. This phase also involves identifying any lessons learned and best practices, and communicating the findings and suggestions for improvement to the relevant parties.
References = ISTQB Certified Tester Foundation Level Syllabus, Version 4.0, 2018, Section 2.2, page 15; ISTQB Glossary of Testing Terms, Version 4.0, 2018, pages 37-38; ISTQB CTFL 4.0 - Sample Exam - Answers, Version 1.1, 2023, Question 88, page 32.
質問 # 46
In which of the following test documents would you expect to find test exit criteria described9
- A. Test plan
- B. Test design specification
- C. Project plan
- D. Requirements specification
正解：A
解説：
Test exit criteria are the conditions that must be fulfilled before concluding a particular testing phase. These criteria act as a checkpoint to assess whether we have achieved the testing objectives and are done with testing1. Test exit criteria are typically defined in the test plan document, which is one of the outputs of the test planning phase. The test plan document describes the scope, approach, resources, and schedule of the testing activities. It also identifies the test items, the features to be tested, the testing tasks, the risks, and the test deliverables2. According to the ISTQB Certified Tester Foundation Level Syllabus v4.0, the test plan document should include the following information related to the test exit criteria3:
The criteria for evaluating test completion, such as the percentage of test cases executed, the percentage of test coverage achieved, the number and severity of defects found and fixed, the quality and reliability of the software product, and the stakeholder satisfaction.
The criteria for evaluating test process improvement, such as the adherence to the test strategy, the efficiency and effectiveness of the testing activities, the lessons learned and best practices identified, and the recommendations for future improvements.
Therefore, the test plan document is the most appropriate test document to find the test exit criteria described. The other options, such as test design specification, project plan, and requirements specification, are not directly related to the test exit criteria. The test design specification describes the test cases and test procedures for a specific test level or test type3. The project plan describes the overall objectives, scope, assumptions, risks, and deliverables of the software project4. The requirements specification describes the functional and non-functional requirements of the software product5. None of these documents specify the conditions for ending the testing process or evaluating the testing outcomes. Reference = ISTQB Certified Tester Foundation Level Syllabus v4.0, Entry and Exit Criteria in Software Testing | Baeldung on Computer Science, Entry And Exit Criteria In Software Testing - Rishabh Software, Entry and Exit Criteria in Software Testing Life Cycle - STLC [2022 Updated] - Testsigma Blog, ISTQB releases Certified Tester Foundation Level v4.0 (CTFL).
質問 # 47
When should component integration tests be carried out?
- A. Integration tests should always be done after system tests
- B. Integration tests should always be done before system tests
- C. Integration tests can be done before or after system tests
- D. Integration tests should be done at the customer's site, after acceptance tests
正解：B
解説：
Component integration tests are designed to verify the interactions and interfaces between integrated components. These tests should be carried out after component testing (where individual components are tested in isolation) but before system testing (where the entire system is tested as a whole). This ensures that any issues arising from the integration of components are identified and resolved early in the testing process, making option D the correct answer.
質問 # 48
Your manager asked you when testing will be complete. In order to answer this question, you'll most likely use:
- A. Your colleagues advice
- B. A Test Oracle
- C. Test progress reports
- D. A conversion spreadsheet
正解：C
解説：
When a manager asks when testing will be complete, the most appropriate and informative resource to provide an answer is test progress reports (Option A). Test progress reports contain detailed information on the status of testing activities, including what has been accomplished, what remains to be done, the results of the tests conducted, and any issues or risks that might impact the completion of testing. These reports allow for an informed assessment of the testing progress and estimation of when testing might be completed. Options B, C, and D do not provide the structured, detailed, and specific information required to accurately answer the manager's question about the completion of testing.
質問 # 49
A test engineer finds a defect while testing. After the developer has fixed the defect, the test engineer decides to re-run a complete section of the tests. Which of the following is correct?
- A. The test engineer should re-run the tests, in order to ensure that new defects have not been introduced by the fix.
- B. The test engineer should not re-run the tests, they should be part of the developer tests.
- C. The lest engineer should not re-run the tests, as they have already been run, and results recorded.
- D. The test engineer should re-run the tests, because the defect shows that the test cases need to be updated.
正解：A
解説：
The test engineer should re-run the tests, in order to ensure that new defects have not been introduced by the fix. This is also known as regression testing, which is a type of testing that verifies that previously tested software still performs correctly after a change. Regression testing helps to detect any side effects or unintended consequences of a fix or a modification. The other options are incorrect reasons for re-running the tests. The test engineer should not re-run the tests, as they have already been run, and results recorded, because this ignores the possibility of new defects caused by the fix. The test engineer should not re-run the tests, they should be part of the developer tests, because this assumes that developer tests are sufficient and reliable, which may not be true. The test engineer should not re-run the tests, because the defect shows that the test cases need to be updated, because this does not address the impact of the fix on other test cases or functionalities. Verified References: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 41.
質問 # 50
Which of the following statements is not correct?
- A. Looking for defects in a system may require Ignoring system details
- B. Testing is often seen as a destructive activity instead of constructive activity
- C. Identifying defects may be perceived as criticism against product
- D. Looking for defects in system requires professional pessimism and curiosity
正解：A
解説：
Looking for defects in a system does not require ignoring system details, but rather paying attention to them and understanding how they affect the system's quality, functionality, and usability. Ignoring system details could lead to missing important defects or testing irrelevant aspects of the system.
Identifying defects may be perceived as criticism against product, especially by the developers or stakeholders who are invested in the product's success. However, identifying defects is not meant to be a personal attack, but rather a constructive feedback that helps to improve the product and ensure its alignment with the requirements and expectations of the users and clients.
Looking for defects in system requires professional pessimism and curiosity, as testers need to anticipate and explore the possible ways that the system could fail, malfunction, or behave unexpectedly. Professional pessimism means being skeptical and critical of the system's quality and reliability, while curiosity means being eager and interested in finding out the root causes and consequences of the defects.
Testing is often seen as a destructive activity instead of constructive activity, as it involves finding and reporting the flaws and weaknesses of the system, rather than creating or enhancing it. However, testing is actually a constructive activity, as it contributes to the system's improvement, verification, validation, and optimization, and ultimately to the delivery of a high-quality product that meets the needs and expectations of the users and clients.
質問 # 51
Which of the following statements about test reports are TRUE?
I Test reports shall be approved by the test team.
II Test reports shall give stakeholders information as basis for decisions.
Ill Test reports shall summarize what happened through a period of testing.
IV Test reports shall be approved by the development team, the test team and the customer V Test reports shall include information about remaining risks.
- A. I, II, IV
- B. I, III, v
- C. II, III, IV
- D. II, III, V
正解：D
解説：
Statements II, III and V are true about test reports. Test reports are documents that provide information on the results and status of testing activities for a given period or phase. Test reports should give stakeholders information as basis for decisions, such as whether to release the software product, whether to continue testing, whether to change the scope or priorities of testing, etc. Test reports should summarize what happened through a period of testing, such as what test cases were executed, what defects were found, what risks were identified, what issues were encountered, what achievements were made, etc. Test reports should include information about remaining risks, such as what defects are still open, what test cases are still pending, what functionalities are still untested, what uncertainties are still unresolved, etc. Statements I and IV are not true about test reports. Test reports do not need to be approved by the test team, the development team, or the customer, unless it is specified by the test policy or the test plan. Test reports only need to be reviewed and verified by the test leader or the test manager before being distributed to the intended recipients. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 141.
質問 # 52
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. Agile
- B. Prototyping
- C. Waterfall
- D. V-Model
正解：D
解説：
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.
質問 # 53
Which of the following is the most important task of a typical test leader?
- A. To prepare and acquire test data.
- B. To set up the test environment.
- C. To coordinate the test strategy with project managers.
- D. To automate tests.
正解：C
解説：
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.
質問 # 54
Which of the following is a function of a dynamic analysis tool?
- A. Provide support for release of baselines consisting of configuration items
- B. Monitor the allocation, use and de-allocation of memory during run-time of a program
- C. Provide support for traceability of tests, test results and incidents to source documents
- D. Execute programs step-by-step in order to reproduce failures and find corresponding defects
正解：B
解説：
A dynamic analysis tool is a tool that performs analysis of a software product based on its behavior during execution. A dynamic analysis tool can monitor various aspects of a program's run-time performance, such as memory usage, CPU load, response time, or resource leaks. A dynamic analysis tool can monitor the allocation, use and de-allocation of memory during run-time of a program, which can help detect defects such as memory leaks, buffer overflows, or memory corruption. A dynamic analysis tool cannot provide support for traceability of tests, test results and incidents to source documents, as this is a function of a test management tool. A dynamic analysis tool cannot execute programs step-by-step in order to reproduce failures and find corresponding defects, as this is a function of a debugging tool. A dynamic analysis tool cannot provide support for release of baselines consisting of configuration items, as this is a function of a configuration management tool. Verified Reference: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer], Chapter 6, page 56-57.
質問 # 55
Which sequence of stated in the answer choices is correct in accordance with the following figure depicting the life-cycle of a defect?
- A. S0->S1->S2~>S3->S4
- B. S0->S1->S2->S3->S5->S1->S2->S3
- C. S0->S1 ->S2->S3->S5->S3->S4
- D. S0->S1->S2->S3->S5->S1
正解：C
解説：
According to the ISTQB Certified Tester Foundation Level (CTFL) v4.0, the life cycle of a defect typically follows a sequence from its discovery to its closure. In the provided figure, it starts with S0 (New), moves to S1 (Assigned), then to S2 (Resolved), followed by S3 (Verified). If the defect is not fixed, it can be Re-opened (S5) and goes back for verification (S3). Once verified, it is Closed (S4). Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Section 1.4.3, Page 17.
質問 # 56
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. IV
- B. I, IV
- C. II. Ill
- D. I. Ill
正解：C
解説：
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:
* I. 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.
* 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 References: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, Chapter 4, page 42-43.
質問 # 57
In what way do Configuration Management effects testing?
- A. Proper configuration management ensures that testers can uniquely identity the tested item
- B. There is very little influence of configuration management practices on the test project.
- C. Without proper configuration management, test planning cannot proceed.
- D. Configuration management is important for developers, not for testers
正解：A
解説：
Configuration management is a process that establishes and maintains consistency among work products throughout their life cycle. Configuration management affects testing in various ways, such as:
Proper configuration management ensures that testers can uniquely identify the tested item, which can help traceability, reproducibility and accountability.
Proper configuration management ensures that testers have access to consistent versions of software components and testware, which can help reliability, compatibility and efficiency.
Proper configuration management ensures that testers can track changes and defects in software components and testware, which can help verification, validation and reporting.
Proper configuration management ensures that testers can control the configuration of the test environment, which can help stability, security and performance. Configuration management is not a prerequisite for test planning, as test planning can proceed without configuration management, although it may be less effective or accurate. Configuration management is not important for developers only, but for testers as well, as it affects the quality and consistency of the testing process and products. Configuration management has a significant influence on the test project, as it affects various aspects of testing, such as traceability, reproducibility, reliability, compatibility, efficiency, verification, validation, reporting, stability, security and performance. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, Chapter 6, page 60-61.
質問 # 58
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->S1->S2->S3
- B. S0->S1->S2->S3->S5->S3->S4
- C. S0->S1->S2->S3->S5^>S1
- D. S0->S1->S2->S3->S4
正解：A
解説：
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.
質問 # 59
......
ISTQB-CTFL問題集はあなたの合格を必ず保証します：https://www.goshiken.com/ISTQB/ISTQB-CTFL-mondaishu.html
有効なISTQB-CTFLテスト解答ISTQB-CTFL試験PDF：https://drive.google.com/open?id=1YMcQOUKy_VIfm3u60d9o88pqYQolH6OY