2024

ISTQB
ISTQB-CTFL Exam
ISTQB Foundation Level

Questions & Answers

(Full Version)

Thank you for Purchasing ISTQB-CTFL Exam

[Link]
Questions PDF 1/89

Product Questions: 130

Question: 1

Which of the following is correct with regards to debugging?

A. Debugging identifies the cause of a failure

B. Debugging is often performed by test engineers
C. Debugging is considered part of the testing activities
D. Debugging is intended to find as many defects as possible in the code

Answer: A
Explanation:

Debugging is the process of finding, analyzing and removing the causes of failures in software.
Debugging is not considered part of testing, but rather a development activity that can involve
testing. Debugging is not intended to find as many defects as possible, but rather to fix the specific
failure that was observed. Debugging is usually performed by developers, not by test engineers.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, Chapter
1, page 6.

Question: 2

Which statement about use case testing is true?

A. The lest cases are designed to find defects in the data flew.
B. The test cases are designed to be used by real users, not by professional testers
C. The test cases are always designed by customers or end users.
D. The test cases are designed to find defects in the process flow.

Answer: D
Explanation:

Use case testing is a technique that helps identify test cases that exercise the whole system on a
transaction by transaction basis from start to finish. Use cases are descriptions of how users interact
with the system to achieve a specific goal. Use case testing is not focused on data flow, but rather on
process flow. Use case testing can be performed by professional testers, customers or end users,

[Link]
Questions PDF 2/89

depending on the context. Use case testing does not require the test cases to be designed by
customers or end users, but rather by anyone who has access to the use case specifications. Verified
Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, Chapter 4, page
36.

Question: 3

A software module to be used in a mission critical application incorporates an algorithm for secure
transmission of dat
a.
Which review type is most appropriate to ensure high quality and technical correctness of the
algorithm?
A. Walkthrough
B. Informal Review
C. Technical Review
D. Management Review

Answer: C
Explanation:

A technical review is a type of formal review that involves a team of technical experts who evaluate a
software product against a set of predefined quality criteria. A technical review is suitable for
ensuring high quality and technical correctness of complex or critical software components, such as
algorithms, architectures or designs. A technical review is not a walkthrough, which is an informal
review led by the author of the work product. A technical review is not an informal review, which is a
review that does not follow a defined process and has no formal entry or exit criteria. A technical
review is not a management review, which is a type of formal review that focuses on business
aspects and project progress. Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018
Syllabus - Springer, Chapter 3, page 29-30.

Question: 4

Which of the following is NOT a deciding factor m determining the extent of testing required?

A. Level of risk of the product or features

B. Budget to do testing
C. A particular tester involved in testing
D. Time available to do testing

Answer: C
Explanation:

The extent of testing required for a software product depends on various factors, such as the level of
risk, the budget, and the time available. The level of risk reflects the potential impact of failures on
the stakeholders and the environment. The budget determines how much resources can be allocated
for testing. The time available defines the schedule and deadlines for testing activities. The particular
tester involved in testing is not a deciding factor for the extent of testing required, as testing should

[Link]
Questions PDF 3/89

be based on objective criteria and not on personal preferences or abilities. Verified Reference: [A
Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer], Chapter 2, page 14-15.

Question: 5

ST is a Software Testing organization which utilizes a testing knowledge base. Access to ST knowledge
base can be either full or limited. Access level is determined based on ST certification and testing
experience as follows:
1. If ST certified, with less than 5 years testing experience - allow limited access
2. If ST certified, 5-10 years of testing experience - allow full access
3. If not ST certified with 5-10 years of testing experience - allow limited access.
What would be the results for:
A - ST certified. 12 years of testing experience
B - Not ST certified. 7 years of testing experience
C - Not ST certified. 3 years of testing experience

A. A - unknown
B - limned access
C- unknown
B. A - full access
B - limited access
C - unknown
C. A - full access
B - limited access
C - limited access
D. A - unknown
B - full access
C - unknown

Answer: B
Explanation:

The correct answer can be derived by applying the given rules to each case:
A is ST certified and has 12 years of testing experience, which is more than 10 years. Therefore, A
does not match any of the rules and the result is unknown.
B is not ST certified and has 7 years of testing experience, which is between 5 and 10 years.
Therefore, B matches rule 3 and the result is limited access.
C is not ST certified and has 3 years of testing experience, which is less than 5 years. Therefore, C
does not match any of the rules and the result is unknown. Verified Reference: This question does
not require any external references, as it is based on logical reasoning.

Question: 6
A system computes prices for bus tickets. The price depends on
- the passenger type (baby, child, adult, senior citizen, student, military)
- the travelling type (as single or in a group)

[Link]
Questions PDF 4/89

- the distance (zone 1. 2. 3)

- the kind of transport (ordinary, express)
Which of the following test techniques is the most appropriate one for testing the price
computation?

A. Statement coverage
B. State transition testing
C. Equivalence partitioning
D. Use case testing

Answer: C
Explanation:

Equivalence partitioning is a technique that divides the input data and output results of a software
component into partitions of equivalent data. Each partition should contain data that is treated in the
same way by the component. Equivalence partitioning can be used to reduce the number of test
cases by selecting one representative value from each partition. Equivalence partitioning is suitable
for testing the price computation, as it can identify different partitions based on the passenger type,
the travelling type, the distance and the kind of transport. Equivalence partitioning is not statement
coverage, which is a technique that measures how many executable statements in a source code are
executed by a test suite. Statement coverage is not appropriate for testing the price computation, as
it does not consider the input data or output results. Equivalence partitioning is not state transition
testing, which is a technique that models how a system transitions from one state to another
depending on events or conditions. State transition testing is not relevant for testing the price
computation, as it does not involve any states or transitions. Equivalence partitioning is not use case
testing, which is a technique that tests how users interact with a system to achieve a specific goal.
Use case testing is not applicable for testing the price computation, as it does not focus on a single
function or component. Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018
Syllabus - Springer], Chapter 4, page 37-38.

Question: 7

Which test approach will best fit a new project, with little documentation and high probability for
bugs?

A. Exploratory testing
B. Requirements based testing
C. Metric based approach
D. Regression testing

Answer: A
Explanation:

Exploratory testing is an approach to testing that emphasizes learning, test design and test execution
at the same time. Exploratory testing relies on the tester’s skills, creativity and intuition to explore
the software under test and discover defects. Exploratory testing is suitable for a new project with
little documentation and high probability for bugs, as it can help uncover unknown requirements,

[Link]
Questions PDF 5/89

assumptions and risks. Exploratory testing is not requirements based testing, which is an approach to
testing that derives test cases from documented requirements or specifications. Requirements based
testing is not feasible for a new project with little documentation, as it requires clear and complete
requirements to be available. Exploratory testing is not metric based approach, which is an approach
to testing that uses quantitative measures to monitor and control the testing process and evaluate
the quality of the software product. Metric based approach is not effective for a new project with
high probability for bugs, as it may not capture all aspects of quality and may lead to false confidence
or unrealistic expectations. Exploratory testing is not regression testing, which is an approach to
testing that verifies that previously tested software still performs correctly after changes. Regression
testing is not relevant for a new project with no previous versions or baselines. Verified Reference: [A
Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer], Chapter 5, page 47-48.

Question: 8

The following requirement is given “Set X to be the sum of Y and Z”.

All the following four implementations have bugs.
Which one of the following bugs can be caught by Static Analysis?

A. int x = 1.
int y = 2.
int y = 3.
X = y=z;
B. int x = 1.
int y = 2.
int z = 3.
X = z-y
C. int x = 1.
Int y = 2.
Int z = 3.
Z = x +y
[Link] y = 2
Int z = 3.
Y = z+y

Answer: A
Explanation:

Static analysis is a technique that analyzes the source code or other software artifacts without
executing them. Static analysis can detect defects such as syntax errors, coding standards violations,
potential security vulnerabilities, or logical flaws. Static analysis can catch the bug in the first
implementation, as it contains two syntax errors: the variable y is declared twice, and the assignment
statement X = y=z is invalid. Static analysis cannot catch the bugs in the other three implementations,
as they are logical errors that do not violate any syntax rules, but produce incorrect results. Verified
Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer], Chapter 3, page
25-26.

Question: 9

[Link]
Questions PDF 6/89

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

A. 8
B. 3
C. 6
D. 4

Answer: D
Explanation:

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

Question: 10

A bank software has a feature of locking down accounts that have and overdraft higher than $10,000.
Due to a bug in the code, the system locks down accounts once they reached $1000 overdraft.
Based on this context, which of the following is correct statement

A. It is an example of a defect that it goes undetected, will cause harm to the end customer and to
the company (the bank)
B. It is an example of a defect, that if goes undetected, will cause harm to the end customer but not
to the company (the bank)
C. It is an example of a defect that if goes undetected, will not cause harm to the end customer, but
will cause harm to the company (the bank)
D. It is an example of a defect that if goes undetected, will not cause any real harm to either the end
customer or to the company (the bank)

Answer: A
Explanation:

A defect is a flaw in a component or system that can cause the component or system to fail to

[Link]
Questions PDF 7/89

perform its required function. A defect can cause harm to the end customer, the company, or both,
depending on the impact and severity of the failure. In this case, the defect in the code causes the
system to lock down accounts that have an overdraft higher than $1000, instead of $10,000. This can
cause harm to the end customer, as they may lose access to their funds and face inconvenience or
financial difficulties. This can also cause harm to the company, as they may lose customer trust and
satisfaction, face legal issues or complaints, or incur additional costs for fixing the defect and
restoring the accounts. Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018
Syllabus - Springer], Chapter 1, page 3-4.

Question: 11
Which of the following is a function of a dynamic analysis tool?

A. Provide support for traceability of tests, test results and incidents to source documents
B. Monitor the allocation, use and de-allocation of memory during run-time of a program
C. Execute programs step-by-step in order to reproduce failures and find corresponding defects
D. Provide support for release of baselines consisting of configuration items

Answer: B
Explanation:

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.

Question: 12

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->S4

[Link]
Questions PDF 8/89

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

Answer: C
Explanation:

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.

Question: 13
Which of the following statements about Experience Based Techniques (EBT) is correct?

A. EBT use tests derived from the test engineers' previous experience with similar technologies.
B. EBT is based on the ability of the test engineer to implement various testing techniques.
C. EBT is done as a second stage of testing, after non-experienced-based testing took place.
D. EBT require broad and deep knowledge in testing but not necessarily in the application or
technological domain.

Answer: A
Explanation:

Experience based techniques (EBT) are techniques that use the knowledge, intuition and skills of the
test engineers to design and execute tests. EBT use tests derived from the test engineers’ previous
experience with similar technologies, domains, applications or systems. EBT are not based on the
ability of the test engineer to implement various testing techniques, but rather on their personal

[Link]
Questions PDF 9/89

judgment and creativity. EBT are not done as a second stage of testing, after non-experience-based
testing took place, but rather as a complementary or alternative approach to other techniques. EBT
require broad and deep knowledge in both testing and the application or technological domain, as
this can help the test engineer identify potential risks, scenarios or defects. Verified Reference: [A
Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer], Chapter 5, page 48-49.

Question: 14

Software was found lo take much more time than the stated requirement of less than one second to
save a file. Upon investigation it was found that there was an unnecessary check inside a loop which
was slowing down the file-save operation. The software not being able to meet the desired response
time is an example of

A. It is not a defect
B. Defect
C. Error
D. Failure

Answer: D
Explanation:

A failure is an event in which a component or system does not perform a required function within
specified limits. A failure is observable by the software users or other stakeholders. A failure is
caused by one or more defects in the software. In this case, the software not being able to meet the
desired response time is an example of a failure, as it deviates from the stated requirement and
affects the user experience. It is not a defect, which is a flaw in the software that causes the failure. It
is not an error, which is a human action that produces an incorrect result. It is not a non-defect, as it
clearly violates a specified requirement. Verified Reference: [A Study Guide to the ISTQB® Foundation
Level 2018 Syllabus - Springer], Chapter 1, page 4.

Question: 15
Which of the following statements about independent testing is WRONG?

A. Independent testing is necessary because developers don't know any testing.

B. Independent testing is best suited for the system test level.
C. A certain degree of independence makes the tester more effective at finding defects.
D. Independent test teams may find other types of detects than developers who are familiar with the
system's structure.

Answer: A
Explanation:

Independent testing is testing performed by a person or group that is independent of the

development team. Independent testing can have various degrees of independence, ranging from
testers who are part of the same organization as developers to testers who are external contractors
or consultants. Independent testing can have various benefits, such as reducing bias, increasing

[Link]
Questions PDF 10/89

objectivity, improving quality, or providing different perspectives. Independent testing is not

necessary because developers don’t know any testing, as this is a wrong and disrespectful statement.
Developers can perform various types of testing, such as unit testing, component testing, or
integration testing. However, independent testing can complement developer testing by providing
additional levels of verification and validation, such as system testing, acceptance testing, or non-
functional testing. Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus -
Springer], Chapter 2, page 16-17.

Question: 16
In which of the following cases you would NOT execute maintenance testing?

A. Retirement of the software or system

B. Modifications to a released software or system
C. Migration of the system data to a replacement system
D. Update to the Maintainability requirements during the development phase

Answer: D
Explanation:

Maintenance testing is testing performed on a software product after delivery to correct defects or
improve performance or other attributes. Maintenance testing can be triggered by various
situations, such as modifications to a released software or system, migration of the system data to a
replacement system, or retirement of the software or system. Maintenance testing is not executed
when there is an update to the maintainability requirements during the development phase, as this
is not a maintenance situation but rather a change request that should be handled by the
development process. Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018
Syllabus - Springer], Chapter 2, page 18-19.

Question: 17
Manager responsibilities in formal review includes ad except one of the following:

A. Planning the review

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

Answer: B
Explanation:

A formal review is a type of review that follows a defined process with formal entry and exit criteria
and roles and responsibilities for participants. A formal review can have various roles involved, such
as manager, moderator, author, reviewer and scribe. The manager responsibilities in formal review
include all except one of the following:
Planning the review (correct responsibility)

[Link]
Questions PDF 11/89

Determines if the review objectives have been met (incorrect responsibility)

Decide on the execution of reviews (correct responsibility)
Allocate time for review (correct responsibility) The responsibility of determining if the review
objectives have been met belongs to the moderator role, not to the manager role. Verified
Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer], Chapter 3, page
28-29.

Question: 18
Which ONE of the following statements about acceptance testing is NOT correct?

A. Testing of disaster recovery and backup/restore is usually NOT part of acceptance testing.
B. The customers or system users are often responsible for the acceptance testing.
C. The main goal of acceptance testing is to build confidence in the system, not find defects.
D. Acceptance testing is the last level of testing performed prior to system release.

Answer: A
Explanation:

Acceptance testing is a level of testing performed to verify that a software product meets the agreed
acceptance criteria and is acceptable for delivery. Acceptance testing is often performed by the
customers or system users, who are the main stakeholders of the software product. The main goal of
acceptance testing is to build confidence in the system, not find defects, as defects should have been
detected and fixed in earlier levels of testing. Acceptance testing is the last level of testing performed
prior to system release, unless there are any changes or fixes that require re-testing. Testing of
disaster recovery and backup/restore is usually part of acceptance testing, as these are important
aspects of system reliability and security that affect the customer satisfaction and trust. Therefore,
statement A is not correct, while statements B, C and D are correct. Verified Reference: A Study
Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, Chapter 2, page 20-21.

Question: 19

Which are the MAIN goals of risk management in a software project?

A. To increase the success probability for the project regardless of costs.

B. To increase focus on preventative processes and to increase satisfaction for the testers.
C. To control contractual problems and minimize the impacts of company policies.
D. To reduce the probability of undesired situations and to reduce the effect of potential impact.

Answer: D
Explanation:

Risk management is a process that identifies, analyzes, evaluates and mitigates risks in a software
project. Risks are factors that may negatively affect the quality, schedule, budget or scope of a
software project. The main goals of risk management in a software project are to reduce the
probability of undesired situations and to reduce the effect of potential impact. This can be achieved
by applying various strategies, such as avoidance, transfer, reduction or acceptance. Risk

[Link]
Questions PDF 12/89

