[Q34-Q58] Full CTFL_Syll_4.0 Practice Test and 202 unique questions with explanations waiting just for you!

NO.34 Which ONE of the following activities TYPICALLY belongs to the planning phase of the review process?

A separate defect report is created for each identified defect so that corrective actions can be tracked.

Each reviewer conducts an individual review to identify anomalies, recommendations, and questions.

The purpose and scope of the review are defined, as well as the work product to be reviewed and the exit criteria.

The reviewers analyze and discuss the anomalies found during the review in a joint meeting.

NO.35 Consider the following table, which contains information about test cases from the test management system:

Which ONE of the following optionsorganizes the test cases based on the statement coverage strategy, while considering practical constraints?

{TC 20; TC 30; TC 10; TC 40; TC 50; TC 70; TC 60; TC 80; TC 90}

{TC 10; TC 30; TC 20; TC 60; TC 40; TC 80; TC 90; TC 50; TC 70}

{TC 80; TC 70; TC 50; TC 60; TC 20; TC 30; TC 10; TC 40; TC 90}

{TC 60; TC 80; TC 40; TC 90; TC 50; TC 10; TC 70; TC 30; TC 20}

NO.36 Consider a given test plan which, among others, contains the following three sections: “Test Scope”, “Testing Communication”, and “Stakeholders”. The features of the test object to be tested and those excluded from the testing represent information that is:

not usually included in a test plan, and therefore in the given test plan it should not be specified neither within the three sections mentioned, nor within the others

usually included in a test plan and, in the given test plan, it is more likely to be specified within “Test Scope” rather than in the other two sections mentioned

usually included in a test plan and, in the given test plan, it is more likely to be specified within “Testing Communication” rather than in the other two sections mentioned

usually included in a test plan and, in the given test plan, it is more likely to be specified within
“Stakeholders” rather than in the other two sections mentioned

NO.37 Scenario 1 “Happy Tomatoes” (used for questions 20-22):
An intelligent application for agricultural use incorporates temperature sensors located at different points of an enclosure. The sensors measure and record the temperature at regular intervals and extract the statistical values for these measurements. These values include the average daily temperature.
A new variety of tomatoes is currently being grown and the”World Organization for Happy Tomatoes”has established temperature ranges related to vegetative development.
When the system establishes that the average temperature is within a specific range, it emits a value that will be used to monitor and control the crop.

Using theequivalence partitioningtechnique, identify the set of input values that provides the HIGHEST coverage.

{7,10,21,40}

{8,10,25,40}

{7,10,25,29}

{7,10,25,40}

NO.38 Can “cost” be regarded as Exit criteria?

Yes. Spending too much money on test ng will result in an unprofitable product, and having cost as an exit criterion helps avoid this

No. The financial value of product quality cannot be estimated, so it is incorrect to use cost as an exit criterion

Yes. Going by cost as an exit criterion constrains the testing project which will hello achieve the desired quality level defined for the project

No The cost of testing cannot be measured effectively, so it is incorrect to use cost as an exit criterion

NO.39 Which ONE of the following elements is TYPICALLY part of atest plan?

The budget and schedule for the test project.

A detailed analysis of the defects found and their causes.

A detailed report on the test results after the test project is completed.

A list of test logs from the test execution.

NO.40 Which of the following statements is true?

Functional testing focuses on what the system should do while non-functional testing on the internal structure of the system

Non-functional testing includes testing of both technical and non-technical quality characteristics

Testers who perform functional tests are generally expected to have more technical skills than testers who perform non-functional tests

The test techniques that can be used to design white-box tests are described in the ISO/IEC 25010 standard

NO.41 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

NO.42 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

NO.43 In addition to thorough testing of the requirements specification, a development team aims to involve users as early as possible in the development process, using practices such as prototyping, to ensure that the software systems being developed will meet the users’ expectations. This approach is especially useful at mitigating the risks associated with one of the seven testing principles, which one?

Tests wear out

Absence-of-errors fallacy

Working software over comprehensive documentation

Defects cluster together

NO.44 Which of the following statements is true?

Functional testing focuses on what the system should do while non-functional testing on the internal structure of the system

Non-functional testing includes testing of both technical and non-technical quality characteristics

Testers who perform functional tests are generally expected to have more technical skills than testers who perform non-functional tests

The test techniques that can be used to design white-box tests are described in the ISO/IEC 25010 standard

NO.45 Which of the following statements about static testing and dynamic testing is true?

Static testing is better suited than dynamic testing for highlighting issues that could indicate inappropriate code modularization

Dynamic testing can only be applied to executable work products, while static testing can only be applied to non-executable work products

Both dynamic testing and static testing cause failures, but failures caused by static testing are usually easier and cheaper to analyze

Security vulnerabilities can only be detected when the software is being executed, and thus they can only be detected through dynamic testing, not through static testing

NO.46 Which of the following statements about the value of maintaining traceability between the test basis and test work products is not true?

Traceability can be useful for assessing the impact of a change to a test basis item on the corresponding tests

Traceability can be useful for determining how many test basis items are covered by the corresponding tests

Traceability can be useful for determining the most suitable test techniques to be used in a testing project

Traceability can be useful to support the needs required by the auditing of testing

Traceability is the ability to trace the relationships between the items of the test basis, such as the requirements, the design, the risks, etc., and the test artifacts, such as the test cases, the test results, the defects, etc. Traceability can provide various benefits for the testing process, such as improving the test coverage, the test quality, the test efficiency, and the test communication. However, not all the statements given are true about the value of maintaining traceability between the test basis and test work products. The statement that is not true is option C, which says that test objectives should be the same for all test levels, although the number of tests designed at various levels can vary significantly. This statement is false, because test objectives are the goals or the purposes of testing, which can vary depending on the test level, the test type, the test technique, the test environment, the test stakeholder, etc. Test objectives can be defined in terms of the test basis, the test coverage, the test quality, the test risk, the test cost, the test time, etc. Test objectives should be specific, measurable, achievable, relevant, and time-bound, and they should be aligned with the project objectives and the quality characteristics. Test objectives should not be the same for all test levels, as different test levels have different focuses, scopes, and perspectives of testing, such as component testing, integration testing, system testing, and acceptance testing. The other statements are true about the value of maintaining traceability between the test basis and test work products, such as:
Traceability can be useful for assessing the impact of a change to a test basis item on the corresponding tests: This statement is true, because traceability can help to identify which tests are affected by a change in the test basis, such as a new requirement, a modified design, a revised risk, etc., and to determine the necessary actions to update, re-execute, or re-evaluate the tests. Traceability can also help to estimate the effort, the cost, and the time needed to implement the change and to verify its impact on the software system.
Traceability can be useful for determining how many test basis items are covered by the corresponding tests: This statement is true, because traceability can help to measure the test coverage, which is the degree to which the test basis is exercised by the test cases. Traceability can help to identify which test basis items are covered, partially covered, or not covered by the tests, and to evaluate the adequacy, the completeness, and the effectiveness of the testing process. Traceability can also help to identify the gaps, the overlaps, or the redundancies in the test coverage, and to prioritize, optimize, or improve the test cases.
Traceability can be useful to support the needs required by the auditing of testing: This statement is true, because traceability can help to provide evidence, documentation, and justification for the testing activities, results, and outcomes. Traceability can help to demonstrate that the testing process follows the standards, the regulations, the policies, and the best practices that are applicable to the software system, the project, or the organization. Traceability can also help to verify that the testing process meets the expectations, the needs, and the satisfaction of the users and the stakeholders. Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:
ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 1.2.2, Testing Policies, Strategies, and Test Approaches1 ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.1, Test Planning1 ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.2, Test Monitoring and Control1 ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.1.3, Test Analysis and Design1 ISTQB® Glossary of Testing Terms v4.0, Traceability, Test Basis, Test Artifact, Test Objective, Test Level, Test Coverage, Test Quality, Test Risk, Test Cost, Test Time2

NO.47 For a given set of test-cases, which of the following is a benefit of running these tests with a test automation tool?

The number of found bugs is reduced.

The time spent on repetitive tasks is reduced.

Test coverage is increased.

The total cost of the test project always decreases

NO.48 Which of the following are the phases of the ISTQB fundamental test process?

Test planning and control, Test analysis and design, Test implementation and execution, Evaluating ex t criteria and reporting. Test closure activities

Test planning, Test analysis and design. Test implementation and control. Checking test coverage and reporting, Test closure activities

Test planning and control, Test specification and design. Test implementation and execution, Evaluating test coverage and reporting, Retesting and regression testing, Test closure activities

Test planning. Test specification and design. Test implementation and execution. Evaluating exit criteria and reporting. Retesting and test closure activities

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.

NO.49 Which of the following statements about estimation of the test effort is WRONG?

Once the test effort is estimated, resources can be identified and a schedule can be drawn up.

Effort estimate can be inaccurate because the quality of the product under tests is not known.

Effort estimate depends on the budget of the project.

Experience based estimation is one of the estimation techniques.

Effort estimate does not depend on the budget of the project, but rather on the scope, complexity, and quality of the software product and the testing activities1. Budget is a constraint that may affect the feasibility and accuracy of the effort estimate, but it is not a factor that determines the effort estimate. Effort estimate is the amount of work required to complete the testing activities, measured in terms of person-hours, person-days, or person-months2.
The other options are correct because:
A) Once the test effort is estimated, resources can be identified and a schedule can be drawn up, as they are interrelated aspects of the test planning process3. Resources are the people, tools, equipment, and facilities needed to perform the testing activities4. Schedule is the time frame and sequence of the testing activities, aligned with the project milestones and deadlines5.
B) Effort estimate can be inaccurate because the quality of the product under tests is not known, as it affects the number and severity of the defects that may be found and the rework that may be needed to fix them6. Quality is the degree to which the software product satisfies the specified requirements and meets the needs and expectations of the users and clients7.
D) Experience based estimation is one of the estimation techniques, which relies on the judgment and expertise of the testers and other project stakeholders to estimate the test effort based on similar projects or tasks done in the past. Experience based estimation can be useful when there is a lack of historical data, formal methods, or detailed information about the software product and the testing activities.
Reference =
1 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 154
2 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 155
3 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 156
4 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 157
5 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 158
6 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 159
7 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 16
[8] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 160
[9] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 161

NO.50 Consider the followingiteration planning taskswhere a tester can provide value:
* Break down user stories into tasks (particularly testing tasks)
* Estimate test effort for all testing tasks
* Identify and refine functional and non-functional aspects of the test object Which ONE of the following tasks should be ADDED to the above list?

Determining the test strategy

Participating in the detailed risk analysis of user stories and determining their testability

Planning the testing for the release

Writing testable user stories and acceptance criteria

NO.51 Which ONE of the following options BEST describes black-box test techniques?

Black-box testing techniques are based on experience with the test object without knowing the internal structure.

In black-box testing techniques, test cases are created based on the software’s implementation.

Black-box testing techniques are based on analyzing the test object’s specified and implied behavior without knowledge of its internal data structure.

Black-box testing techniques involve analyzing the specified behavior of the test object without knowledge of its internal structure.

NO.52 What type of testing measures its effectiveness by tracking which lines of code were executed by the tests?

Acceptance testing

Structural testing

Integration testing

Exploratory testing

