iSQI CTFL_Syll_4.0 Exam Questions in PDF and Online

QUESTION: 9

Which of the following statements is true?

Experience-based test techniques rely on the experience of testers to identify the root causes of defects found by black-box test techniques
Some of the most common test basis used by white-box test techniques include user stories, use cases and business processes
Experience-based test techniques are often useful to detect hidden defects that have not been targeted by black-box test techniques
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

Answer(s): C

Explanation:

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

Reveal Solution Next Question

QUESTION: 10

A new web app aims at offering a rich user experience. As a functional tester, you have run some functional tests to verify that, before releasing the app, such app works correctly on several mobile devices, all of which are listed as supported devices within the requirements specification. These tests were performed on stable and isolated test environments where you were the only user interacting with the application. All tests passed, but in some of those tests you observed the following issue: on some mobile devices only, the response time for two web pages containing images was extremely slow.

Based only on the given information, which of the following recommendation would you follow?

You should open a defect report providing detailed information on which devices and by running which tests you observed the issue
The issue is related to performance efficiency, not functionality. Thus, as a functional tester, you should not open any defect report as all the functional tests passed
You should not open any defect report as the problem is most likely due to poor hardware equipment on the devices where you observed the issue
You should not open any defect report and inform the test manager that the devices on which you observed the issue should no longer be supported so that they will be removed from the requirements specification

Answer(s): A

Explanation:

As a functional tester, you should open a defect report providing detailed information on which devices and by running which tests you observed the issue. A defect report is a document that records the occurrence, nature, and status of a defect detected during testing, and provides information for further investigation and resolution. A defect report should include relevant information such as the defect summary, the defect description, the defect severity, the defect priority, the defect status, the defect origin, the defect category, the defect reproduction steps, the defect screenshots, the defect attachments, etc. Opening a defect report is a good practice for any tester who finds a defect in the software system, regardless of the type or level of testing performed.
The other options are not recommended, because:

The issue is related to performance efficiency, not functionality, but that does not mean that as a functional tester, you should not open any defect report as all the functional tests passed. Performance efficiency is a quality characteristic that measures how well the software system performs its functions under stated conditions, such as the response time, the resource utilization, the throughput, etc. Performance efficiency is an important aspect of the user experience, especially for web applications that run on different devices and networks. Even if the functional tests passed, meaning that the software system met the functional requirements, the performance issue observed on some devices could still affect the user satisfaction, the usability, the reliability, and the security of the software system. Therefore, as a functional tester, you have the responsibility to report the performance issue as a defect, and provide as much information as possible to help the developers or the performance testers to investigate and resolve it.

Reveal Solution Next Question

QUESTION: 11

For each of the test cases to be executed, the following table specifies the priority order and dependencies on other test cases

Which of the following test execution schedules is compatible with the logical dependencies and allows executing the test cases in priority order?

TC4, TC3, TC2, TC6, TC5. TC1
TC4, TC6, TC3, TC2, TC5, TC1
TC3, TC5, TC6, TC1, TC4, TC3
TC4, TC3, TC2, TC6, TC1, TC5

Answer(s): D

Explanation:

This answer is correct because it follows the logical dependencies and allows executing the test cases in priority order. TC4, TC3, and TC2 are executed first because they have the highest priority. TC6 is executed next because it has a logical dependency on TC2. TC1 is executed next because it has a logical dependency on TC5. Finally, TC5 is executed last because it has the lowest priority.

Reference:

ISTQB Certified Tester Foundation Level (CTFL) v4.0 documents

Reveal Solution Next Question

QUESTION: 12

Which of the following statements best describes how configuration management supports testing?

Configuration management helps reduce testing effort by identifying a manageable number of test environment configurations in which to test the software, out of all possible configurations of the environment in which the software will be released
Configuration management is an administrative discipline that includes change control, which is the process of controlling the changes to identified items referred to as Configuration Items'
Configuration management is an approach to interoperability testing where tests are executed in the cloud, as the cloud can provide cost-effective access to multiple configurations of the test environments
Configuration management helps ensure that all relevant project documentation and software items are uniquely identified in all their versions and therefore can be unambiguously referenced in test documentation

Answer(s): D

Explanation:

This answer is correct because configuration management is a process of establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life. Configuration management helps ensure that all relevant project documentation and software items are uniquely identified in all their versions and therefore can be unambiguously referenced in test documentation. This supports testing by providing traceability, consistency, and control over the test artifacts and the software under test.

Reference:

: ISTQB Glossary of Testing Terms v4.0, : ISTQB Foundation Level Syllabus v4.0, Section 2.2.2.2

Reveal Solution Next Question

QUESTION: 13

Which of the following statements about exploratory testing is true?

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

Answer(s): B

Explanation:

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.