management does not aim to increase the success probability for the project regardless of costs, as
this may not be feasible or realistic. Risk management does not aim to increase focus on preventative
processes and to increase satisfaction for the testers, as these are secondary or indirect outcomes.
Risk management does not aim to control contractual problems and minimize the impacts of
company policies, as these are specific types of risks that may not apply to all projects. Verified
Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, Chapter 2, page
14-15.

Question: 20

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

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

Answer: D
Explanation:

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

Question: 21

In what way do Configuration Management effects testing?

[Link]
Questions PDF 13/89

A. Without proper configuration management, test planning cannot proceed.

B. Proper configuration management ensures that testers can uniquely identity the tested item
C. Configuration management is important for developers, not for testers
D. There is very little influence of configuration management practices on the test project.

Answer: B
Explanation:

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.

Question: 22

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

A. Try to recreate the incident before reporting

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

Answer: A
Explanation:

An incident is any event that occurs during testing that requires investigation. An incident report is a
document that records the details of an incident. The next step the tester should take prior to
recording the deviation is to try to recreate the incident before reporting. This can help confirm that
the incident is reproducible and not caused by a random or external factor. This can also help gather
more information about the incident, such as the steps to reproduce it, the expected and actual
results, the severity and priority of the incident, or any screenshots or logs that can illustrate the

[Link]
Questions PDF 14/89

incident. Trying to identify the code fragment causing the problem is not the next step the tester
should take prior to recording the deviation, as this is a debugging activity that is usually performed
by developers after receiving the incident report. Sending an email to the developer and not
reporting the bug is not the next step the tester should take prior to recording the deviation, as this is
an informal and unstructured way of communicating incidents that can lead to confusion,
inconsistency or loss of information. Reporting the incident as is without any further action is not the
next step the tester should take prior to recording the deviation, as this can result in incomplete or
inaccurate incident reports that can hamper the investigation and resolution of incidents. Verified
Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, Chapter 3, page
32-33.

Question: 23
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. I, Ill
B. I, IV
C. II, IV
D. II, Ill

Answer: D
Explanation:

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

[Link]
Questions PDF 15/89

Question: 24

Consider the following statements about risk-based testing.

I) Risk-based testing has the objective to reduce the level of protect risks.
II) Tests should be prioritized to find tie critical detects as early as possible.
III) Non-testing activities may also help to reduce risk
IV) Risks have to be reassessed on a regular basis.
V) The project stakeholders can give useful input to determine the risks

A. I III IV and V are true. II is false.

B. II, III IV and V are correct. I is false.
C. I, II and IV are true. III and V are false.
D. II, Ill and V are true. 1 ants Iv are false.

Answer: B
Explanation:

The following statements about risk-based testing are correct:

II) Tests should be prioritized to find tie critical detects as early as possible. Risk-based testing
involves prioritizing tests based on risk level, which reflects both the likelihood and impact of defects
or failures. Tests with higher risk level should be executed earlier than tests with lower risk level, in
order to find and fix critical defects as soon as possible.
III) Non-testing activities may also help to reduce risk. Risk-based testing does not only involve
testing activities, but also other activities that can help mitigate risks, such as reviews, inspections,
audits, simulations or prototyping.

Question: 25

As the last stage of a test cycle of an embedded device, you are performing exploratory testing. You
observed that some character. (A, X and Z) sent via a serial port to the device do not get registered
on the device whereas they should be. You suspect that this could be due to a wrong configuration of
the "bit parity" parameter.
Which of the following items of an incident report would you be UNABLE to write down based on
this information?

A. Expected result
B. Test case identifier
C. Test setup details
D. Actual result

Answer: B
Explanation:

An incident report is a document that records the details of an incident. An incident report typically
contains the following items:
Identifier: A unique identifier for the incident report
Summary: A concise summary of the incident

[Link]
Questions PDF 16/89

Description: A detailed description of the incident, including the steps to reproduce it, the expected
and actual results, and any relevant screenshots or logs
Severity: The degree of impact that the incident has on the system
Priority: The level of urgency for resolving the incident
Status: The current state of the incident, such as new, open, resolved, closed, etc.
Resolution: The action taken to resolve the incident, such as fix, workaround, reject, etc. Based on
the information given in the question, the tester would be able to write down all of these items
except for the test case identifier. A test case identifier is a unique identifier for a test case that is
used to link it to other test artifacts, such as test plans, test scripts, test results or incident reports.
However, since the tester is performing exploratory testing, there is no predefined test case that can
be associated with the incident. Exploratory testing is an approach to testing that emphasizes
learning, test design and test execution at the same time. Exploratory testing relies on the tester’s
skills, creativity and intuition to explore the software under test and discover defects. Exploratory
testing does not use formal test cases or scripts, but rather uses test charters or missions that guide
the tester’s actions and objectives. Verified Reference: A Study Guide to the ISTQB® Foundation Level
2018 Syllabus - Springer, Chapter 3, page 32-33; Chapter 5, page 47-48.

Question: 26

Which of the following statements about re-testing and regression testing are TRUE?
I, Re-testing should be performed after a defect is fixed.
II, Regression testing should always be performed after a defect is fixed.
III, Re-testing and regression testing may be performed at any test level.
IV, Regression testing may include functional, non-functional and structural testing.
V, Re-testing should be included in the debugging activity.

A. I, III, Iv
B. II, v
C. I, Ill
D. II, IV, V

Answer: A
Explanation:

The following statements about re-testing and regression testing are true:
I) Re-testing should be performed after a defect is fixed. Re-testing is a type of testing that verifies
that a defect has been successfully resolved by executing a test case that previously failed due to that
defect. Re-testing should be performed after a defect is fixed and delivered to ensure that it does not
cause any new failures or side effects.
III) Re-testing and regression testing may be performed at any test level. Re-testing and regression
testing are not limited to a specific test level, but can be applied at any level depending on the
context and objectives. For example, re-testing and regression testing can be performed at unit level,
integration level, system level or acceptance level.
IV) Regression testing may include functional, non-functional and structural testing. Regression
testing is a type of testing that verifies that previously tested software still performs correctly after
changes. Regression testing may include various types of testing depending on the scope and
purpose of the changes. For example, regression testing may include functional testing to check if the
software meets its requirements, non-functional testing to check if the software meets its quality

[Link]
Questions PDF 17/89

attributes, or structural testing to check if the software meets its design or code standards. The
following statement about re-testing and regression testing is false:
II) Regression testing should always be performed after a defect is fixed. Regression testing is not
always necessary after a defect is fixed, as some defects may have a low impact or low likelihood of
affecting other parts of the software. Regression testing should be performed after a defect is fixed
only if there is a risk of introducing new defects or causing existing defects due to the changes made
to fix the defect. Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus -
Springer, Chapter 2, page 19; Chapter 4, page 45.

Question: 27

Which of the following can be considered a VALID exit criterion?

I Estimates of defect density or reliability measures.
II, The completion and publication of an exhaustive Test Report.
III, Accuracy measures, such as code, functionality or risk coverage.
IV Residual risks such as lack of code coverage in certain areas.

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

Answer: A
Explanation:

An exit criterion is a condition that defines when a test activity has been completed or when a test
phase can be concluded. An exit criterion can be based on various factors, such as:
I) Estimates of defect density or reliability measures. These are quantitative measures that indicate
how many defects are present in the software product or how likely it is to fail under certain
conditions. These can be used as exit criteria to ensure that the software product meets a certain
level of quality or performance before moving to the next phase or releasing it to the customer.
III) Accuracy measures, such as code coverage, functionality coverage or risk coverage. These are
quantitative measures that indicate how much of the software product has been tested in terms of
its code, functionality or risk. These can be used as exit criteria to ensure that the test suite is
adequate or complete before moving to the next phase or releasing it to the customer.
IV) Residual risks, such as lack of code coverage in certain areas, unresolved defects or unknown
factors. These are qualitative measures that indicate the remaining risks or uncertainties associated
with the software product after testing. These can be used as exit criteria to ensure that the residual
risks are acceptable or manageable before moving to the next phase or releasing it to the customer.
The following factor is not a valid exit criterion:
II) The completion and publication of an exhaustive Test Report. This is not a valid exit criterion, as it
does not reflect the quality or completeness of the testing process or product. A test report is a
document that summarizes the results and outcomes of a test activity or phase. A test report can be
used as an input for deciding whether to exit a test activity or phase, but it is not a condition that
defines when to exit. Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018
Syllabus - Springer, Chapter 2, page 13; Chapter 6, page 58-59.

[Link]
Questions PDF 18/89

Question: 28

Which of the following statements about testware are correct?

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

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

Answer: A
Explanation:

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

Question: 29

[Link]
Questions PDF 19/89

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

A. Document incidents on a large board in the lab

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

Answer: D
Explanation:

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

Question: 30
Which of the following statements regarding inspection is NOT true?

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

Answer: B
Explanation:

[Link]
Questions PDF 20/89

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

Question: 31

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

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

Answer: B
Explanation:

System testing is a level of testing performed to evaluate the behavior and quality of a whole
software product or system. System testing can include various types of testing, such as:
I) Usability testing: A type of testing that evaluates how easy, efficient and satisfying it is to use the
software product or system from the user’s perspective.
II) Requirements based scenarios testing: A type of testing that verifies that the software product or

[Link]
Questions PDF 21/89

system meets its specified requirements or user stories by executing realistic scenarios or workflows.
System testing does not include the following types of testing, as they are more suitable for lower
levels of testing, such as unit testing or integration testing:
III) Testing parts of the code in isolation: A type of testing that verifies the functionality and quality of
individual software components or units by isolating them from other components or units.
IV) Correct order of parameters in API calls: A type of testing that verifies the functionality and
quality of software components or units that communicate with each other through application
programming interfaces (APIs) by checking the correct order and format of parameters in API calls.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer], Chapter
2, page 20-21; Chapter 4, page 34-35.

Question: 32

A mid-size software product development company has analyzed data related to defects detected in
its product and found out that detects fixed in earlier builds are getting re-opened after a few
months.
The company management now seeks your advice in order to reverse this trend and prevent re-
opening of defects fixed earlier.
What would be your FIRST recommendation to the company?

A. Automate existing test suits so that lesser time is spent on execution of each test, and more tests
can be executed m the available time thus leading to a lower probability of defects slipping by
B. Verify existing regression test suite are adequate, and augment it, if required, in order to ensure
that defects fixed earlier get re-tested in each subsequent build
C. Analyze the product modules containing maximum defects, and get them thoroughly tested and
defects fixed as a one-time activity
D. If required, tram the teams responsible for development and testing of the modules containing
maximum number of defects, and if this does not help, replace them with more knowledgeable
people

Answer: B
Explanation:

Regression testing is a type of testing that verifies that previously tested software still performs
correctly after changes. Regression testing can help prevent re-opening of defects fixed earlier by
ensuring that they do not cause any new failures or side effects. The first recommendation to the
company is to verify existing regression test suite are adequate, and augment it, if required, in order
to ensure that defects fixed earlier get re-tested in each subsequent build. This can help improve the
coverage and effectiveness of regression testing and detect any regression defects as soon as
possible. Automating existing test suites may also help reduce the time and effort required for
regression testing, but this is not the first recommendation, as automation may not be feasible or
cost-effective for all test cases. Analyzing the product modules containing maximum defects and
getting them thoroughly tested and defects fixed as a one-time activity may also help reduce the
defect density and improve the quality of those modules, but this is not the first recommendation, as
it does not address the root cause of re-opening defects fixed earlier. Training or replacing the teams
responsible for development and testing of the modules containing maximum number of defects
may also help improve their skills or performance, but this is not the first recommendation, as it may
not be necessary or appropriate for all teams. Verified Reference: [A Study Guide to the ISTQB®

[Link]
Questions PDF 22/89

Foundation Level 2018 Syllabus - Springer], Chapter 2, page 19; Chapter 4, page 45.

Question: 33
Which of the following does MOT describe a reason why testing is necessary?

A. The customer decided that 100% branch coverage shall be achieved

B. The acquisition of test automation tools was based on the assumption that it will be used m all
projects
C. For avionics and pharmaceutical systems software testing is mandated by standards
D. The risks associated with delivering the system are far higher than the cost of testing

Answer: B
Explanation:

Testing is necessary for various reasons, such as:

To detect defects and failures that may affect the quality, performance, reliability or security of a
software product or system
To verify that a software product or system meets its specified requirements, expectations and
standards
To validate that a software product or system fulfills its intended purpose and satisfies its
stakeholders’ needs
To provide information and feedback about the status and risks of a software product or system
To comply with regulations or contractual obligations that mandate testing for certain types of
software products or systems The following statements describe some reasons why testing is
necessary:
A) The customer decided that 100% branch coverage shall be achieved. This is a reason why testing is
necessary, as it reflects a contractual obligation or a quality standard that requires testing to measure
and achieve a certain level of code coverage.
C) For avionics and pharmaceutical systems software testing is mandated by standards. This is a
reason why testing is necessary, as it reflects a regulation or a compliance requirement that
mandates testing for certain types of software products or systems that have high safety or security
risks.
D) The risks associated with delivering the system are far higher than the cost of testing. This is a
reason why testing is necessary, as it reflects a risk-based approach that considers testing as an
investment to reduce the probability and impact of potential failures or defects. The following
statement does not describe a reason why testing is necessary:
B) The acquisition of test automation tools was based on the assumption that it will be used m all
projects. This is not a reason why testing is necessary, as it reflects a business decision or a resource
allocation that does not justify the need or purpose of testing. Test automation tools are not always
suitable or beneficial for all projects, and testing can be performed with or without test automation
tools. Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer],
Chapter 1, page 5-6.

Question: 34
Which of the following statements is CORRECT?

[Link]
Questions PDF 23/89

A. Test cases are made up of input values, expected results and actual results developed to cover test
objectives
B. Test cases describe items or events to test that are derived from the test basis during the test
analysis activity
C. Test cases are sequences of actions for test execution specified during the test implementation
activity D. Test cases are derived during the test design activity to cover test objectives or test
conditions

Answer: C
Explanation:

A test case is a set of input values, execution preconditions, expected results and execution
postconditions, developed for a particular objective or test condition. A test case is a sequence of
actions for test execution that can be followed by a tester or a test automation tool. A test case is
specified during the test implementation activity, which is the activity that prepares the testware
needed for test execution. A test case does not include actual results, as these are obtained during
test execution and compared with the expected results. A test case does not describe items or events
to test, as these are derived from the test basis during the test analysis activity. A test case is not
derived during the test design activity, as this is the activity that specifies the test conditions or
objectives that need to be tested. Verified Reference: [A Study Guide to the ISTQB® Foundation Level
2018 Syllabus - Springer], Chapter 3, page 23-24; Chapter 4, page 34.

Question: 35
Given the following requirement:
Requirement ID: 2 8
Requirement Description Additional Entrance Fee
Detailed Description
An additional fee of S3 is charged during the weekend, but
1) Visitors aged under 7 are not charged.
2) Visitors aged 7 to 13 inclusive get a 20% discount off the additional fee.
3) Visitors aged greater than 65 get a 50% discount off the additional fee.
Age should be an integer of 0 or above.
Weekend means Friday to Sunday inclusive.
Which of the following statements is NOT correct?

A. Thursday is a valid input boundary value.

B. A minimum of 6 valid test cases are derived from boundary value analysis based on input age.
C. $3.01 is a valid output boundary value.
D. 7 and 13 are boundary values for the equivalence partition including age 10.

Answer: A
Explanation:

Boundary value analysis is a technique that tests boundary values between partitions of equivalent
data. Boundary values are values at the edge of an equivalence partition or at the smallest

[Link]
Questions PDF 24/89

