ISTQB ISTQB-CTFL Online Practice Questions and Exam Preparation

ISTQB ISTQB-CTFL Online Questions & Answers

• Question 351:

  Who of the following has the best knowledge to decide what tests in a test project should be automated?

  A. The developer
  B. The customer
  C. The development manager
  D. The test leader
  D. The test leader

  ---

  Explanation

  The test leader is the person who is responsible for planning, monitoring, and controlling the test activities and resources in a test project. The test leader should have the best knowledge of the test objectives, scope, risks, resources, schedule, and quality criteria. The test leader should also be aware of the test automation criteria, such as the execution frequency, the test support, the team education, the roles and responsibilities, and the devs and testers collaboration1. Based on these factors, the test leader can decide which tests are suitable for automation and which are not, and prioritize them accordingly. The test leader can also coordinate with the test automation engineers, the developers, and the stakeholders to ensure the alignment of the test automation strategy with the test project goals and expectations.

  References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Chapter 2, Section 2.3.1, Page 152; ISTQB Glossary of Testing Terms v4.0, Page 403; ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Chapter 6, Section 6.1.1, Page 514; Top 8 Test Automation Criteria You Need To Fulfill - QAMIND1

• Question 352:

  Which ONE of the following options BEST describes Behavior-Driven Development (BDD)?

  A. Expresses the desired behavior of an application with test cases written in a simple form of natural language that is easy to understand by stakeholders--usually using the Given/When/Then format. Test cases are then automatically translated into executable tests.
  B. Defines test cases at a low level, close to the implementation, using unit test frameworks.
  C. Is primarily focused on non-functional testing techniques to ensure system reliability and performance.
  D. Requires testing to be performed after development is completed to validate software functionality.
  A. Expresses the desired behavior of an application with test cases written in a simple form of natural language that is easy to understand by stakeholders--usually using the Given/When/Then format. Test cases are then automatically translated into executable tests.

  ---

  Explanation

  Comprehensive and Detailed In-Depth Explanation:

  BDD emphasizes collaboration between developers, testers, and business stakeholders to define system behavior in a readable format (A). It typically uses the Given-When-Then syntax. Unlike unit testing (B), BDD is at a higher level of

  abstraction. It does not focus solely on non-functional testing (C) and encourages early testing rather than post-development validation (D).

  ISTQB CTFL v4.0 Syllabus, Section 2.1.5 ?Behavior-Driven Development (BDD)

• Question 353:

  A system has a self-diagnostics module that starts executing after the system is reset. The diagnostics are running 12 different tests on the systems memory hardware. The following is one of the requirements set for the diagnostics module:

  'The time taking the diagnostics tests to execute shall be less than 2 seconds' Which of the following is a failure related to the specified requirement?

  A. The diagnostic tests fail to start after a system reset
  B. The diagnostic tests take too much time to execute
  C. The diagnostic tests that measure the speed of the memory, fail
  D. The diagnostic tests fail due to incorrect implementation of the test code
  B. The diagnostic tests take too much time to execute

  ---

  Explanation

  A failure is an event in which a component or system does not perform a required function within specified limits1. A requirement is a condition or capability needed by a user to solve a problem or achieve an objective2. In this case, the requirement is that the diagnostics tests should execute in less than 2 seconds. Therefore, any event that violates this requirement is a failure. The only option that clearly violates this requirement is

  B. The diagnostic tests take too much time to execute. If the diagnostic tests take more than 2 seconds to complete, then they do not meet the specified limit and thus fail. The other options are not necessarily failures related to the specified requirement. Option A. The diagnostic tests fail to start after a system reset is a failure, but not related to the time limit. It is related to the functionality of the self- diagnostics module. Option

  C. The diagnostic tests that measure the speed of the memory, fail is also a failure, but not related to the time limit. It is related to the accuracy of the memory tests. Option

  D. The diagnostic tests fail due to incorrect implementation of the test code is also a failure, but not related to the time limit. It is related to the quality of the test code.

  References: ISTQB Certified Tester Foundation Level Syllabus v4.0, Requirements Engineering Fundamentals.

• Question 354:

  Which ONE of the following elements is TYPICALLY NOT part of a test progress report ?

  A. Obstacles and their workarounds
  B. A detailed assessment of product quality
  C. Test metrics to show the current status of the test process
  D. New or changed risks
  B. A detailed assessment of product quality

  ---

  Explanation

  Comprehensive and Detailed In-Depth Explanation:

  A test progress report provides an overview of testing activities, metrics, and identified risks. It focuses on tracking testing progress rather than evaluating overall product quality (B) , which is typically included in a test summary report after testing is completed.

  (A)

  is correct because obstacles (challenges) are reported to ensure test execution stays on track.

  (C)

  is correct as test metrics help stakeholders track execution progress.

  (D)

  is correct because new or changed risks impact test focus and priorities.

  A test progress report tracks execution and informs stakeholders about ongoing testing activities .

  ISTQB CTFL v4.0 Syllabus, Section 5.3 ?Test Monitoring and Control