Structural testing is a type of testing that measures its effectiveness by tracking which lines of code were executed by the tests. Structural testing, also known as white-box testing or glass-box testing, is based on the internal structure, design, or implementation of the software. Structural testing aims to verify that the software meets the specified quality attributes, such as performance, security, reliability, or maintainability, by exercising the code paths, branches, statements, conditions, or data flows. Structural testing uses various coverage metrics, such as function coverage, line coverage, branch coverage, or statement coverage, to determine how much of the code has been tested and to identify any untested or unreachable parts of the code.
Structural testing can be applied at any level of testing, such as unit testing, integration testing, system testing, or acceptance testing, but it is more commonly used at lower levels, where the testers have access to the source code.
The other options are not correct because they are not types of testing that measure their effectiveness by tracking which lines of code were executed by the tests. Acceptance testing is a type of testing that verifies that the software meets the acceptance criteria and the user requirements. Acceptance testing is usually performed by the end-users or customers, who may not have access to the source code or the technical details of the software. Acceptance testing is more concerned with the functionality, usability, or suitability of the software, rather than its internal structure or implementation. Integration testing is a type of testing that verifies that the software components or subsystems work together as expected. Integration testing is usually performed by the developers or testers, who may use both structural and functional testing techniques to check the interfaces, interactions, or dependencies between the components or subsystems. Integration testing is more concerned with the integration logic, data flow, or communication of the software, rather than its individual lines of code. Exploratory testing is a type of testing that involves simultaneous learning, test design, and test execution. Exploratory testing is usually performed by the testers, who use their creativity, intuition, or experience to explore the software and discover any defects, risks, or opportunities for improvement. Exploratory testing is more concerned with the behavior, quality, or value of the software, rather than its internal structure or implementation. References = ISTQB Certified Tester Foundation Level (CTFL) v4.0 syllabus, Chapter 4: Test Techniques, Section 4.3: Structural Testing Techniques, Pages 51-54; Chapter
1: Fundamentals of Testing, Section 1.4: Testing Throughout the Software Development Lifecycle, Pages
11-13; Chapter 3: Static Testing, Section 3.4: Exploratory Testing, Pages 40-41.

NO.53 An alphanumeric password must be between 4 and 7 characters long and must contain at least one numeric character, one capital (uppercase) letter and one lowercase letter of the alphabet.
Which one of the following sets of test cases represents the correct outcome of a two-value boundary value analysis applied to the password length? (Note: test cases are separated by a semicolon)

1xA;aB11;Pq1ZZab;7iDD0a1x

aB11;99rSp:5NnN10;7iDD0a1x

1xB: aB11: 99rSp: 5NnN10; 4NnN10T; 44ghWn19

1RhT;rSp53;3N3e10;8sBdby

NO.54 Scenario 2 “Big Drop”:
A company”The Big Drop”providesbulk discounts and frequent customer discountsas follows:

How manypossible decision rulescan be extracted from this table?

5 decision rules

6 decision rules

32 decision rules

8 decision rules

NO.55 The following chart represents metrics related to testing of a project that was competed. Indicate what is represented by tie lines A, B and the axes X.Y

NO.56 What type of testing measures its effectiveness by tracking which lines of code were executed by the tests?

Acceptance testing

Structural testing

Integration testing

Exploratory testing

Structural testing is a type of testing that measures its effectiveness by tracking which lines of code were executed by the tests. Structural testing, also known as white-box testing or glass-box testing, is based on the internal structure, design, or implementation of the software. Structural testing aims to verify that the software meets the specified quality attributes, such as performance, security, reliability, or maintainability, by exercising the code paths, branches, statements, conditions, or data flows. Structural testing uses various coverage metrics, such as function coverage, line coverage, branch coverage, or statement coverage, to determine how much of the code has been tested and to identify any untested or unreachable parts of the code.
Structural testing can be applied at any level of testing, such as unit testing, integration testing, system testing, or acceptance testing, but it is more commonly used at lower levels, where the testers have access to the source code.
The other options are not correct because they are not types of testing that measure their effectiveness by tracking which lines of code were executed by the tests. Acceptance testing is a type of testing that verifies that the software meets the acceptance criteria and the user requirements. Acceptance testing is usually performed by the end-users or customers, who may not have access to the source code or the technical details of the software. Acceptance testing is more concerned with the functionality, usability, or suitability of the software, rather than its internal structure or implementation. Integration testing is a type of testing that verifies that the software components or subsystems work together as expected. Integration testing is usually performed by the developers or testers, who may use both structural and functional testing techniques to check the interfaces, interactions, or dependencies between the components or subsystems. Integration testing is more concerned with the integration logic, data flow, or communication of the software, rather than its individual lines of code. Exploratory testing is a type of testing that involves simultaneous learning, test design, and test execution. Exploratory testing is usually performed by the testers, who use their creativity, intuition, or experience to explore the software and discover any defects, risks, or opportunities for improvement. Exploratory testing is more concerned with the behavior, quality, or value of the software, rather than its internal structure or implementation. References = ISTQB Certified Tester Foundation Level (CTFL) v4.0 syllabus, Chapter 4: Test Techniques, Section 4.3: Structural Testing Techniques, Pages51-54; Chapter 1: Fundamentals of Testing, Section 1.4: Testing Throughout the Software Development Lifecycle, Pages 11-13; Chapter 3: Static Testing, Section 3.4: Exploratory Testing, Pages 40-41.