incremental distance on either side of an edge. Boundary value analysis can be applied to both input
and output values. Based on the given requirement, we can identify two input values: age and
weekend. Age should be an integer of 0 or above, and weekend means Friday to Sunday inclusive.
The following statement is not correct:
A) Thursday is a valid input boundary value. This statement is not correct, as Thursday is not a
boundary value for the input weekend. The boundary values for the input weekend are Friday and
Sunday, as they are at the edge of the equivalence partition that represents weekend days. The
following statements are correct:
B) A minimum of 6 valid test cases are derived from boundary value analysis based on input age. This
statement is correct, as we can derive six valid test cases based on input age by using the minimum
and maximum values for each equivalence partition defined by the requirement. The equivalence
partitions for input age are: under 7 (0 to 6), 7 to 13 inclusive (7 to 13), and greater than 65 (66 and
above). The minimum and maximum values for each partition are: 0 and 6, 7 and 13, and 66 and any
value above it.
C) $3.01 is a valid output boundary value. This statement is correct, as $3.01 is a boundary value for
the output additional fee. The additional fee can have four possible values depending on the input
age: $0 (for visitors aged under 7), $2.40 (for visitors aged 7 to 13 inclusive with a 20% discount),
$1.50 (for visitors aged greater than 65 with a 50% discount), and $3 (for visitors aged between 14
and 65). The boundary values for the output additional fee are $0 and $3, as they are at the edge of
an equivalence partition or at the smallest incremental distance on either side of an edge. Therefore,
$3.01 is a valid output boundary value, as it is at the smallest incremental distance above $3.
D) 7 and 13 are boundary values for the equivalence partition including age 10. This statement is
correct, as 7 and 13 are boundary values for the equivalence partition that represents visitors aged 7
to 13 inclusive. This partition includes age 10, which is an internal value within the partition. Verified
Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer], Chapter 4, page
37-38.

Question: 36
Out of the following. what is not needed to specify in defect report?

A. Test environment details

B. How to reproduce the defect
C. How to fix the defect
D. Seventy and priority

Answer: C
Explanation:

A defect report is a document that records the details of a defect found during testing. A defect
report typically contains the following items:
Identifier: A unique identifier for the defect report
Summary: A concise summary of the defect
Description: A detailed description of the defect, including the steps to reproduce it, the expected
and actual results, and any relevant screenshots or logs
Severity: The degree of impact that the defect has on the system
Priority: The level of urgency for resolving the defect
Status: The current state of the defect, such as new, open, resolved, closed, etc.

[Link]
Questions PDF 25/89

Resolution: The action taken to resolve the defect, such as fix, workaround, reject, etc. Out of these
items, the one that is not needed to specify in a defect report is how to fix the defect. How to fix the
defect is a technical solution that is usually determined by the developer who is assigned to resolve
the defect. How to fix the defect is not part of the defect report, but rather part of the code change
or patch that is delivered to fix the defect. The other items are needed to specify in a defect report,
as they provide essential information for identifying, tracking and resolving defects. Verified
Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer], Chapter 3, page
32-33.

Question: 37

You need to test the login page of a web site. The page contains fields for user name and password.
Which test design techniques are most appropriate for this case?

A. Decision table testing, state transition testing.

B. Equivalence partitioning, Boundary value analysis.
C. Exploratory testing, statement coverage.
D. Decision coverage, fault attack.

Answer: B
Explanation:

Equivalence partitioning and boundary value analysis are test design techniques that are most
appropriate for testing the login page of a web site. The page contains fields for user name and
password, which are input values that can be divided into partitions of equivalent data. Equivalence
partitioning is a technique that divides the input data and output results of a software component
into partitions of equivalent data. Each partition should contain data that is treated in the same way
by the component. Equivalence partitioning can be used to reduce the number of test cases by
selecting one representative value from each partition. Boundary value analysis is a technique that
tests boundary values between partitions of equivalent data. Boundary values are values at the edge
of an equivalence partition or at the smallest incremental distance on either side of an edge.
Boundary value analysis can be used to detect defects caused by incorrect handling of boundary
conditions. For example, for testing the user name field, we can identify two equivalence partitions:
valid user name (existing and correct) and invalid user name (non-existing or incorrect). The
boundary values for these partitions are the minimum and maximum length of user name allowed by
the system.
Decision table testing and state transition testing are not suitable for testing the login page of a web
site, as they are more applicable for testing components that have multiple inputs and outputs that
depend on logical combinations of conditions or events. Decision table testing is a technique that
shows combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions
(effects). State transition testing is a technique that models how a system transitions from one state
to another depending on events or conditions.
Exploratory testing and statement coverage are not suitable for testing the login page of a web site,
as they are more applicable for testing components that require learning, creativity and intuition or
structural analysis. Exploratory testing is an approach to testing that emphasizes learning, test design
and test execution at the same time. Exploratory testing relies on the tester’s skills, creativity and
intuition to explore the software under test and discover defects. Statement coverage is a type of
structural testing that measures how many statements in a program have been executed by a test

[Link]
Questions PDF 26/89

suite. Statement coverage can be used to assess the adequacy or completeness of a test suite.
Decision coverage and fault attack are not suitable for testing the login page of a web site, as they
are more applicable for testing components that have complex logic or potential errors. Decision
coverage is a type of structural testing that measures how many decision outcomes in a program
have been executed by a test suite. Decision coverage can be used to assess the adequacy or
completeness of a test suite. Fault attack is a type of functional testing that deliberately introduces
faults into a system in order to provoke failures or errors. Verified Reference: [A Study Guide to the
ISTQB® Foundation Level 2018 Syllabus - Springer], Chapter 4, page 34-46; Chapter 5, page 47-48.

Question: 38

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

A. Use case based testing

B. Decision table
C. Boundary value analysis
D. Equivalence class partitioning

Answer: B
Explanation:

A decision table is a technique that should be used to cover all possible combinations of input
conditions for withdrawing money from an Automated Teller Machine (ATM). A decision table shows
combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects).
A decision table consists of four quadrants: conditions (inputs), actions (outputs), condition entries
(values) and action entries (results). A decision table can be used to test components that have
multiple inputs and outputs that depend on logical combinations of conditions. For example, for
testing the ATM, we can identify three input conditions: the bank card is valid, the PIN code is
correct, and money is available in the user’s account. We can also identify four output actions: the
card is rejected, the ATM asks for another PIN code, the ATM asks for another amount, and the ATM
dispenses the money. A decision table can show all possible combinations of these conditions and
actions in a systematic way.
Use case based testing is not a technique that can cover all possible combinations of input conditions
for withdrawing money from an ATM. Use case based testing is a technique that verifies that a
software product or system meets its specified requirements or user stories by executing realistic
scenarios or workflows. Use case based testing can be used to test components that have complex or

[Link]
Questions PDF 27/89

dynamic interactions with users or other systems. For example, for testing the ATM, we can identify
several use cases, such as withdraw money, check balance, transfer money, etc. Each use case can
have one or more scenarios that describe the steps and outcomes of the interaction. However, use
case based testing may not cover all possible combinations of input conditions, as some scenarios
may be omitted or overlooked.
Boundary value analysis is not a technique that can cover all possible combinations of input
conditions for withdrawing money from an ATM. Boundary value analysis is a technique that tests
boundary values between partitions of equivalent data. Boundary values are values at the edge of an
equivalence partition or at the smallest incremental distance on either side of an edge. Boundary
value analysis can be used to test components that have input values that can be divided into
partitions of equivalent data. For example, for testing the ATM, we can identify boundary values for
the input amount, such as the minimum and maximum amount allowed by the system or the user’s
account. However, boundary value analysis may not cover all possible combinations of input
conditions, as some conditions may not have boundary values or may not be related to input values.
Equivalence class partitioning is not a technique that can cover all possible combinations of input
conditions for withdrawing money from an ATM. Equivalence class partitioning is a technique that
divides the input data and output results of a software component into partitions of equivalent data.
Each partition should contain data that is treated in the same way by the component. Equivalence
class partitioning can be used to test components that have input values that can be divided into
partitions of equivalent data. For example, for testing the ATM, we can identify equivalence
partitions for the input amount, such as valid amount (within the range allowed by the system and
the user’s account) and invalid amount (outside the range allowed by the system or the user’s
account). However, equivalence class partitioning may not cover all possible combinations of input
conditions, as some conditions may not be related to input values or may have more than two
partitions. Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus -
Springer], Chapter 4, page 34-46.

Question: 39
Which of the following statements about reviews are TRUE?
I, In walkthroughs the review meeting is typically led by the author.
II, Inspection is characterized by an open-ended review meeting
III, Preparation before the review meeting is part of informal reviews
IV, Management rarely participates in technical review meetings

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

Answer: C
Explanation:

The following statements about reviews are true:

I) In walkthroughs the review meeting is typically led by the author. A walkthrough is a type of review
that has a predefined objective and agenda but no formal process or roles. A walkthrough is typically
led by the author of the work product under review, who guides the participants through a scenario
and solicits feedback.

[Link]
Questions PDF 28/89

IV) Management rarely participates in technical review meetings. A technical review is a type of
review that has a predefined objective and agenda but no formal process or roles. A technical review
is typically performed by peers with technical expertise in order to evaluate technical aspects of a
work product. Management rarely participates in technical review meetings, as they may not have
sufficient technical knowledge or skills to contribute effectively. The following statements about
reviews are false:
II) Inspection is characterized by an open-ended review meeting. An inspection is a type of review
that follows a defined process with formal entry and exit criteria and roles and responsibilities for
participants. An inspection is characterized by a structured review meeting with a fixed duration and
agenda.
III) Preparation before the review meeting is part of informal reviews. Preparation before the review
meeting is part of formal reviews, such as inspections or technical reviews. Preparation involves
checking

Question: 40

The following part of a business process flow is specified; REPEAT (book a bill) UNTIL (User presses
Cancel). How many test cases are necessary in order to achieve 100% branch coverage of the process
flow?

A. 4
B. 1
C. 2
D. Infinite

Answer: C
Explanation:

To achieve 100% branch coverage of the process flow, we need to test both the true and false
outcomes of the condition (User presses Cancel). Branch coverage is a type of structural testing that
measures how many decision outcomes in a program have been executed by a test suite. Branch
coverage can be used to assess the adequacy or completeness of a test suite.
To test the true outcome of the condition, we need a test case that simulates the user pressing
Cancel after booking a bill. This test case will exit the loop and end the process flow.
To test the false outcome of the condition, we need a test case that simulates the user not pressing
Cancel after booking a bill. This test case will repeat the loop and book another bill.
Therefore, we need at least two test cases to achieve 100% branch coverage of the process flow. One
test case for each possible outcome of the condition.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer], Chapter
4, page 40-41.

Question: 41

Why it is essential that defects found in a review be reported objectively?

A. In order to facilitate easy entry of detected defects in a OTS (Defect Tracking System)

[Link]
Questions PDF 29/89

B. In order to allow the author of reviewed work product(S) to take the feedback positively as an
effort at improving the product (S) and not as a personal assault
C. In order to allow the review moderator to easily understand them, and assign them to the right
developer for fixing
D. In order to allow augmentation of existing checklists used for reviewing the work product (S)

Answer: B
Explanation:

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

Question: 42

The testers in company A were part of the development team. Due to an organizational change they
moved to be part of the support team.
What are the advantages and the disadvantages of this change?

A. Advantage: More independence in deciding what and how to test,

Disadvantage: Isolation from me development team knowledge
B. Advantage: being closer to customer perspective,
Disadvantage less independence in perspectives
C. Advantage: pulled to support tasks and having less time for testing,
Disadvantage less chances to move a tester to development
D. Advantage: increased chances to move a tester to development;
Disadvantage: pulled to support tasks and having less time for testing

Answer: B
Explanation:

Being part of the support team means that the testers are closer to the customer perspective, which
is an advantage for testing, as they can better understand the user needs and expectations, and
identify more realistic scenarios and risks. However, being part of the support team also means that
they have less independence in deciding what and how to test, as they may be influenced by the
customer’s preferences or requests, which could compromise the objectivity and effectiveness of
testing. Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer,
page 6.

Question: 43

The following sentences refer to the 'Standard for Software Test Documentation' specification (IEEE
829).
Which sentence is correct?

[Link]
Questions PDF 30/89

A. Any deviation from this standard should be approved by management, marketing & development
B. Most test documentation regimes follow this spec to some degree, with changes done to fit a
specific situation or organization
C. The key to high quality test documentation regimes is strict adherence to this standard
D. This test plan outline is relevant for military projects. For consumer market projects there is a
different specification with fewer items.

Answer: B
Explanation:

The IEEE 829 standard is a widely used specification for test documentation, but it is not mandatory
or universal. Most test documentation regimes follow this spec to some degree, with changes done
to fit a specific situation or organization. The standard does not require any approval from
management, marketing or development for any deviation, nor does it depend on the type of project
(military or consumer market). The standard also does not guarantee high quality test
documentation regimes, as it only provides a general outline and format, not the actual content or
quality criteria. Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus -
Springer, page 16.

Question: 44

4 equivalence classes are given for integer values:

0 < x <100
100<= x <= 200
200 < x < 500
x >= 500
Which of the following options represent correct set of data for valid equivalence class partitions?

A. 50; 100; 200. 1000

B. 0. 1.99, 100.200,201.499, 500;
C. 0.50; 100; [Link];
D. 50; 100; 250; 1000

Answer: C
Explanation:

The correct set of data for valid equivalence class partitions should include one value from each
equivalence class, and no value from outside the range. Option C satisfies this condition, as it has one
value from each of the four equivalence classes (50, 100, 250, 500). Option A has two values from the
same equivalence class (100 and 200), option B has values outside the range (0 and 0.99), and option
D has two values from the same equivalence class (1000 and 500). Verified Reference: A Study Guide
to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 35.

Question: 45

Which of the following are valid testing principles?

[Link]
Questions PDF 31/89

I) Exhaustive testing is in general impossible.

II) Exhaustive testing should be executed for code intended to be reused.
III) Testing may guarantee that a program is correct.
IV) Testing cannot guarantee that a program is correct.
V) Defects cluster together in certain areas of the product.

A. I, IV, V
B. II, Iv
C. I, V
D. I, Ill

Answer: A
Explanation:

Statements I, IV and V are valid testing principles according to the ISTQB syllabus. Statement I states
that exhaustive testing is in general impossible, because it would require testing all possible inputs,
outputs and combinations of states, which is usually impractical or impossible. Statement IV states
that testing cannot guarantee that a program is correct, because testing can only show the presence
of defects, not their absence. Statement V states that defects cluster together in certain areas of the
product, which means that some modules or functions are more likely to contain defects than others.
Statements II and III are invalid testing principles. Statement II states that exhaustive testing should
be executed for code intended to be reused, which contradicts statement I, Statement III states that
testing may guarantee that a program is correct, which contradicts statement IV, Verified
Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, pages 4-5.

Question: 46

Which of the following statements contradicts the general principles of testing?

A. Most defects are found in a small subset of a system's modules.

B. If new defects are to be found we should run the same test set more often.
C. Testing is better if it starts at the beginning of a project.
D. How testing is done, is based on the situation in a particular project.

Answer: B
Explanation:

Statement B contradicts the general principles of testing, because running the same test set more
often will not increase the chances of finding new defects, unless there are some changes in the
system or environment that affect the test results. Running different test sets with different inputs,
outputs or conditions would be more effective in finding new defects. Statements A, C and D are
consistent with the general principles of testing. Statement A states that most defects are found in a
small subset of a system’s modules, which is true according to the defect clustering principle.
Statement C states that testing is better if it starts at the beginning of a project, which is true
according to the early testing principle. Statement D states that how testing is done, is based on the
situation in a particular project, which is true according to the context-dependent testing principle.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, pages 4-

[Link]
Questions PDF 32/89

6.

Question: 47
Which of the following is true about Oracles?

A. Sometimes old version of a product can be used as an Oracle

B. Oracles help in reproducing the irreproducible bugs
C. Oracles are derived from the design
D. Oracles can be generated automatically using data generators

Answer: A
Explanation:

An oracle is a mechanism or source that can provide the expected result for a given test input or
situation. Sometimes old version of a product can be used as an oracle, if it is assumed that the old
version behaves correctly for the test cases that are executed on the new version. This is also known
as back-to-back testing. Oracles do not help in reproducing the irreproducible bugs, as they only
provide the expected results, not the actual results. Oracles are not derived from the design, but
from the requirements or specifications. Oracles cannot be generated automatically using data
generators, as data generators only provide test inputs, not test outputs. Verified Reference: A Study
Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 9.

Question: 48

Which type of software development product can undergo static testing?

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

Answer: A
Explanation:

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

Question: 49

[Link]
Questions PDF 33/89

The following incident report that was generated during test of a web application.
What would you suggest as the most important report improvement?
Defect detected date: 15 8.2010
Defect detected by: Joe Smith
Test level System test
Test case: Area 5/TC 98
Build version: 2011-16.2
Defect description After having filled out all required fields in screen 1, t click ENTER to continue to
screen 2 Nothing happens, no system response at all.

A. Add information about which web browser was used

B. Add information about which developer should fix the bug
C. Add the time stamp when the incident happened
D. Add an impact analysis

Answer: A
Explanation:

The most important report improvement for the given incident report would be to add information
about which web browser was used when the defect was detected. This information is relevant for
reproducing and debugging the defect, as different web browsers may have different behaviors or
compatibility issues with the web application. The other options are less important or irrelevant for
the incident report. The developer who should fix the bug can be assigned by the project manager or
the defect tracking system, not by the tester who reports the defect. The time stamp when the
incident happened is not very useful, as it does not indicate the cause or the frequency of the defect.
The impact analysis is not part of the incident report, but rather of the risk assessment or
prioritization process. Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018
Syllabus - Springer, page 140.

Question: 50

Which of the following statements is LEAST likely to be describing component testing?

A. It identifies defects in modules and classes.

B. Simulators and stubs may be required.
C. It mainly tests interfaces and interaction between components.
D. It may be applied using a test-first approach.

Answer: C
Explanation:

Component testing (also known as unit testing or module testing) is a level of testing that focuses on
verifying the functionality and quality of individual software components (such as modules, classes,
functions, methods, etc.). Component testing mainly tests interfaces and interaction between
components, as well as internal logic and data structures of the components. Component testing
may be applied using a test-first approach (such as test-driven development or behavior-driven

[Link]
Questions PDF 34/89

development), where tests are written before the code is implemented. Component testing does not
identify defects in modules and classes, as this is a result of component testing, not an objective.
Simulators and stubs may be required for component testing, as they can simulate or replace missing
or incomplete components or external systems that are needed for testing. Verified Reference: A
Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 19.

Question: 51

Which of the following is NOT a common objective of testing?

A. Finding defects in the software

B. Preventing defects
C. Debugging the software to find the reason for defects
D. Providing information on the status of the system

Answer: C
Explanation:

Debugging the software to find the reason for defects is not a common objective of testing, but
rather a task of development or maintenance. Debugging is a process of locating and fixing errors in
the software code, while testing is a process of finding and reporting defects in the software behavior
or quality. Testing does not aim to fix defects, but rather to provide information on their existence
and impact. The other options are common objectives of testing. Finding defects in the software is
one of the main objectives of testing, as it helps to improve the quality and reliability of the
software. Preventing defects is another objective of testing, as it helps to avoid rework and reduce
costs and risks. Providing information on the status of the system is another objective of testing, as it
helps to support decision making and risk management. Verified Reference: A Study Guide to the
ISTQB® Foundation Level 2018 Syllabus - Springer, page 3.

Question: 52

A Static analysis tool analyzes a given program's CONTROL FLOW among other things. Which of the
following options represents the most likely outcome of the control flow analysis:

A. Identification of unreachable code

B. Report on adherence to the coding standards
C. Number of comment lines
D. Number of source code lines

Answer: A
Explanation:

A static analysis tool is a tool that analyzes a given program’s source code or executable code without
executing it. A static analysis tool can perform various types of analysis on a program’s code, such as
syntax checking, data flow analysis, control flow analysis, complexity measurement, coding standards
compliance checking, etc. Control flow analysis is a type of analysis that examines how a program’s
statements are executed in different paths or branches. One of the most likely outcomes of control

[Link]
Questions PDF 35/89

flow analysis is identification of unreachable code, which is code that can never be executed due to
logical errors or design flaws. Unreachable code can reduce readability and maintainability of the
code, as well as increase complexity and size. The other options are not outcomes of control flow
analysis, but rather outcomes of other types of analysis. Report on adherence to coding standards is
an outcome of coding standards compliance checking. Number of comment lines and number of
source code lines are outcomes of complexity measurement. Verified Reference: A Study Guide to
the ISTQB® Foundation Level 2018 Syllabus - Springer, page 8.

Question: 53

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

A. configuration management tool

B. unit test framework tool
C. test design tool
D. monitoring tool

Answer: B
Explanation:

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

Question: 54

A system has valid input numbers ranging between 1000 and 99999 (both inclusive). Which of the
following inputs are a result of designing tests for all valid equivalence classes and their boundaries?

A. 999.1000.23232.99999.100000
B. 999.1000.50000.100000.100001
C. 999.100000
D. 1000,50000,99999

Answer: B
Explanation:

A correct list of boundary values for the P input should include the minimum and maximum values of

[Link]
Questions PDF 36/89

the valid range (15 and 350), as well as the values just below and above the boundaries (14 and 351).
Boundary value analysis is a test design technique that involves testing the values at or near the
boundaries of an input domain or output range, as these values are more likely to cause errors than
values in the middle. Option B satisfies this condition, as it has all four boundary values (14, 15, 350,
351). Option A has two values from the same equivalence class (1000 and 99999), option C has two
values outside the range (999 and 100000), and option D has no boundary values at all. Verified
Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 34.

Question: 55

Which of the following is the most important task of a typical test leader?

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

Answer: D
Explanation:

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.

Question: 56

Which of the following is NOT an experience-based technique?

A. Boundary value analysis.

B. Error guessing
C. Exploratory testing
D. Fault attack

Answer: A
Explanation:

Boundary value analysis is not an experience-based technique, but rather a specification-based

technique (also known as black-box technique). Experience-based techniques are techniques that
rely on the tester’s knowledge and intuition to derive and select test cases based on their experience

[Link]
Questions PDF 37/89

with similar systems, technologies, domains, risks, etc. Some examples of experience-based
techniques are error guessing, exploratory testing, fault attack, checklist-based testing, etc.
Specification-based techniques are techniques that rely on the tester’s analysis and interpretation of
the requirements or specifications of the system under test to derive and select test cases based on
some criteria or rules. Some examples of specification-based techniques are equivalence
partitioning, boundary value analysis, decision table testing, state transition testing, etc. Verified
Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 31.

Question: 57

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

Answer: A
Explanation:

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.

Question: 58

Which of the following is a correct reason to apply test automation?

A. When a new test automation tool is launched

B. When there are a lot of repetitive testing tasks
C. When it is easy to automate
D. When it is cheap to buy test automation tools

[Link]
Questions PDF 38/89

Answer: B
Explanation:

A correct reason to apply test automation is when there are a lot of repetitive testing tasks. Test
automation is the use of software tools or scripts to perform or support testing activities, such as test
case execution, test result comparison, test data generation, etc. Test automation can be beneficial
when there are a lot of repetitive testing tasks that need to be performed frequently or consistently,
such as regression testing, performance testing, load testing, etc. Test automation can help to save
time and effort, increase reliability and accuracy, and improve coverage and efficiency of testing. The
other options are not correct reasons to apply test automation. When a new test automation tool is
launched is not a reason to apply test automation, but rather a factor for choosing a test automation
tool. When it is easy to automate is not a reason to apply test automation, but rather a factor for
evaluating the feasibility of test automation. When it is cheap to buy test automation tools is not a
reason to apply test automation, but rather a factor for estimating the cost and benefit of test
automation. Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus -
Springer, page 10.

Question: 59

Consider the following testing levels:

1) Component Testing
2) Integration Testing
3) System Testing
4) Acceptance Testing
Which of the following statements is true?

A. Integration and system testing are applicable when V-model is used.

Component and acceptance testing are applicable when iterative development models are used.
B. All the testing levels are applicable to V-model for software development.
Only acceptance testing is applicable for iterative models.
C. Acceptance testing is applicable for all software development models.
Component and system testing are applicable only for the V-model.
D. All testing levels are applicable, independent of which software development life-cycle process (V-
model. iterative, incremental) is used.

Answer: D
Explanation:

All testing levels are applicable, independent of which software development life-cycle process (V-
model, iterative, incremental) is used. Testing levels are defined based on the scope and objectives
of testing, not on the software development model. Component testing, integration testing, system
testing and acceptance testing are common testing levels that can be applied to any software
development model, as long as they are planned and executed properly. The V-model is a software
development model that emphasizes the relationship between each development phase and its
corresponding testing phase. Iterative and incremental models are software development models
that divide the development process into smaller cycles or iterations, where each iteration produces

[Link]
Questions PDF 39/89

a working version of the software that can be tested and evaluated. Verified Reference: A Study
Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 18.

Question: 60

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. V-Model
B. Agile
C. Waterfall
D. Prototyping

Answer: A
Explanation:

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.

Question: 61

A software calculates the annual car tax using three inputs:

- E; the emission level of the vehicle
- P: the power of the vehicle
-T the type of the vehicle
The input value for P can be integer positive values between 15 and 350.
Which of the following answers contains a correct list of a boundary values for the P input?

A. 14,351
B. 14,15,350,351
C. 15,350
D. 5.175.500

Answer: B
Explanation:

[Link]
Questions PDF 40/89

A correct list of boundary values for the P input should include the minimum and maximum values of
the valid range (15 and 350), as well as the values just below and above the boundaries (14 and 351).
Boundary value analysis is a test design technique that involves testing the values at or near the
boundaries of an input domain or output range, as these values are more likely to cause errors than
values in the middle. Option B satisfies this condition, as it has all four boundary values (14, 15, 350,
351). Option A has only two boundary values (14 and 351), option C has only two boundary values
(15 and 350), and option D has no boundary values at all. Verified Reference: A Study Guide to the
ISTQB® Foundation Level 2018 Syllabus - Springer, page 34.

Question: 62

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 lest engineer should not re-run the tests, as they have already been run, and results recorded.
B. The test engineer should not re-run the tests, they should be part of the developer tests.
C. The test engineer should re-run the tests, in order to ensure that new defects have not been
introduced by the fix.
D. The test engineer should re-run the tests, because the defect shows that the test cases need to be
updated.

Answer: C
Explanation:

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 Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 41.

Question: 63

Which of the following is NOT a product risk?

A. Poor software usability

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

Answer: C
Explanation:

[Link]
Questions PDF 41/89

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

Question: 64

Why should you choose a test technique?

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

Answer: A
Explanation:

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

Question: 65

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

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

Answer: A
Explanation:

Test exit criteria are the conditions or requirements that must be met before testing can be
concluded. Test exit criteria are usually defined in the test plan and agreed by the stakeholders. Test

[Link]
Questions PDF 42/89

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

Question: 66

How can testing contribute to higher quality?

A. Testing help to measure the quality of software.

B. Testing ensures that remaining defects are documented.
C. Testing removes errors in the software.
D. Testing eliminates the risk with software.

Answer: A
Explanation:

Testing can contribute to higher quality by helping to measure the quality of software. Quality is
defined as the degree to which a component or system satisfies specified requirements and
customer or user needs and expectations. Testing is a process of evaluating a component or system
by applying inputs and observing outputs, and comparing them with expected results. Testing can
help to measure the quality of software by providing information on its functionality, performance,
usability, security, reliability, etc. Testing can also help to identify and report defects in software,
which can lead to improvement actions and quality assurance activities. The other options are not
accurate descriptions of how testing can contribute to higher quality. Testing does not ensure that
remaining defects are documented, but rather that detected defects are reported. Testing does not
remove errors in software, but rather finds defects in software behavior or quality. Testing does not
eliminate the risk with software, but rather assesses and manages the risk with software. Verified
Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 3.

Question: 67

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.

[Link]
Questions PDF 43/89

D. The "dead" code has not been covered.

Answer: A
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 Reference: A Study Guide to the ISTQB® Foundation Level
2018 Syllabus - Springer, page 36.

Question: 68

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

[Link]
Questions PDF 44/89

Answer: D
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 Reference: A Study Guide to the ISTQB® Foundation Level 2018
Syllabus - Springer, page 141.

Question: 69

In maintenance testing, what is the relationship between impact analysis and regression testing?

A. Impact analysis requires a regression testing for only the tests that have detected faults in
previous SW release
B. There is no relationship between impact analysis and regression testing.
C. Impact analysis requires a regression testing for all program elements which were newly
integrated (new functionalities).
D. The impact analysis is used to evaluate the amount of regression testing to be performed.

Answer: D
Explanation:

In maintenance testing, the relationship between impact analysis and regression testing is that the
impact analysis is used to evaluate the amount of regression testing to be performed. Maintenance
testing is a type of testing that is performed on an existing software product after it has been
delivered or deployed, in order to ensure that it still meets its requirements and functions correctly
after a change or a modification. Maintenance testing can be triggered by various reasons, such as
corrective maintenance (fixing defects), adaptive maintenance (adapting to new environments),
perfective maintenance (improving performance), preventive maintenance (avoiding future

[Link]
Questions PDF 45/89

problems), etc. Impact analysis is a technique that is used to assess the extent and nature of changes
introduced by maintenance activities on the software product or project. Impact analysis helps to
identify which parts of the software product are affected by the changes, which parts need to be
modified or updated accordingly, which parts need to be retested or verified for correctness or
compatibility, etc. Regression testing is a type of testing that verifies that previously tested software
still performs correctly after a change or a modification. Regression testing helps to detect any side
effects or unintended consequences of maintenance activities on the software product’s
functionality or quality. Regression testing can be performed at various levels and scopes depending
on the impact analysis results. Therefore, in maintenance testing, impact analysis is used to evaluate
the amount of regression testing to be performed. Verified Reference: A Study Guide to the ISTQB®
Foundation Level 2018 Syllabus - Springer, page 20.

Question: 70

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

A. (-[Link].18,19)
B. (-1.0,11.12.13,14,18.19)
C. ([Link].19)
D. ([Link])

Answer: A
Explanation:

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

Question: 71

Which of the following is an example of black-box dynamic testing?

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

[Link]
Questions PDF 46/89

Answer: A
Explanation:

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

Question: 72

What is 'Component Testing'?

A. Integration Testing
B. Functional testing
C. Experience-based testing
D. A test level

Answer: D
Explanation:

Component testing is a test level. A test level is a group of test activities that are organized and
managed together based on some common characteristics or objectives. A test level can be defined
based on various factors, such as the scope and target of testing, the phase and model of
development, the stakeholders and roles involved in testing, etc. Component testing (also known as
unit testing or module testing) is a test level that focuses on verifying the functionality and quality of
individual software components (such as modules, classes, functions, methods, etc.). Component
testing can be performed by developers or testers using various techniques and tools depending on
the type and complexity of the components. The other options are not test levels. Integration testing

[Link]
Questions PDF 47/89

is another test level that focuses on verifying the functionality and quality of groups of software
components that interact with each other or with external systems. Functional testing is a type of
black-box dynamic testing that verifies that the system under test performs its intended functions
according to its requirements or specifications. Experience-based testing is a category of test design
techniques that rely on the tester’s knowledge and intuition to derive and select test cases based on
their experience with similar systems, technologies, domains, risks, etc. Verified Reference: A Study
Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 19.

Question: 73

Which of the following is NOT an objective of testing?

A. Finding defects
B. Providing information for decision-making
C. Gaining confidence about the level of quality of the software
D. Analyzing and removing the cause of failures

Answer: D
Explanation:

Analyzing and removing the cause of failures is not an objective of testing, but rather a task of
development or maintenance. A failure is an event or behavior that deviates from the expected or
specified result of a system under test. A failure is caused by an error (also known as a mistake or a
fault) in the software code, design, or specification. Analyzing and removing the cause of failures is a
process of locating and fixing errors in the software code, design, or specification, which is also
known as debugging or defect resolution. Analyzing and removing the cause of failures does not aim
to find or report defects, but rather to correct or prevent them. The other options are objectives of
testing. Finding defects is one of the main objectives of testing, as it helps to improve the quality and
reliability of the software product. Providing information for decision-making is another objective of
testing, as it helps to support decision making and risk management. Gaining confidence about the
level of quality of the software is another objective of testing, as it helps to assure that the software
product meets its requirements and customer or user needs and expectations. Verified Reference: A
Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 3.

Question: 74

An Incident Management tool implements the following defect states; Open, Assigned, Solved,
Closed Consider the following defect report:
Id T000561
Test Object "Warehouse Management' application
Tester name; John Bishop
Date: 10th. April 2010
Test Case MRT558I
Status OPEN
Severity Serious
Priority
Problem- After inputting the Total Quantity item = 450 in the SV034 screen, the system shows an

[Link]
Questions PDF 48/89

unexpected Error message=47

Correction:
Developer name:
Closing date:
Which of the following is a valid criticism of this report?

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

Answer: B
Explanation:

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

Question: 75

Which of the following is a key characteristic of informal reviews?

A. Kick-off meeting
B. Low cost
C. Individual preparation
D. Metrics analysis

Answer: B
Explanation:

[Link]
Questions PDF 49/89

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.

Question: 76

Which of the following BEST matches the attributes with a level of testing?
I, Stubs and drivers are often used
II The lest environment should correspond to the production environment
III Finding defects is not the main focus
IV Testing can be based on use cases
V Testing is normally performed by testers
VI Testing for functional and non-functional characteristics

A. Component - VI
Integration - IV
System -1
Acceptance - 111
B. Component - IV
Integration -1
System - VI
Acceptance - V
C. Component-I
Integration - V
System - II
Acceptance - IV
D. Component - V
Integration - II
System - IV
Acceptance - VI

[Link]
Questions PDF 50/89

Answer: D
Explanation:

The relationship between impact analysis and regression testing in maintenance testing is that
impact analysis is used to evaluate the amount of regression testing to be performed. Maintenance
testing is a type of testing that is performed on an existing software product after it has been
delivered or deployed, in order to ensure that it still meets its requirements and functions correctly
after a change or a modification. Maintenance testing can be triggered by various reasons, such as
corrective maintenance (fixing defects), adaptive maintenance (adapting to new environments),
perfective maintenance (improving performance), preventive maintenance (avoiding future
problems), etc. Impact analysis is a technique that is used to assess the extent and nature of changes
introduced by maintenance activities on the software product or project. Impact analysis helps to
identify which parts of the software product are affected by the changes, which parts need to be
modified or updated accordingly, which parts need to be retested or verified for correctness or
compatibility, etc. Regression testing is a type of testing that verifies that previously tested software
still performs correctly after a change or a modification. Regression testing helps to detect any side
effects or unintended consequences of maintenance activities on the software product’s
functionality or quality. Regression testing can be performed at various levels and scopes depending
on the impact analysis results. Therefore, in maintenance testing, impact analysis is used to evaluate
the amount of regression testing to be performed. Verified Reference: A Study Guide to the ISTQB®
Foundation Level 2018 Syllabus - Springer, page 20.

Question: 77

Which of the following statements is not correct?

A. Looking for defects in a system may require Ignoring system details

B. Identifying defects may be perceived as criticism against product
C. Looking for defects in system requires professional pessimism and curiosity
D. Testing is often seen as a destructive activity instead of constructive activity

Answer: A
Explanation:

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

[Link]
Questions PDF 51/89

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.

Question: 78
Which of the following s the most correct statement about state testing techniques?

A. Static techniques can be used before all code is ready for execution
B. Static techniques find more detects then dynamic techniques.
C. Static techniques can be used by inexperienced users.
D. Static techniques are always cheaper than dynamic techniques.

Answer: A
Explanation:

State testing techniques are a type of dynamic testing techniques that are based on the behavior of
the system under test for different input conditions and events. Dynamic testing techniques require
the system to be executed with test cases, whereas static testing techniques do not. Static testing
techniques can be applied before the code is ready for execution, such as reviews, inspections,
walkthroughs, and static analysis. Static testing techniques can help find defects early in the
development process, improve the quality of the code, and reduce the cost and effort of dynamic
testing. Reference = ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Chapter 4, Section
4.2.1, Page 281; ISTQB Glossary of Testing Terms v4.0, Page 292

Question: 79

A test manager decided to skip static testing since he believes bugs can be found easily by doing
dynamic testing. Was this decision right or wrong?

A. The decision was wrong. Ensuring quality mandates that static testing is performed after
performing the dynamic testing.
B. The decision was right. Static testing is usually redundant if a product is planned to go through a
full-cycle of dynamic testing.
C. The decision was right. Most of the bugs are easier to identify during the dynamic testing.
D. The decision was wrong. Static testing can find defects early in the development process, reducing
the overall cost of testing and development

Answer: D
Explanation:

Static testing is a form of testing that does not involve executing the software or system under test. It
includes activities such as reviews, inspections, walkthroughs, and analysis of documents, code, and
models. Static testing can find defects early in the development process, before they become more
expensive and difficult to fix in later stages. Static testing can also improve the quality of the software

[Link]
Questions PDF 52/89

or system by preventing defects from being introduced in the first place. Static testing can
complement dynamic testing, which involves executing the software or system under test and
checking the results against expected outcomes. Dynamic testing can find defects that static testing
may miss, such as performance, usability, or integration issues. However, dynamic testing alone is
not sufficient to ensure quality, as it may not cover all possible scenarios, inputs, or paths. Therefore,
a test manager who decides to skip static testing is making a wrong decision, as he or she is ignoring
the benefits of static testing and relying solely on dynamic testing, which may not be effective or
efficient enough to find and prevent defects. Reference = ISTQB Certified Tester Foundation Level
Syllabus, Version 4.0, 2018, Section 2.1.1, page 14; ISTQB Glossary of Testing Terms, Version 4.0,
2018, page 36; ISTQB CTFL 4.0 - Sample Exam - Answers, Version 1.1, 2023, Question 3, page 9.

Question: 80
In which of the following test documents would you expect to find test exit criteria described9

A. Test design specification

B. Project plan
C. Requirements specification
D. Test plan

Answer: D
Explanation:

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

[Link]
Questions PDF 53/89

Question: 81

The following 4 equivalence classes are given:

Which of the following alternatives includes correct test values for x. based on equivalence
partitioning?

A. -100; 100:1000; 1001

B. -500; 0; 100; 1000
C. -99; 99:101; 1001
D. -1000; -100; 100; 1000

Answer: D
Explanation:

The question is about selecting the correct test values for x based on equivalence partitioning.
Equivalence partitioning is a software test design technique that divides the input data of a software
unit into partitions of equivalent data from which test cases can be derived. In this case, the given
equivalence classes are:
(x \leq -100)
(-100 < x < 100)
(100 \leq x < 1000)
(x \geq 1000)
Option D provides a value from each of these partitions:
For (x \leq -100), it gives -1000.
For (-100 < x < 100), it gives -100 and 100.
For (100 \leq x < 1000), it gives 500.
For (x \geq 1000), it gives 1500.
So, option D covers all four given equivalence classes with appropriate values.
Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 documents available
at ISTQB and ASTQB.
1: ISTQB Foundation Level Syllabus 2018, Version 4.0, p. 38
2: ISTQB Foundation Level Syllabus 2018, Version 4.0, p. 39
: ISTQB Foundation Level Syllabus 2018, Version 4.0, p. 40

Question: 82

Which of the following coverage criteria results in the highest coverage for state transition based test
cases?

A. Can't be determined
B. Covering all transitions at least once

[Link]
Questions PDF 54/89

C. Covering only start and end states

D. Covering all states at least once

Answer: B
Explanation:

Covering all transitions at least once is the highest coverage criterion for state transition based test
cases, because it ensures that every possible change of state is tested at least once. This means that
all the events that trigger the transitions, as well as the actions and outputs that result from the
transitions, are verified. Covering all transitions at least once also implies covering all states at least
once, but not vice versa. Therefore, option D is not the highest coverage criterion. Option C is the
lowest coverage criterion, because it only tests the initial and final states of the system or
component, without checking the intermediate states or transitions. Option A is incorrect, because
the coverage criteria for state transition based test cases can be determined and compared based on
the number of transitions and states covered. Reference = CTFL 4.0 Syllabus, Section 4.2.3, page 49-
50.

Question: 83
Which of the following lists factors That contribute to PROJECT risks?

A. skill and staff shortages; problems in defining the right requirements, contractual issues.
B. skill and staff shortages; software does not perform its intended functions; problems in defining
the right requirements.
C. problems in defining the right requirements; contractual issues; poor software quality
characteristics.
D. poor software quality characteristics; software does not perform its intended functions.

Answer: A
Explanation:

Project risks are the uncertainties or threats that may affect the project objectives, such as scope,
schedule, cost, and quality. According to the ISTQB Certified Tester Foundation Level (CTFL) v4.0
syllabus, some of the factors that contribute to project risks are:
Skill and staff shortages: This factor refers to the lack of adequate or qualified human resources to
perform the project tasks. This may result in delays, errors, rework, or low productivity.
Problems in defining the right requirements: This factor refers to the difficulties or ambiguities in
eliciting, analyzing, specifying, validating, or managing the requirements of the project. This may
result in misalignment, inconsistencies, gaps, or changes in the requirements, affecting the project
scope and quality.
Contractual issues: This factor refers to the challenges or disputes that may arise from the
contractual agreements between the project parties, such as clients, suppliers, vendors, or
subcontractors. This may result in legal, financial, or ethical risks, affecting the project delivery and
satisfaction.
The other options are not correct because they list factors that contribute to PRODUCT risks, not
project risks. Product risks are the uncertainties or threats that may affect the quality or functionality
of the software product or system. Some of the factors that contribute to product risks are:

[Link]
Questions PDF 55/89

Poor software quality characteristics: This factor refers to the lack of adherence or compliance to the
quality attributes or criteria of the software product or system, such as reliability, usability, security,
performance, or maintainability. This may result in defects, failures, or dissatisfaction of the users or
stakeholders.
Software does not perform its intended functions: This factor refers to the deviation or discrepancy
between the expected and actual behavior or output of the software product or system. This may
result in errors, faults, or malfunctions of the software product or system.
Reference = ISTQB Certified Tester Foundation Level (CTFL) v4.0 syllabus, Chapter 1: Fundamentals of
Testing, Section 1.5: Risks and Testing, Pages 14-16.

Question: 84

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->S5->S1
B. S0->S1->S2->S3->S5->S1->S2->S3
C. S0->S1->S2~>S3->S4
D. S0->S1 ->S2->S3->S5->S3->S4

Answer: D
Explanation:

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.

Question: 85

A Test Manager conducts risk assessment for a project. One of the identified risks is: The sub-
contractor may fail to meet his commitment". If this risk materializes. it will lead to delay in
completion of testing required for the current cycle.
Which of the following sentences correctly describes the risk?

A. It is a product risk since any risk associated with development timeline is a product risk.
B. It is no longer a risk for the Test Manager since an independent party (the sub-contractor) is now
managing it
C. It is a object risk since successful completion of the object depends on successful and timely
completion of the tests

[Link]
Questions PDF 56/89

D. It is a product risk since default on part of the sub-contractor may lead to delay in release of the
product

Answer: D
Explanation:

A product risk is a risk that affects the quality or timeliness of the software product being developed
or tested1. Product risks are related to the requirements, design, implementation, verification, and
maintenance of the software product2.
The risk of the sub-contractor failing to meet his commitment is a product risk, as it could cause a
delay in the completion of the testing required for the current cycle, which in turn could affect the
release date of the product. The release date is an important aspect of the product quality, as it
reflects the customer satisfaction and the market competitiveness of the product3.
The other options are not correct because:
A) It is not true that any risk associated with development timeline is a product risk. Some risks could
be project risks, which are risks that affect the management or control of the software project, such
as budget, resources, schedule, or communication1. For example, a risk of losing a key project
stakeholder is a project risk, not a product risk.
B) It is not true that the risk is no longer a risk for the Test Manager since an independent party is
managing it. The Test Manager is still responsible for ensuring that the testing activities are
completed according to the test plan and the quality objectives4. The Test Manager should monitor
and control the sub-contractor’s performance and communicate with him regularly to identify and
mitigate any potential issues or deviations5.
C) It is not clear what is meant by “object” in this option, but it could be interpreted as the software
system under test or the test object6. In any case, the risk is not an object risk, as it does not affect
the successful completion of the object, but rather the successful completion of the testing of the
object. An object risk could be a risk that affects the functionality, reliability, usability, efficiency,
maintainability, or portability of the software system under test2. For example, a risk of the software
system having a high complexity or a low testability is an object risk, not a product risk.
Reference =
1 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 97
2 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 98
3 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 99
4 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 100
5 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 101
6 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 102

Question: 86

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

[Link]
Questions PDF 57/89

Answer: D
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. Reference = 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: 87

Which of the following are the phases of the ISTQB fundamental test process?

A. Test planning and control, Test analysis and design, Test implementation and execution, Evaluating
ex t criteria and reporting. 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 and control, Test specification and design. Test implementation and execution,
Evaluating test coverage and reporting, Retesting and regression testing, Test closure activities
D. Test planning. Test specification and design. Test implementation and execution. Evaluating exit
criteria and reporting. Retesting and test closure activities

Answer: A
Explanation:

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

[Link]
Questions PDF 58/89

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.
Reference = 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.

Question: 88
Which of the following issues cannot be identified by static analysis tools?

A. Very low MTBF (Mean Time Between failure)

B. Potentially endless loops
C. Referencing a variable with an undefined value
D. Security vulnerabilities

Answer: A
Explanation:

Static analysis tools are software tools that examine the source code of a program without executing
it. They can detect various types of issues, such as syntax errors, coding standards violations, security
vulnerabilities, and potential bugs12. However, static analysis tools cannot identify issues that
depend on the runtime behavior or performance of the program, such as very low MTBF (Mean Time
Between failure)3. MTBF is a measure of the reliability of a system or component. It is calculated by
dividing the total operating time by the number of failures. MTBF reflects how often a system or
component fails during its expected lifetime. Static analysis tools cannot measure MTBF because
they do not run the program or observe its failures. MTBF can only be estimated by dynamic testing,
which involves executing the program under various conditions and collecting data on its failures4.
Therefore, very low MTBF is an issue that cannot be identified by static analysis tools. The other
options, such as potentially endless loops, referencing a variable with an undefined value, and
security vulnerabilities, are issues that can be identified by static analysis tools. Static analysis tools
can detect potentially endless loops by analyzing the control flow and data flow of the program and
checking for conditions that may never become false5. Static analysis tools can detect referencing a
variable with an undefined value by checking the scope and initialization of variables and reporting
any use of uninitialized variables6. Static analysis tools can detect security vulnerabilities by checking
for common patterns of insecure code, such as buffer overflows, SQL injections, cross-site scripting,
and weak encryption. Reference = What Is Static Analysis? Static Code Analysis Tools - Perforce
Software, How Static Code Analysis Works | Perforce, Static Code Analysis: Techniques, Top 5

[Link]
Questions PDF 59/89

Benefits & 3 Challenges, What is MTBF? Mean Time Between Failures Explained | Perforce, Static
analysis tools - Software Testing MCQs - CareerRide, ISTQB_Chapter3 | Quizizz, [Static Code Analysis
for Security Vulnerabilities | Perforce].

Question: 89

A company runs a pilot project for evaluation of a test automation tool. Which of the following is
NOT a valid object of this pilot project?

A. Get familiar with the functionality and options of the tool

B. Check haw the tool fits to the existing test processes
C. Train all testers on using the tool
D. Decide upon standards for tool implementation

Answer: C
Explanation:

A pilot project is a small-scale experiment or trial that is conducted to evaluate the feasibility,
effectiveness, and suitability of a test automation tool before implementing it on a larger scale1.
The objectives of a pilot project may vary depending on the context and scope of the test automation
initiative, but some common ones are2:
To get familiar with the functionality and options of the tool
To check how the tool fits to the existing test processes and environment
To assess the benefits and challenges of using the tool
To decide upon standards and guidelines for tool implementation and usage
To estimate the costs and resources required for tool deployment and maintenance
Therefore, option C is not a valid objective of a pilot project, as it is not necessary to train all testers
on using the tool at this stage. Training all testers on using the tool would be more appropriate after
the tool has been selected and approved for full-scale implementation, and after the standards and
guidelines have been established. Training all testers on using the tool during the pilot project would
be inefficient, costly, and premature, as the tool may not be suitable or effective for the intended
purpose, or may be replaced by another tool later.
Reference:
1: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 82
2: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 83
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 84
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 85

Question: 90
Which of the following applications will be the MOST suitable for testing by Use Cases

A. Accuracy and usability of a new Navigation system compared with previous system
B. A billing system used to calculate monthly charge based or large number of subscribers
parameters
C. The ability of an Anti virus package to detect and quarantine a new threat
D. Suitability and performance of a Multi media (audio video based) system to a new operating

[Link]
Questions PDF 60/89

system

Answer: A
Explanation:

A new navigation system compared with a previous system is the most suitable application for
testing by use cases, because it involves a high level of interaction between the user and the system,
and the expected behavior and outcomes of the system are based on the user’s needs and goals. Use
cases can help to specify the functional requirements of the new navigation system, such as the
ability to enter a destination, select a route, follow the directions, receive alerts, etc. Use cases can
also help to compare the accuracy and usability of the new system with the previous system, by
defining the success and failure scenarios, the preconditions and postconditions, and the alternative
flows of each use case. Use cases can also help to design and execute test cases that cover the main
and exceptional paths of each use case, and to verify the satisfaction of the user’s expectations.
The other options are not the most suitable applications for testing by use cases, because they do not
involve a high level of interaction between the user and the system, or the expected behavior and
outcomes of the system are not based on the user’s needs and goals. A billing system used to
calculate monthly charge based on a large number of subscriber parameters is more suitable for
testing by data-driven testing, which is a technique for testing the functionality and performance of a
system or component by using a large set of input and output data. The ability of an antivirus
package to detect and quarantine a new threat is more suitable for testing by exploratory testing,
which is a technique for testing the functionality and security of a system or component by using an
informal and flexible approach, based on the tester’s experience and intuition. The suitability and
performance of a multimedia (audio video based) system to a new operating system is more suitable
for testing by compatibility testing, which is a technique for testing the functionality and
performance of a system or component by using different hardware, software, or network
environments. Reference = CTFL 4.0 Syllabus, Section 3.1.1, page 28-29; Section 4.1.1, page 44-45;
Section 4.2.1, page 47-48.

Question: 91

A program is used to control a manufacturing line (turn machines on and off. start and stop conveyer
belts, add raw materials to the flow. etc.). Not all actions are possible at all times. For example, there
are certain manufacturing stages that cannot be stopped - unless there is an emergency. A tester
attempts to evaluate if all such cases (where a specific action is not allowed) are covered by the tests.
Which coverage metric will provide the needed information for this analysis?

A. Code coverage
B. Data flow coverage
C. Statement coverage
D. Branch Coverage

Answer: D
Explanation:

Branch coverage is a type of structural coverage metric that measures the percentage of branches or
decision outcomes that are executed by the test cases. A branch is a point in the code where the

[Link]
Questions PDF 61/89

control flow can take two or more alternative paths based on a condition. For example, an if-else
statement is a branch that can execute either the if-block or the else-block depending on the
evaluation of the condition. Branch coverage ensures that each branch is taken at least once by the
test cases, and thus reveals the behavior of the software under different scenarios. Branch coverage
is also known as decision coverage or all-edges coverage.
Branch coverage is suitable for testing the cases where a specific action is not allowed, because it can
verify that the test cases cover all the possible outcomes of the conditions that determine the action.
For example, if the program has a condition that checks if the manufacturing stage can be stopped,
then branch coverage can ensure that the test cases cover both the cases where the stage can be
stopped and where it cannot be stopped. This way, branch coverage can help identify any missing or
incorrect branches that may lead to undesired or unsafe actions.
The other options are not correct because they are not suitable for testing the cases where a specific
action is not allowed. Code coverage is a general term that encompasses various types of coverage
metrics, such as statement coverage, branch coverage, data flow coverage, etc. Code coverage does
not specify which type of coverage metric is used for the analysis. Data flow coverage is a type of
structural coverage metric that measures the percentage of data flow paths that are executed by the
test cases. A data flow path is a sequence of statements that define, use, or kill a variable. Data flow
coverage is useful for testing the correctness and completeness of the data manipulation in the
software, but not for testing the conditions that determine the actions. Statement coverage is a type
of structural coverage metric that measures the percentage of statements or lines of code that are
executed by the test cases. Statement coverage ensures that each statement is executed at least
once by the test cases, but it does not reveal the behavior of the software under different scenarios.
Statement coverage is a weaker criterion than branch coverage, because it does not account for the
branches or decision outcomes in the code. Reference = ISTQB Certified Tester Foundation Level
(CTFL) v4.0 syllabus, Chapter 4: Test Techniques, Section 4.3: Structural Testing Techniques, Pages 51-
54.

Question: 92
What is test oracle?

A. The source of lest objectives

B. The source for the actual results
C. The source of expected results
D. The source of input conditions

Answer: C
Explanation:

A test oracle is a mechanism or principle that can be used to determine whether the observed
behavior or output of a system under test is correct or not1. A test oracle can be based on various
sources of expected results, such as specifications, user expectations, previous versions, comparable
systems, etc2. Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Section 1.2.1,
Page 91; ISTQB Glossary of Testing Terms, Version 4.0, Page 332.

Question: 93

[Link]
Questions PDF 62/89

Which ONE of the following statements does NOT describe how testing contributes to higher quality?

A. Properly designed tests that pass reduce the level of risk in a system.
B. The testing of software demonstrates the absence of defects.
C. Software testing identifies defects, which can be used to improve development activities.
D. Performing a review of the requirement specifications before implementing the system can
enhance quality.

Answer: B
Explanation:

The testing of software does not demonstrate the absence of defects, but rather the presence of
defects or the conformance of the software to the specified requirements1. Testing can never prove
that the software is defect-free, as it is impossible to test all possible scenarios, inputs, outputs, and
behaviors of the software2. Testing can only provide a level of confidence in the quality of the
software, based on the coverage, effectiveness, and efficiency of the testing activities3.
The other options are correct because:
A) Properly designed tests that pass reduce the level of risk in a system, as they verify that the
system meets the expected quality attributes and satisfies the needs and expectations of the users
and clients4. Risk is the potential for loss or harm due to the occurrence of an undesirable
event5. Testing can help to identify, analyze, prioritize, and mitigate the risks associated with the
software product and project6.
C) Software testing identifies defects, which can be used to improve development activities, as they
provide feedback on the quality of the software and the effectiveness of the development
processes7. Defects are flaws or errors in the software that cause it to deviate from the expected or
required results or behavior. Testing can help to detect, report, track, and resolve the defects, and
prevent them from recurring in the future.
D) Performing a review of the requirement specifications before implementing the system can
enhance quality, as it can ensure that the requirements are clear, complete, consistent, testable, and
aligned with the needs and expectations of the users and clients. Requirements are the specifications
of what the software should do and how it should do it. Testing can help to validate that the
requirements are met by the software, and verify that the software is implemented according to the
requirements.
Reference =
1 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 10
2 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 11
3 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 12
4 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 13
5 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 97
6 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 98
7 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 14
[8] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 15
[9] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 16
[10] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 17
[11] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 18
[12] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 19

Question: 94

[Link]
Questions PDF 63/89

Which of the following statements describes regression testing?

I, Retesting of a fixed defect
II, Testing of an already tested program
III, Testing of new functionality in a program
IV, Regression testing applies only to functional testing
V Tests that do not nave to be repeatable, because They are only used once

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

Answer: C
Explanation:

Regression testing is the re-running of functional and non-functional tests to ensure that previously
developed and tested software still performs as expected after a change1 It does not involve
retesting of a fixed defect, testing of new functionality, or applying only to functional testing. Tests
that are used for regression testing should be repeatable, because they are used to verify the
stability of the software after each change2 Reference = ISTQB Certified Tester Foundation Level
(CTFL) v4.0 Syllabus, Chapter 4, Section 4.2.2, Page 291; ISTQB Glossary of Testing Terms v4.0, Page
292

Question: 95

A calculator software is used to calculate the result for 5+6.

The user noticed that the result given is 6.
This is an example of;

A. Mistake
B. Fault
C. Error
D. Failure

Answer: D
Explanation:

According to the ISTQB Glossary of Testing Terms, Version 4.0, 2018, page 18, a failure is “an event in
which a component or system does not perform a required function within specified limits”. In this
case, the calculator software does not perform the required function of calculating the correct result
for 5+6 within the specified limits of accuracy and precision. Therefore, this is an example of a failure.
The other options are incorrect because:
A mistake is “a human action that produces an incorrect result” (page 25). A mistake is not an event,
but an action, and it may or may not lead to a failure. For example, a mistake could be a typo in the
code, a wrong assumption in the design, or a misunderstanding of the requirement.
A fault is “a defect in a component or system that can cause the component or system to fail to

[Link]
Questions PDF 64/89

perform its required function” (page 16). A fault is not an event, but a defect, and it may or may not
cause a failure. For example, a fault could be a logical error in the code, a missing specification in the
design, or a contradiction in the requirement.
An error is “the difference between a computed, observed, or measured value or condition and the
true, specified, or theoretically correct value or condition” (page 15). An error is not an event, but a
difference, and it may or may not result in a failure. For example, an error could be a rounding error
in the calculation, a measurement error in the observation, or a deviation error in the condition.
Reference = ISTQB Glossary of Testing Terms, Version 4.0, 2018, pages 15-18, 25; ISTQB CTFL 4.0 -
Sample Exam - Answers, Version 1.1, 2023, Question 96, page 34.

Question: 96

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

Answer: B
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. Reference = ISTQB® Certified Tester Foundation Level Syllabus
v4.0, Requirements Engineering Fundamentals.

Question: 97

Which of the following statements is an example of testing contributing to higher quality?

A. A test leader writes a test summary report

B. A project manager asks to a test leader to estimate the test effort

[Link]
Questions PDF 65/89

C. A tester installs a test ten in the lest environment

D. A tester finds a bug which is resolved prior to release

Answer: D
Explanation:

The question is about identifying an example of testing contributing to higher quality. Quality is the
degree to which a component, system or process meets specified requirements and/or
user/customer needs and expectations1. Testing is the process consisting of all lifecycle activities,
both static and dynamic, concerned with planning, preparation and evaluation of software products
and related work products to determine that they satisfy specified requirements, to demonstrate
that they are fit for purpose and to detect defects2.
Therefore, testing contributes to higher quality by verifying and validating that the software products
and related work products meet the specified requirements, are fit for purpose and have no defects,
or at least have a reduced number of defects. Testing also provides information about the quality of
the software products and related work products to the stakeholders, who can make informed
decisions based on the test results3.
Out of the four given statements, only option D is an example of testing contributing to higher
quality, as it shows that testing has detected a defect (a flaw in a component or system that can
cause the component or system to fail to perform its required function4) and that the defect has
been resolved (fixed and confirmed) prior to release (delivery of the software product to the
customer or end user). This means that testing has prevented a potential failure (an event in which a
component or system does not perform a required function within specified limits) from occurring in
the operational environment, and thus has improved the quality of the software product.
Option A is not an example of testing contributing to higher quality, as it is a reporting activity that
summarizes the test results and evaluates the test objectives, but does not directly affect the quality
of the software product or related work products. A test summary report is a document that records
and communicates the outcomes of testing activities, including test completion criteria, test results,
incident reports, test summary and evaluation, and lessons learned.
Option B is not an example of testing contributing to higher quality, as it is a planning activity that
estimates the resources and time needed for testing activities, but does not directly affect the quality
of the software product or related work products. A test effort estimate is an approximation of the
amount of work and/or the duration of time required to perform testing activities.
Option C is not an example of testing contributing to higher quality, as it is a preparation activity that
sets up the test environment (an environment containing hardware, instrumentation, simulators,
software tools, and other support elements needed to conduct a test), but does not directly affect
the quality of the software product or related work products. A test environment installation is a
process of installing and configuring the test environment according to the test environment
specification.
Reference:
1: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 10
2: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 11
3: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 12
4: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 13
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 13
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 77
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 78
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 79

[Link]
Questions PDF 66/89

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 80

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 81
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 82
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 83
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 84
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 85
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 86
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 87
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 88
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 89
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 90
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 91
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 92
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 93
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 94
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 95
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 96
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 97
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 98
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 99
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 100
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 101
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 102
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 103
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 104
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 105
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 106
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 107

Question: 98
A software company decides to invest in reviews of various types. The thought process they have is
that each artifact needs to be reviewed using only one of the review methods depending on the
criticality of the artifact.

A. The thought process is incorrect. The whole company should adopt same standard for review of all
artifacts.
B. The thought process is correct. The whole company should decide or the review method based on
their CMM level.
C. The thought process is incorrect. Same artifact can be reviewed using different review methods
D. The thought process is correct. It wastes time to review same artifact using efferent review
methods

Answer: C
Explanation:

The thought process of the software company is incorrect, because it assumes that each artifact can
be reviewed using only one review method, and that the review method depends solely on the

[Link]
Questions PDF 67/89

criticality of the artifact. This is a simplistic and rigid approach that does not consider the benefits
and limitations of different review methods, the context and purpose of the review, and the feedback
and improvement opportunities that can be gained from multiple reviews. According to the CTFL 4.0
Syllabus, the selection of review methods should be based on several factors, such as the type and
level of detail of the artifact, the availability and competence of the reviewers, the time and budget
constraints, the expected defects and risks, and the desired outcomes and quality criteria. Moreover,
the same artifact can be reviewed using different review methods at different stages of the
development lifecycle, to ensure that the artifact meets the changing requirements, standards, and
expectations of the stakeholders. For example, a requirement specification can be reviewed using an
informal review method, such as a walkthrough, to get an initial feedback from the users and
developers, and then using a formal review method, such as an inspection, to verify the
completeness, correctness, and consistency of the specification. Therefore, the software company
should adopt a more flexible and context-sensitive approach to selecting and applying review
methods for different artifacts, rather than following a fixed and arbitrary rule. Reference = CTFL 4.0
Syllabus, Section 3.2.1, page 31-32; Section 3.2.2, page 33-34; Section 3.2.3, page 35-36.

Question: 99

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

A. Acceptance testing
B. Structural testing
C. Integration testing
D. Exploratory testing

Answer: B
Explanation:

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,

[Link]
Questions PDF 68/89

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. Reference = 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.

Question: 100

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

A)

B)

C)

[Link]
Questions PDF 69/89

D)

A. Option A
B. Option B
C. Option C
D. Option D

Answer: D
Explanation:

Option D correctly explains what is represented by the lines A, B and the axes X, Y in a testing metrics
chart. According to option D:
X-axis represents Time
Y-axis represents Count
Line A represents Number of open bugs
Line B represents Total number of executed tests
This information is essential in understanding and analyzing the testing metrics of a completed
project.
Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Section 2.5.1, Page 35.

Question: 101
Which of the following statements about estimation of the test effort is WRONG?

A. Once the test effort is estimated, resources can be identified and a schedule can be drawn up.
B. Effort estimate can be inaccurate because the quality of the product under tests is not known.
C. Effort estimate depends on the budget of the project.
D. Experience based estimation is one of the estimation techniques.

Answer: C
Explanation:

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

[Link]
Questions PDF 70/89

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

Question: 102

You are testing a room upgrade system for a hotel. The system accepts three differed types of room
(increasing order of luxury): Platinum. Silver and Gold Luxury. ONLY a Preferred Guest Card holder s
eligible for an upgrade.
Below you can find the decision table defining the upgrade eligibility:

What is the expected result for each of the following test cases?
Customer A: Preference Guest Card holder, holding a Silver room

[Link]
Questions PDF 71/89

Customer B: Non Preferred Guest Card holder, holding a Platinum room

A. Customer A; doesn't offer any upgrade; Customer B: offers upgrade to Gold luxury room
B. Customer A: doesn't offer any upgrade; Customer B: doesn't offer any upgrade.
C. Customer A: offers upgrade to Gold Luxury room; Customer B: doesn't offer any upgrade
D. Customer A: offers upgrade to Silver room; Customer B: offers upgrade to Silver room.

Answer:C

According to the decision table in the image, a Preferred Guest Card holder with a Silver room is
eligible for an upgrade to Gold Luxury (YES), while a non-Preferred Guest Card holder, regardless of
room type, is not eligible for any upgrade (NO). Therefore, Customer A (a Preferred Guest Card
holder with a Silver room) would be offered an upgrade to Gold Luxury, and Customer B (a non-
Preferred Guest Card holder with a Platinum room) would not be offered any upgrade. Reference =
The answer is derived directly from the decision table provided in the image; specific ISTQB Certified
Tester Foundation Level (CTFL) v4.0 documents are not referenced.

Question: 103
The four test levels used in ISTQB syllabus are:
1. Component (unit) testing
2. Integration testing
3. System testing
4. Acceptance testing
An organization wants to do away with integration testing but otherwise follow V-model. Which of
the following statements is correct?

A. It is allowed as organizations can decide on men test levels to do depending on the context of the
system under test
B. It is allowed because integration testing is not an important test level arc! can be dispensed with.
C. It is not allowed because integration testing is a very important test level and ignoring i: means
definite poor product quality
D. It is not allowed as organizations can't change the test levels as these are chosen on the basis of
the SDLC (software development life cycle) model

Answer: D
Explanation:

The V-model is a software development life cycle model that defines four test levels that correspond
to four development phases: component (unit) testing with component design, integration testing
with architectural design, system testing with system requirements, and acceptance testing with user
requirements. The V-model emphasizes the importance of verifying and validating each phase of
development with a corresponding level of testing, and ensuring that the test objectives, test basis,
and test artifacts are aligned and consistent across the test levels. Therefore, an organization that
wants to follow the V-model cannot do away with integration testing, as it would break the
symmetry and completeness of the V-model, and compromise the quality and reliability of the
software or system under test. Integration testing is a test level that aims to test the interactions and

[Link]
Questions PDF 72/89

interfaces between components or subsystems, and to detect any defects or inconsistencies that
may arise from the integration of different parts of the software or system. Integration testing is
essential for ensuring the functionality, performance, and compatibility of the software or system as
a whole, and for identifying and resolving any integration issues early in the development process.
Skipping integration testing would increase the risk of finding serious defects later in the test
process, or worse, in the production environment, which would be more costly and difficult to fix,
and could damage the reputation and credibility of the organization. Therefore, the correct answer is
D.
The other options are incorrect because:
A) It is not allowed as organizations can decide on the test levels to do depending on the context of
the system under test. While it is true that the choice and scope of test levels may vary depending on
the context of the system under test, such as the size, complexity, criticality, and risk level of the
system, the organization cannot simply ignore or skip a test level that is defined and required by the
chosen software development life cycle model. The organization must follow the principles and
guidelines of the software development life cycle model, and ensure that the test levels are
consistent and coherent with the development phases. If the organization wants to have more
flexibility and adaptability in choosing the test levels, it should consider using a different software
development life cycle model, such as an agile or iterative model, that allows for more dynamic and
incremental testing approaches.
B) It is not allowed because integration testing is not an important test level and can be dispensed
with. This statement is false and misleading, as integration testing is a very important test level that
cannot be dispensed with. Integration testing is vital for testing the interactions and interfaces
between components or subsystems, and for ensuring the functionality, performance, and
compatibility of the software or system as a whole. Integration testing can reveal defects or
inconsistencies that may not be detected by component (unit) testing alone, such as interface errors,
data flow errors, integration logic errors, or performance degradation. Integration testing can also
help to verify and validate the architectural design and the integration strategy of the software or
system, and to ensure that the software or system meets the specified and expected quality
attributes, such as reliability, usability, security, and maintainability. Integration testing can also
provide feedback and confidence to the developers and stakeholders about the progress and quality
of the software or system development. Therefore, integration testing is a crucial and indispensable
test level that should not be skipped or omitted.
C) It is not allowed because integration testing is a very important test level and ignoring it means
definite poor product quality. This statement is partially true, as integration testing is a very
important test level that should not be ignored, and skipping it could result in poor product quality.
However, this statement is too strong and absolute, as it implies that integration testing is the only
factor that determines the product quality, and that ignoring it would guarantee a poor product
quality. This is not necessarily the case, as there may be other factors that affect the product quality,
such as the quality of the requirements, design, code, and other test levels, the effectiveness and
efficiency of the test techniques and tools, the competence and experience of the developers and
testers, the availability and adequacy of the resources and environment, the management and
communication of the project, and the expectations and satisfaction of the customers and users.
Therefore, while integration testing is a very important test level that should not be skipped, it is not
the only test level that matters, and skipping it does not necessarily mean definite poor product
quality, but rather a higher risk and likelihood of poor product quality.
Reference = ISTQB Certified Tester Foundation Level Syllabus, Version 4.0, 2018, Section 2.3, pages
16-18; ISTQB Glossary of Testing Terms, Version 4.0, 2018, pages 38-39; ISTQB CTFL 4.0 - Sample
Exam - Answers, Version 1.1, 2023, Question 104, page 36.

[Link]
Questions PDF 73/89

Question: 104

During component testing of a program if 100% decision coverage is achieved, which of the following
coverage criteria is also guaranteed to be 100%?

A. 100% Stale transition coverage

B. 100% Equivalence class coverage
C. 100% Boundary value coverage
D. 100% Statement coverage

Answer: D
Explanation:

Statement coverage is a structural coverage metric that measures the percentage of executable
statements in the source code that are executed by a test suite1. Decision coverage is another
structural coverage metric that measures the percentage of decision outcomes (such as branches or
conditions) in the source code that are executed by a test suite1. Decision coverage is a stronger
metric than statement coverage, because it requires that every possible outcome of each decision is
tested, while statement coverage only requires that every statement is executed at least once2.
Therefore, if a test suite achieves 100% decision coverage, it also implies that it achieves 100%
statement coverage, because every statement in every branch or condition must have been
executed. However, the converse is not true: 100% statement coverage does not guarantee 100%
decision coverage, because some branches or conditions may have multiple outcomes that are not
tested by the test suite2. For example, consider the following pseudocode:
if (x > 0) then print(“Positive”) else print(“Non-positive”) end if
A test suite that executes this code with x = 1 and x = -1 will achieve 100% statement coverage,
because both print statements are executed. However, it will not achieve 100% decision coverage,
because the condition x > 0 has only been tested with two outcomes: true and false. The third
possible outcome, x = 0, has not been tested by the test suite. Therefore, the test suite may miss a
potential bug or error in the condition or the branch.
The other options, such as stale transition coverage, equivalence class coverage, and boundary value
coverage, are not guaranteed to be 100% by achieving 100% decision coverage. Stale transition
coverage is a structural coverage metric that measures the percentage of transitions between states
in a state machine that are executed by a test suite3. Equivalence class coverage is a functional
coverage metric that measures the percentage of equivalence classes (or partitions) of input or
output values that are tested by a test suite4. Boundary value coverage is another functional
coverage metric that measures the percentage of boundary values (or extreme values) of input or
output ranges that are tested by a test suite4. These metrics are independent of decision coverage,
because they are based on different aspects of the system under test, such as its behavior,
functionality, or specification. Therefore, achieving 100% decision coverage does not imply achieving
100% of any of these metrics, and vice versa. Reference = ISTQB® Certified Tester Foundation Level
Syllabus v4.0, Test Coverage in Software Testing - Guru99, Structural Coverage Metrics - MATLAB &
Simulink - MathWorks India, Test Design Coverage in Software Testing - GeeksforGeeks.

Question: 105

[Link]
Questions PDF 74/89

Mark the correct sentences:

* Defects are a result of environmental conditions and are also referred to as "Failures"
* A human mistake may produce a defect
* A system mil totally fail to operate correctly when a failure exists in it
* When a defect exists in a system it may result in a failure
* Defects occur only as a result of technology changes

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

Answer: A
Explanation:

The question is about marking the correct sentences among the given statements related to defects,
failures, and mistakes. According to the ISTQB glossary, the definitions of these terms are1:
Defect: A flaw in a component or system that can cause the component or system to fail to perform
its required function, e.g. an incorrect statement or data definition. A defect, if encountered during
execution, may cause a failure of the component or system.
Failure: An event in which a component or system does not perform a required function within
specified limits.
Mistake: A human action that produces an incorrect result.
Therefore, out of the five given statements, only two are correct, namely:
A human mistake may produce a defect: This is true, as a mistake is a source or cause of a defect, e.g.
a programmer may make a mistake in writing a code statement, which results in a defect in the
software component.
When a defect exists in a system it may result in a failure: This is true, as a defect is a potential or
actual cause of a failure, e.g. a defect in the software component may cause the system to fail to
perform a required function when the defect is encountered during execution.
The other three statements are incorrect, namely:
Defects are a result of environmental conditions and are also referred to as “Failures”: This is false, as
defects are not a result of environmental conditions, but of mistakes or other factors, and defects are
not the same as failures, but rather the causes of failures.
A system will totally fail to operate correctly when a failure exists in it: This is false, as a system may
not necessarily fail completely or stop operating when a failure occurs, but may continue to operate
with reduced functionality or performance, or with incorrect results.
Defects occur only as a result of technology changes: This is false, as defects can occur due to various
reasons, not only technology changes, such as human mistakes, design flaws, requirement changes,
hardware failures, etc.
Reference:
1: ISTQB Glossary of Testing Terms 4.0, 2023, available at ISTQB) and ASTQB).

Question: 106

Can "cost" be regarded as Exit criteria?

A. Yes. Spending too much money on test ng will result in an unprofitable product, and having cost as

[Link]
Questions PDF 75/89

an exit criterion helps avoid this

B. No. The financial value of product quality cannot be estimated, so it is incorrect to use cost as an
exit criterion
C. Yes. Going by cost as an exit criterion constrains the testing project which will hello achieve the
desired quality level defined for the project
D. No The cost of testing cannot be measured effectively, so it is incorrect to use cost as an exit
criterion

Answer: A
Explanation:

Cost can be regarded as an exit criterion for testing, because it is a factor that affects the profitability
and feasibility of the software product. Testing is an investment that aims to improve the quality and
reliability of the software product, but it also consumes resources, such as time, money, and human
effort. Therefore, testing should be planned and executed in a way that balances the cost and benefit
of testing activities. Having cost as an exit criterion helps to avoid spending too much money on
testing, which may result in an unprofitable product or a loss of competitive advantage. Cost can also
help to prioritize and focus the testing efforts on the most critical and valuable features and functions
of the software product. However, cost should not be the only exit criterion for testing, as it may not
reflect the true quality and risk level of the software product. Other exit criteria, such as defect rate,
test coverage, user satisfaction, etc., should also be considered and defined in the test plan.
The other options are incorrect, because they either deny the importance of cost as an exit criterion,
or they make false or unrealistic assumptions about the cost of testing. Option B is incorrect, because
the financial value of product quality can be estimated, for example, by using cost-benefit analysis,
return on investment, or cost of quality models. Option C is incorrect, because going by cost as an
exit criterion does not necessarily constrain the testing project or help achieve the desired quality
level. Cost is a relative and variable factor that depends on the scope, complexity, and context of the
software product and the testing project. Option D is incorrect, because the cost of testing can be
measured effectively, for example, by using metrics, such as test effort, test resources, test tools, test
environment, etc.

Question: 107
Which of the following sentences describe a product risk?

A. The application might not be able to provide the expected responsiveness under a load of up-lo
300 concurrent users
B. Failure in acquiring an adequate and test automation tool
C. A wrong configuration of the test environment that causes incidents related to the environment
and not to the software under test
D. The development team lacks knowledge of the technology on which the product is based

Answer: A
Explanation:

This question relates to identifying product risks, which are potential problems associated with the
product itself, such as software functionality, reliability, usability, and performance. Option A

[Link]
Questions PDF 76/89

describes a scenario where the application might not meet performance requirements under specific
conditions (up to 300 concurrent users), which directly impacts the product's ability to perform its
intended function. This is a classic example of a product risk, as it concerns the product's quality and
its ability to meet user needs. Options B, C, and D, on the other hand, relate to project risks, which
are concerns related to the management and execution of the project, such as tool acquisition,
environment configuration, and team expertise, rather than the quality of the product itself.

Question: 108
Which of the following activities is NOT a pan of the fundamental testing process?

A. Archiving automation code

B. Test status reporting
C. Test process improvement
D. Build release and maintenance

Answer: D
Explanation:

The fundamental testing process includes activities that are directly related to the planning,
preparation, execution, and evaluation of tests, as well as the closure activities of the testing phase.
Option D, "Build release and maintenance," falls outside the scope of the fundamental testing
process as it relates more to software development and operations rather than specific testing
activities. Options A, "Archiving automation code," B, "Test status reporting," and C, "Test process
improvement," are all activities that can be part of or associated with the fundamental testing
process. Archiving automation code is part of test closure, test status reporting is part of test
monitoring and control, and test process improvement can be an outcome of test closure activities.

Question: 109
Your manager asked you when testing will be complete. In order to answer this question, you'll most
likely use:

A. Test progress reports

B. Your colleagues advice
C. A conversion spreadsheet
D. A Test Oracle

Answer: A
Explanation:

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,

[Link]
Questions PDF 77/89

detailed, and specific information required to accurately answer the manager's question about the
completion of testing.

Question: 110
You are testing the download process of a mobile phone application.
For which to the following capabilities to the system you need to design a nonfunctional test?

A. It was easy to locate, download and install the application

B. The application was correctly downloaded
C. The application created an installation log file in a given folder
D. The application installed only after the user's approval

Answer: A
Explanation:

This question asks for a non-functional aspect of testing the download process of a mobile
application. Option A, "It was easy to locate, download and install the application," refers to usability,
which is a non-functional quality attribute. Non-functional testing involves testing the system's
attributes, such as usability, performance, reliability, etc., rather than specific behaviors or functions.
Options B, "The application was correctly downloaded," C, "The application created an installation
log file in a given folder," and D, "The application installed only after the user's approval," describe
functional aspects, focusing on what the software does rather than how it performs or is experienced
by the user.

Question: 111

Which of the following statements about static analysis are FALSE?

I, Static analysis can be used Instead of dynamic testing.
II, Stalk: analysis can uncover defects like security vulnerabilities.
III, Static analysis can be used to check conformance to specifications and standards.
IV Static analysis typically detects failures prior to component testing.

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

Answer: D
Explanation:

Static analysis involves analyzing the software's code, design, and structure without executing the
program. It can uncover various types of defects, including security vulnerabilities (II) and non-
conformance to specifications and standards (III). However, static analysis cannot replace dynamic
testing (I), which involves executing the software to observe its behavior under various conditions.
Dynamic testing can identify failures that static analysis cannot, such as those related to runtime
issues and interaction between different parts of the software. Statement IV is false because static

[Link]
Questions PDF 78/89

analysis does not detect failures; it detects defects. Failures are observed when the software is
executed, which is beyond the scope of static analysis.

Question: 112
Which of the following is a typical product risk?

A. Poor usability of the software

B. A problem in the code developed by a 3rd party
C. Low quality of the configuration data, test data and tests
D. Problem in defining the right requirements

Answer: A
Explanation:

A typical product risk involves issues directly related to the software product's functionality,
performance, usability, reliability, etc. Option A, "Poor usability of the software," directly impacts the
end-user's interaction with the software and is a quality attribute of the product itself, making it a
product risk. Options B, "A problem in the code developed by a 3rd party," C, "Low quality of the
configuration data, test data and tests," and D, "Problem in defining the right requirements," can be
considered either product or project risks depending on the context, but option A is the most directly
associated with a typical product risk concerning the quality and usability of the software.

Question: 113
Which of the following exemplifies how a software bug can cause harm to a company?

A. "Print" prints the last page twice for a file with 1000 pages
B. The timeout on the login page of a web site is 9 minutes, while the requirement was for 10
minutes
C. When uninstalling the application, the uninstall dialog has a spelling mistake
D. When calculating the final price in a shopping list, the price of the last item is not added

Answer: D
Explanation:

A software bug can cause harm to a company by directly affecting its operations, reputation, user
satisfaction, and financials. Option D, "When calculating the final price in a shopping list, the price of
the last item is not added," describes a defect that directly impacts the core functionality of a
financial transaction, potentially leading to financial loss and customer dissatisfaction. This can have
severe implications for the company's credibility and revenue. Options A, B, and C describe bugs
that, while potentially annoying, do not have the same direct impact on the company's core
operations and financial integrity as option D.

Question: 114
Which or the following is a valid collection of equivalence classes for the following problem: An

[Link]
Questions PDF 79/89

integer field shall contain values from and including 1 to and including 15.

A. Less than 0.1 through 14. 15 and more

B. Less than 1.1 through 14. more than 15
C. negative numbers. 1 through 15. above 15
D. Less than 1.1 through 15. more than 15

Answer: D
Explanation:

Equivalence partitioning is a black-box test design technique where inputs to the software or system
are divided into groups that are expected to exhibit similar behavior. For an integer field that should
accept values from 1 to 15, the valid equivalence class is 1 through 15. The invalid equivalence
classes are numbers less than 1 and numbers more than 15. Therefore, option D, "Less than 1, 1
through 15, more than 15," correctly identifies the valid equivalence class along with the two invalid
classes, covering all possible input scenarios for the field. Options A, B, and C either do not accurately
capture the valid range or incorrectly specify the range boundaries.

Question: 115
Why is it important to select a test technique?

A. There are usually loo many test cases that may be run on a system. Test techniques help reduce
the number of tests.
B. The only way to test a software application is by using well proven test techniques.
C. Selecting the right test technique in a given situation Increases the effectiveness of the test
process Oy creating tests with higher chance of finding bugs.
D. Test techniques define the number of regression cycles, which in turn impact the project schedule.

Answer: C
Explanation:

Selecting the right test technique is crucial because different techniques are suited to different types
of testing and can significantly increase the effectiveness of the testing process by creating tests that
are more likely to find defects. While reducing the number of tests (A) and defining the number of
regression cycles (D) are considerations in the testing process, they are not the primary reasons for
selecting a test technique. The assertion that the only way to test a software application is by using
well-proven test techniques (B) is too restrictive and does not acknowledge the adaptability required
in testing to suit different contexts and objectives. Therefore, option C is the most comprehensive
reason, as it focuses on the effectiveness and efficiency of testing, leading to the creation of high-
quality tests that have a higher chance of finding bugs.

Question: 116
Which of the following activities does NOT belong to a typical technical review?

A. Pre-meeting preparation by reviewers

[Link]
Questions PDF 80/89

B. Using checklists during the meeting

C. Inviting end-users to the meeting
D. Preparation of a review report

Answer: C
Explanation:

Technical reviews are structured meetings that aim to examine various aspects of a product or
project to identify any defects or improvements. Options A (Pre-meeting preparation by reviewers),
B (Using checklists during the meeting), and D (Preparation of a review report) are typical activities in
a technical review process. Inviting end-users to the meeting (C), however, is generally not part of a
typical technical review, as these reviews are usually more focused on the technical aspects and are
conducted by peers or experts within the development or testing teams rather than end-users.

Question: 117
Which of the following activities are part of test planning?
I) Setting the entry and exit criteria
II) Determining the validity of bug reports
III) Determining the number of resources required
IV) Determining the expected result for test cases

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

Answer: B
Explanation:

Test planning is a key activity in the testing process that involves defining the objectives, approach,
resources, and schedule of intended test activities. Setting the entry and exit criteria (I) and
determining the number of resources required (III) are integral parts of test planning. Determining
the validity of bug reports (II) is more aligned with test analysis or test management activities post-
execution, and determining the expected result for test cases (IV) is part of test design. Therefore,
options I and III (B) are the activities that belong to test planning.

Question: 118

Consider the following code

int premium=2500;
if (age<30)
{
premium = premium +1500:
}
Which options suits for a correct combination of Boundary value and expected result. Assume first
number as boundary followed by expected result.

[Link]
Questions PDF 81/89

A. 29, 1500
30. 2500
B. 29. 4000
30. 2500
C. 29, 2500
30. 1500
D. 30, 1500
31,2500

Answer: B
Explanation:

In the given code snippet, the premium is increased by 1500 if the age is less than 30. Therefore, at
the boundary value of age 29, the premium should be 2500 + 1500 = 4000, and at age 30, the
premium should remain at its initial value of 2500, as the condition is no longer met. Option B
correctly reflects this with 29, 4000 and 30, 2500 as the boundary value and the expected results,
respectively.

Question: 119
When should component integration tests be carried out?

A. Integration tests should always be done after system tests

B. Integration tests should be done at the customer's site, after acceptance tests
C. Integration tests can be done before or after system tests
D. Integration tests should always be done before system tests

Answer: D
Explanation:

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.

Question: 120
"Statement Testing" is part of;

A. Specification Based testing

B. Decision Testing
C. Experience based testing
D. Structured based testing

Answer: D

[Link]
Questions PDF 82/89

Explanation:

Statement Testing is a type of white-box testing technique where the test cases are designed based
on the implementation of the software, specifically aiming to execute every statement in the code at
least once. This falls under the category of structure-based testing (also known as white-box testing),
where the internal structure of the system is used to design test cases. Therefore, option D is correct.

Question: 121

While repotting a defect, which attribute indicates the degree of impact that the defect has on the
system?

A. Priority
B. Severity
C. Status
D. Description

Answer: B
Explanation:

In defect reporting, the attribute that indicates the degree of impact that the defect has on the
system is the severity. Severity reflects the seriousness of the defect in terms of its impact on the
operation of the system, ranging from minor issues that do not significantly affect the system's
functionality to critical defects that can cause system failure. Therefore, option B is the correct
answer.

Question: 122

Which of the following would be LEAST appropriate as part of an incident report covering the
observation of a failure during testing?

A. SOL injection into the username entry field allowed a variety of SQL commands to be executed by
the application without the appropriate authority.
B. The user interface was complicated and confusing and I found It quite difficult to follow
the test script.
C. The updates made as part of the add new member' function did not reflect the expected change
as the name was written into the address field.
D. The expected result for the ‘list friends' response time was less than 10 seconds, whereas the
average response time obtained was 13 seconds.

Answer: B
Explanation:

An incident report during testing should focus on factual observations of failures or defects in the
system, including their impacts and how they deviate from expected results. Options A, C, and D
describe specific issues that are directly related to the system's behavior or performance and are
suitable for inclusion in an incident report. Option B, which describes the user interface as

[Link]
Questions PDF 83/89

"complicated and confusing" and relates to the tester's personal difficulty in following the test script,
is more subjective and relates to the tester's experience rather than an objective observation of a
system failure. Therefore, option B is the least appropriate for an incident report.

Question: 123

Which or the following would be a key difference between a peer review of code and static analysis
of code using a tool?

A. A peer reviews finds defects while static analysis finds failures.

B. Static analysis targets the code technically whereas Peer review is applicable to further aspects.
C. Peer reviews cannot find missing requirements whereas static analysis can
D. A peer reviews find failures while static analysis finds defects.

Answer: B
Explanation:

The key difference between a peer review of code and static analysis of code using a tool lies in their
approaches and scope. A peer review is a manual inspection of the code by peers or colleagues,
focusing not only on the technical aspects of the code but also on other elements such as design,
compliance with standards, and maintainability. Peer reviews can identify defects, suggest
improvements, and ensure that the code adheres to best practices and team standards.
On the other hand, static analysis is an automated process performed by tools designed to analyze
the code without executing it. These tools can detect potential issues such as syntax errors,
vulnerabilities, and code smells based on predefined rules and patterns. While static analysis is
technically focused, it lacks the broader perspective that human reviewers can provide, such as
evaluating the code's maintainability or adherence to project-specific standards. Therefore, static
analysis targets the code technically, whereas peer review encompasses a wider range of aspects,
making option B the correct answer.

Question: 124

For the following pseudo-code determine number of tests required for 100% statement coverage
IF Gender = Boy
If Age > 3 AND Age < 5
Shoe Size = 1
ELSE IF Age >=5 AND Age < 7
Shoe Size = 2
ENDIF
ELSE
IF Age > 3 AND Age < 5
Shoe Size = 0
ELSE IF Age >=5 AND Age < 7
Shoe Size = 1
ENDIF
ENDIF

[Link]
Questions PDF 84/89

A. 6
B. 4
C. 2
D. 6

Answer: B
Explanation:

To achieve 100% statement coverage, we need to design test cases that ensure every statement in
the given pseudo-code is executed at least once. Analyzing the pseudo-code, we notice that there
are conditions based on two variables: Gender and Age. To cover all statements, we need to consider
the paths that lead to each assignment of the Shoe Size variable.
Gender = Boy, Age <= 3 (Shoe Size assignment is not reached, but the condition is evaluated)
Gender = Boy, Age > 3 AND Age < 5 (Shoe Size = 1)
Gender = Boy, Age >= 5 AND Age < 7 (Shoe Size = 2)
Gender != Boy, Age <= 3 (Again, Shoe Size assignment is not reached, but the condition is evaluated)
Gender != Boy, Age > 3 AND Age < 5 (Shoe Size = 0)
Gender != Boy, Age >= 5 AND Age < 7 (Shoe Size = 1)
However, upon closer inspection, we see that tests 1 and 4 do not contribute to statement coverage
as they do not lead to a Shoe Size assignment. Therefore, we only need 4 test cases to achieve 100%
statement coverage, making option B the correct answer.

Question: 125
The following open incident report provided:
Date: 01.01.01
Description: When pressing the stop button the application status remain in "Attention" instead of
"Ready'.
Severity: High
Life Cycle: Integration
Which of the following details are missing in the giving incident report?
I, Identification or configuration of the application
II, The name of the developer
III, Recommendation of the developer
IV The actions and/or conditions that came before the pressing of the button

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

Answer: B
Explanation:

In an incident report, essential details provide context and facilitate the investigation and resolution
of the incident. The missing elements in the given incident report are:
I, Identification or configuration of the application: This detail is crucial as it specifies which version

[Link]
Questions PDF 85/89

or configuration of the application is affected, helping in reproducing the issue. IV, The actions and/or
conditions that came before pressing the button: Understanding the sequence of actions leading to
the issue is vital for replicating and diagnosing the problem.
The name of the developer (II) and the recommendation of the developer (III) are not typically
included in an incident report as they do not contribute to identifying or resolving the incident. The
focus is on the incident's details, reproduction steps, and the system's state rather than on personnel
or proposed solutions at this stage. Therefore, option B, which includes both I and IV, is the correct
answer.

Question: 126
Which ONE of the following statements about state transition testing is correct?

A. The state transition diagram explicitly shows all invalid transitions.

B. The size of the state table depends on the number of possible transitions between the states
C. Usually it is not possible to create tests to cover ell transitions and all stales
D. All transitions between states are explicitly shown in the state table.

Answer: D
Explanation:

State transition testing is a black-box testing technique used to analyze the behavior of a system by
examining the transitions between different states in response to events. In state transition testing, a
state table or diagram is used to represent the states of a system and the transitions between these
states triggered by events.
Option D is correct because in state transition testing, all transitions between states should be
explicitly shown in the state table. This includes valid transitions that the system is expected to make
under normal operation and, where relevant, invalid transitions that should be tested to ensure the
system handles unexpected or erroneous inputs gracefully. The state table provides a comprehensive
view of how the system should behave, making it possible to create tests that cover all defined
transitions.

Question: 127

The ISTOB glossary defines Quality Assurance as: "Pail or quality management focused on providing
confidence that quality requirements will be fulfilled. Which of the following Is not one of the Quality
Assurance activity?

A. Requirements elicitation
B. Defect analysis
C. Functional Testing
D. Performance Testing

Answer: C
Explanation:

Quality Assurance (QA) activities are focused on providing confidence that quality requirements will

[Link]
Questions PDF 86/89

be fulfilled through planned and systematic processes. These activities are preventive in nature,
aimed at ensuring quality is built into the product from the beginning.
Requirements elicitation (A) is part of the requirements engineering process and is concerned with
gathering the needs and conditions to meet for a new or altered product.
Defect analysis (B) can be part of QA activities as it involves analyzing defects to prevent them in
future development cycles.
Functional Testing (C) and Performance Testing (D) are types of dynamic testing, which are actually
Quality Control activities rather than Quality Assurance. They are concerned with the identification
of defects in the product, not with the processes to prevent defects.
Since the question asks for an activity that is NOT part of Quality Assurance, options A and B are
incorrect because they can be part of QA activities. Between C and D, while both are dynamic testing
activities, Functional Testing (C) is more directly related to verifying the functionality against
specified requirements, which is more aligned with Quality Control. Therefore, C is the best answer.

Question: 128

Which of the following statements about testing in the context of an agile (iterative-incremental)
development model is correct?

A. Unit test and acceptance test ate the most important tests to make sure that the system works as
expected.
B. Each iteration of testing has to be completely finished before a new Iteration of development
starts.
C. Regression testing is necessary whenever a new Increment Is added to the existing system. D. Only
certain types of non-functional and explorative testing are performed.

Answer: C
Explanation:

In the context of agile (iterative-incremental) development models, testing is integrated into the
development process and occurs continuously throughout the lifecycle of the project. Agile testing
emphasizes adaptability and the need for feedback at various stages of development.
Option C is correct because regression testing is indeed necessary whenever a new increment is
added to the existing system. Agile development often involves frequent changes and additions to
the codebase, which can potentially introduce new defects into previously tested code. Regression
testing ensures that new changes have not adversely affected existing functionality.
Options A, B, and D present misconceptions about agile testing:
A is incorrect because, in agile, all types of testing (unit, integration, system, acceptance) are
important and occur throughout the iteration, not just unit and acceptance tests.
B is incorrect because agile methodologies advocate for continuous integration and testing, where
development and testing activities overlap and support each other throughout an iteration.
D is incorrect because agile methodologies encourage a wide range of testing types, including both
functional and non-functional, as well as exploratory testing, to ensure a comprehensive quality
assessment.

Question: 129

[Link]
Questions PDF 87/89

Which of the following is the main benefit of a configuration management of testware?

A. All testware is backed up with restore option, including incident reports and change requests. B.
The testware can be traced to information in requirements tools and to the bug tracking system.
C. All testware items are identified, version controlled, tracked tor changes with relation to each
other
D. There is an easy way to assess the level to test coverage provided by the existing tests

Answer: C
Explanation:

Configuration management of testware is a critical aspect of maintaining the integrity and

traceability of test assets throughout the testing lifecycle. The main benefit of configuration
management is to ensure that all testware items, such as test cases, test scripts, test data, and test
results, are systematically identified, version controlled, and tracked for changes in relation to each
other.
Option C accurately describes this benefit. By applying configuration management principles to
testware, teams can manage changes to test assets efficiently, ensuring that the testware remains
consistent, up-to-date, and aligned with the version of the software under test. This control
mechanism facilitates the reproducibility of tests, enhances the reliability of testing activities, and
supports traceability from requirements through to defects.
Options A, B, and D describe other aspects of test management and testing processes but do not
capture the core benefit of configuration management of testware, which is centered on the
systematic control and tracking of testware items.

Question: 130
Which of the following definitions is NOT true?

A. Test data preparation tools fill databases, create files or data transmissions to set up test data to
be used during the execution of tests.
B. Test execution tools execute test objects using automated test scripts.
C. Test Management tools monitor and report on how a system behaves during the testing activities.
D. Test comparators determine differences between files, databases or test results.

Answer: C
Explanation:

Test Management tools are designed to support the planning, execution, and monitoring of the
testing process. They provide features for managing test cases, test runs, tracking defects, and
reporting on testing activities. However, the statement in option C describes Test Management tools
as monitoring and reporting on the system's behavior during testing activities, which is not accurate.
Test Management tools focus on the testing process itself rather than on the behavior of the system
under test.
Test data preparation tools (A) indeed create and manage test data for use during test execution.
Test execution tools (B) automate the execution of test cases and the comparison of actual outcomes
against expected results.

[Link]
Questions PDF 88/89

Test comparators (D) are tools that compare actual outcomes with expected outcomes, highlighting
discrepancies.
Therefore, option C is the correct answer as it inaccurately describes the function of Test
Management tools.

[Link]
Questions PDF 89/89

[Link]