• Question 355:

  Which of the following is a test-first approach, where tests that express a shared understanding from stakeholders of how the application is expected to work, are first written in business-readable language (following the Given/When/Then format), and then made executable to drive development?

  A. Test-Driven Development (TDD)
  B. Acceptance Test-Driven Development (ATDD)
  C. Behavior-Driven Development (BDD)
  D. Domain-Driven Design (DDD)
  C. Behavior-Driven Development (BDD)

  ---

  Explanation

  This answer is correct because Behavior-Driven Development (BDD) is a test-first approach, where tests that express a shared understanding from stakeholders of how the application is expected to work, are first written in business-readable language (following the Given/When/Then format), and then made executable to drive development. BDD is a collaborative approach that involves testers, developers, business analysts, product owners, and other stakeholders in defining the expected behavior of the application using scenarios that describe the preconditions, actions, and outcomes of the application. BDD scenarios are written using a domain-specific language (DSL) that can be translated into executable test cases using tools such as Cucumber or SpecFlow. BDD aims to improve communication, collaboration, and feedback among the team members, and to deliver software that meets the customer's needs and expectations.

  References: ISTQB Glossary of Testing Terms v4.0, ISTQB Foundation Level Syllabus v4.0, Section 3.1.1.4, Requirements Engineering Fundamentals.

• Question 356:

  Which of the following types of tools is BEST suited for determining source code compliance with the guidelines provided by a coding standard?

  A. Containerisation tool
  B. Fault seeding tool.
  C. Static analysis tool.
  D. Test data preparation tool
  C. Static analysis tool.

  ---

  Explanation

  A static analysis tool is best suited for determining source code compliance with coding standards. These tools analyze the code without executing it and can check for adherence to coding standards, syntax errors, and other static properties of the code. The ISTQB CTFL syllabus emphasizes the role of static analysis tools in verifying that code meets predefined standards and guidelines.

  References: ISTQB CTFL Syllabus, Section on static testing and tools.

• Question 357:

  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. II, III
  D. II, III.V
  I. II. IV
  D. II, III.V

  ---

  Explanation

  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

  References: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 141.

• Question 358:

  Which ONE of the following options BEST describes the purpose of confirmation testing versus regression testing?

  A. The purpose of confirmation testing is to confirm that the defect giving rise to a failure has been successfully fixed. The regression test aims to ensure that no defects have been introduced or discovered in unmodified areas of the software as a result of the changes made.
  B. Confirmation testing ensures the entire system functions as expected, whereas regression testing focuses only on modified components.
  C. Confirmation testing verifies all system requirements, while regression testing ensures that no additional test cases are needed.
  D. Regression testing and confirmation testing are interchangeable and serve the same purpose.
  A. The purpose of confirmation testing is to confirm that the defect giving rise to a failure has been successfully fixed. The regression test aims to ensure that no defects have been introduced or discovered in unmodified areas of the software as a result of the changes made.

  ---

  Explanation

  Comprehensive and Detailed In-Depth Explanation:

  Confirmation testing is performed after a defect is fixed to confirm it no longer exists (A). Regression testing ensures new defects have not been introduced in unchanged parts of the system. Regression testing is broader than confirmation testing and covers unmodified areas affected by the changes. Options B, C, and D misrepresent the relationship and scope of these tests.

  ISTQB CTFL v4.0 Syllabus, Section 2.2.3 ?Confirmation Testing and Regression Testing

• Question 359:

  Which of the following statements about static testing is true?

  A. Static testing is NOT suitable for finding coding defects. For this, dynamic testing is necessary.
  B. Static testing should be done instead of dynamic testing, as both find the same defects.
  C. Static tests are NOT suitable to evaluate the quality of work results.
  D. It makes sense to perform static testing before dynamic testing, because defects can be found earlier or at lower cost.
  D. It makes sense to perform static testing before dynamic testing, because defects can be found earlier or at lower cost.

  ---

  Explanation

• Question 360:

  A program got 100% decision coverage in a test. Which of the following statements is then guaranteed to be true?

  A. Every executable statement Is covered.
  B. Every output equivalence class has been tested.
  C. Every input equivalence class has been tested.
  D. The "dead" code has not been covered.
  A. Every executable statement Is covered.

  ---

  Explanation

  If a program got 100% decision coverage in a test, then it is guaranteed that every executable statement is covered. Decision coverage (also known as branch coverage) is a type of structural coverage (also known as white-box coverage) that measures how many decision outcomes have been exercised by a test suite. A decision outcome is a possible result of a decision point (such as an if-then-else statement) in a program's code. Decision coverage requires that each decision point has both true and false outcomes executed at least once by a test suite. Decision coverage implies statement coverage, which is another type of structural coverage that measures how many executable statements have been executed by a test suite. Statement coverage requires that each executable statement is executed at least once by a test suite. Therefore, if a program got 100% decision coverage in a test, then it also got 100% statement coverage in a test, which means that every executable statement is covered. The other options are not guaranteed to be true if a program got 100% decision coverage in a test. Every output equivalence class has been tested and every input equivalence class has been tested are not guaranteed to be true if a program got 100% decision coverage in a test, because equivalence classes are based on functional requirements or specifications, not on code structure or logic. Equivalence classes are used in specification-based testing (also known as black-box testing), which is a type of testing that does not consider the internal structure or implementation of the system under test. Decision coverage is used in structure-based testing (also known as white-box testing), which is a type of testing that considers the internal structure or implementation of the system under test. Therefore, achieving 100% decision coverage does not imply achieving 100% equivalence class coverage. The "dead" code has not been covered is not guaranteed to be true if a program got 100% decision coverage in a test, because dead code (also known as unreachable code) is code that can never be executed due to logical errors or design flaws. Dead code can reduce readability and maintainability of the code, as well as increase complexity and size. Decision coverage does not account for dead code, as it only considers the decision outcomes that are possible to execute. Therefore, achieving 100% decision coverage does not imply that the dead code has not been covered. Verified

  References: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 36.