NO.57 Which ONE of the following work products TYPICALLY belongs to test execution?

Test logs that document the results of test execution.

Automated test scripts used for test execution.

A test plan that describes the test strategy and test objectives.

A list of test conditions prioritized during test analysis.

NO.58 Which of the following statements is true?

A defect does not always produce a failure, while a bug always produces a failure

A defect may cause a failure which, when occurring, always causes an error

Failures can be caused by defects, but also by environmental conditions

Bugs are defects found during component testing, while failures are defects found at higher test levels

Failures can be caused by defects, but also by environmental conditions. A failure is an event in which the software system does not perform a required function or performs a function incorrectly, according to the expected behavior. A defect is a flaw in the software system or a deviation from the requirements or the specifications, that may cause a failure. However, not all failures are caused by defects, as some failures may be caused by environmental conditions, such as hardware malfunctions, network interruptions, power outages, incompatible configurations, etc. Environmental conditions are factors that affect the operation of the software system, but are not part of the software system itself. The other statements are false, because:
* A defect does not always produce a failure, while a bug always produces a failure. This statement is false, because a defect may or may not produce a failure, depending on the inputs, the outputs, the states, or the scenarios of the software system, and a bug is just another term for a defect, so it has the same possibility of producing a failure as a defect. For example, a defect in a rarely used feature or a hidden branch of the code may never produce a failure, while a defect in a frequently used feature or a critical path of the code may produce a failure often. A bug is not a different concept from a defect, but rather a synonym or a colloquial term for a defect, so it has the same definition and implications as a defect.
* A defect may cause a failure which, when occurring, always causes an error. This statement is false, because an error is not a consequence of a failure, but rather a cause of a defect. An error is a human action or a mistake that produces a defect in the software system, such as a typo, a logic flaw, a requirement misunderstanding, etc. An error is not observable in the software system, but rather in the human mind or the human work products, such as the code, the design, the documentation, etc. A failure is not a cause of an error, but rather a result of a defect, which is a result of an error. For example, an error in the code may cause a defect in the software system, which may cause a failure in the software behavior.
* Bugs are defects found during component testing, while failures are defects found at higher test levels.
This statement is false, because bugs and failures are not different types of defects, but rather different terms for defects and their manifestations. As mentioned before, bugs are just another word for defects, and failures are the events in which the software system does not perform as expected due to defects.
Bugs and failures can be found at any test level, not only at component testing or higher test levels. Test levels are the stages of testing that correspond to the levels of integration of the software system, such as component testing, integration testing, system testing, and acceptance testing. Defects and failures can occur and be detected at any test level, depending on the test objectives, the test basis, the test techniques, and the test environment. References: ISTQB Certified Tester Foundation Level (CTFL) v4.
0 sources and documents:
* ISTQB Certified Tester Foundation Level Syllabus v4.0, Chapter 1.1.2, Testing and Quality1
* ISTQB Certified Tester Foundation Level Syllabus v4.0, Chapter 1.2.1, Testing Principles1
* ISTQB Certified Tester Foundation Level Syllabus v4.0, Chapter 1.3.1, Testing in Software Development Lifecycles1
* ISTQB Glossary of Testing Terms v4.0, Failure, Defect, Bug, Environmental Condition, Error, Test Level2

[Q34-Q58] Full CTFL_Syll_4.0 Practice Test and 202 unique questions with explanations waiting just for you!

Leave a Reply Cancel reply