Reference:

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 Techniques.

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 Traceability.

Reveal Solution Next Question

QUESTION: 14

In a two-hour uninterrupted test session, performed as part of an iteration on an Agile project, a heuristic checklist was used to help the tester focus on some specific usability issues of a web application.
The unscripted tests produced by the tester's experience during such session belong to which one of the following testing quadrants?

Answer(s): C

Explanation:

The unscripted tests produced by the tester's experience during the two-hour test session belong to the testing quadrant
Q3. The testing quadrants are a classification of testing types based on two dimensions: the test objectives (whether the testing is focused on supporting the team or critiquing the product) and the test basis (whether the testing is based on the technology or the business). The testing quadrants are labeled as
Q1,
Q2,
Q3, and Q4, and each quadrant represents a different testing perspective, such as unit testing, acceptance testing, usability testing, or performance testing. The testing quadrant
Q3 corresponds to the testing types that have the objective of critiquing the product from the business perspective, such as exploratory testing, usability testing, user acceptance testing, alpha testing, beta testing, etc. The unscripted tests performed by the tester in the given scenario are examples of exploratory testing and usability testing, as they are based on the tester's experience, intuition, and learning of the web application, and they focus on some specific usability issues, such as the user interface, the user satisfaction, the user feedback, etc. The other options are incorrect, because:
The testing quadrant
Q1 corresponds to the testing types that have the objective of supporting the team from the technology perspective, such as unit testing, component testing, integration testing, system testing, etc. These testing types are usually performed by developers or testers who have access to the source code, the design, the architecture, or the configuration of the software system, and they aim to verify the functionality, the quality, and the reliability of the software system at different levels of integration.
The testing quadrant Q2 corresponds to the testing types that have the objective of supporting the team from the business perspective, such as functional testing, acceptance testing, story testing, scenario testing, etc. These testing types are usually performed by testers or customers who have access to the requirements, the specifications, the user stories, or the business processes of the software system, and they aim to validate that the software system meets the expectations and the needs of the users and the stakeholders.
The testing quadrant Q4 corresponds to the testing types that have the objective of critiquing the product from the technology perspective, such as performance testing, security testing, reliability testing, compatibility testing, etc. These testing types are usually performed by testers or specialists who have access to the tools, the metrics, the standards, or the benchmarks of the software system, and they aim to evaluate the non-functional aspects of the software system, such as the efficiency, the security, the reliability, or the compatibility of the software system under different conditions or environments.

Reference:

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 Lifecycles

ISTQB® Glossary of Testing Terms v4.0, Testing Quadrant, Exploratory Testing, Usability Testing, Unit Testing, Component Testing, Integration Testing, System Testing, Functional Testing, Acceptance

Testing, Story Testing, Scenario Testing, Performance Testing, Security Testing, Reliability Testing, Compatibility Testing

Reveal Solution Next Question

QUESTION: 15

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

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

Answer(s): D

Explanation:

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.

Reference:

ISTQB Foundation Level Syllabus v4.0, Section 2.5.3.2

Reveal Solution Next Question

QUESTION: 16

Which of the following statements about error guessing is true?

Error guessing is a system that adopts artificial intelligence to predict whether software components are likely to contain defects or not
Experienced testers, when applying error guessing, rely on the use of a high-level list of what needs to be tested as a guide to find defects
Error guessing refers to the ability of a system or component to continue normal operation despite the presence of erroneous inputs
Experienced testers, when applying error guessing technique, can anticipate where errors, defects and failures have occurred and target their tests at those issues

Answer(s): D

Explanation:

This answer is correct because error guessing is a test design technique where the experience and intuition of the tester are used to anticipate where errors, defects and failures have occurred or are likely to occur, and to design test cases to expose them. Error guessing can be based on factors such as the complexity of the system or component, the known or suspected weaknesses of the system or component, the previous history of defects, or the common types of errors in the domain or technology. Error guessing can be used as a complementary technique to other more systematic or formal techniques, or when there is insufficient information or time to apply them.

Reference:

ISTQB Glossary of Testing Terms v4.0, ISTQB Foundation Level Syllabus v4.0, Section 2.3.2.5

Reveal Solution Next Question

iSQI ISTQB Certified Tester Foundation Level (CTFL) v4.0 CTFL_Syll_4.0 Exam Questions in PDF

Free iSQI CTFL_Syll_4.0 Dumps Questions (page: 2)

QUESTION: 9

Explanation:

Reference:

QUESTION: 10

Explanation:

QUESTION: 11

Explanation:

Reference:

QUESTION: 12

Explanation:

Reference:

QUESTION: 13

Explanation:

Reference:

QUESTION: 14

Explanation:

Reference:

QUESTION: 15

Explanation:

Reference:

QUESTION: 16

Explanation:

Reference: