ISTQB Foundation (CTFL v4.0) Mock Exam #3 — Questions & Answers
Every question in this mock exam, with the correct answer marked and a written rationale behind each option below — for reading and review, not a timed run.
Which statement about the seven testing principles is CORRECT?
Exhaustive testing is impossible, so testing must be focused using risk and priorities.
Correct — this is the principle 'exhaustive testing is impossible'.
Testing can prove that software is completely free of defects.
Testing shows the presence of defects, not their absence.
Running the same tests repeatedly keeps finding new defects.
This contradicts the pesticide paradox — repeated tests stop finding new defects.
Defects are spread uniformly across all modules.
Defects cluster — a few modules usually contain most defects.
Exhaustive testing (testing all input/precondition combinations) is impossible except for trivial cases; risk and priorities should focus the test effort instead.
A developer makes a mistake while coding a calculation. This results in incorrect code, which when executed produces a wrong total on the screen. Using ISTQB terminology, what is the wrong total on the screen?
A failure
Correct — the displayed wrong total is the observable failure caused by the defect.
A defect
The defect is the flaw in the code, not the wrong output on screen.
An error
The error (mistake) is the human action that introduced the defect.
A root cause
The root cause is the underlying reason for the mistake, not the visible wrong total.
Mistake (error) → defect (in the code) → failure (the observable wrong behaviour). The wrong total displayed is a failure.
Which of the following is an example of testing contributing to success rather than just finding defects?
Testers reviewing requirements before coding starts, preventing defects.
Correct — early involvement prevents defects, contributing to success.
Logging as many defects as possible during system testing.
This is defect detection, not the broader contribution to success.
Re-running failed tests after a fix.
Confirmation testing verifies fixes; it is not the described preventive contribution.
Counting the number of test cases executed per day.
A productivity metric, not a contribution to product success.
Testers reviewing requirements early can prevent defects from being built into the product — a contribution to success beyond defect detection.
Which TWO of the following are typical test objectives? (Choose two.)
Building confidence in the quality of the test object.
Correct — a recognised testing objective.
Providing information to support decision-making.
Correct — testing provides information to stakeholders.
Fixing the defects that are found.
Fixing is debugging/development, not a testing objective.
Writing the system requirements specification.
Authoring requirements is a business-analysis task, not testing.
Typical objectives include preventing defects, finding defects/failures, building confidence, providing information for decisions, and verifying/validating. Fixing defects and writing requirements are not testing objectives.
Which pair correctly distinguishes verification from validation?
Verification: meeting specified requirements; Validation: meeting users' actual needs.
Correct — the standard distinction.
Verification: dynamic testing; Validation: static testing.
Both can use static or dynamic techniques; this mapping is wrong.
Verification: done by users; Validation: done by developers.
Roles do not define the distinction.
Verification and validation are synonyms.
They are related but distinct activities.
Verification checks that work products meet specified requirements (building the product right); validation checks that the product meets users' actual needs (building the right product).
During which test activity are the test environment, infrastructure and tools verified to be ready, and entry criteria checked before execution begins?
Test implementation
Correct — implementation prepares and verifies the environment and resources.
Test planning
Planning defines objectives and approach, not the final environment check.
Test design
Design transforms test conditions into test cases.
Test completion
Completion gathers data and reports after testing ends.
In the ISTQB test process, test implementation includes verifying that the environment and required resources are set up correctly before execution starts.
Which of the following BEST describes traceability between the test basis and test work products?
It enables coverage assessment, impact analysis and auditability of the testing.
Correct — these are key benefits of traceability.
It guarantees that no defects remain in the software.
Traceability does not prove the absence of defects.
It replaces the need for test planning.
Traceability supports but does not replace planning.
It is only useful for automated tests.
Traceability applies to manual and automated tests alike.
Good traceability links test conditions, test cases and results back to the test basis, enabling impact analysis, coverage assessment and auditability.
Which of the following is the BEST example of a tester demonstrating a good testing mindset and the right interpersonal skills when reporting a defect?
Describing the defect factually and neutrally, focusing on the product, not the person.
Correct — constructive, fact-based communication maintains good relationships.
Pointing out which developer caused the defect in the report.
Blaming individuals damages relationships and is counter-productive.
Waiting until many defects accumulate before reporting them at once.
Delaying defect reports reduces their value and timeliness.
Reporting only the defects that confirm the tester's own expectations.
Confirmation bias undermines objective testing.
Defects should be communicated constructively and factually, focusing on the product rather than blaming the author, to maintain good working relationships.
According to the principle of 'early testing' (shift left), which is the BEST reason to involve testing during the requirements phase?
Defects found early are cheaper to fix and prevented from propagating.
Correct — the cost of fixing rises sharply the later a defect is found.
It allows skipping system and acceptance testing later.
Early testing complements, it does not replace, later test levels.
Requirements never contain defects, so review is quick.
Requirements frequently contain defects such as ambiguities and gaps.
It guarantees the project will finish on time.
Early testing reduces risk but cannot guarantee schedule.
Defects found in requirements are far cheaper to fix than those found later; reviewing requirements early prevents costly defects from propagating into design and code.
A team has just integrated several components and wants to verify that the interfaces and data flows between them work correctly. Which test level is this?
Integration testing
Correct — it targets interfaces and interactions between components.
Component testing
Component testing checks a single component in isolation.
Acceptance testing
Acceptance testing validates readiness for use by users/customers.
System testing
System testing checks the behaviour of the whole integrated system.
Integration testing focuses on the interactions and interfaces between integrated components or systems.
Which of the following is a FUNCTIONAL test type?
Verifying that a money transfer debits and credits the correct accounts.
Correct — it tests a function the system must perform.
Measuring response time under 1000 concurrent users.
This is performance (non-functional) testing.
Assessing how easily new users can complete checkout.
This is usability (non-functional) testing.
Checking the app installs on three operating systems.
This is portability (non-functional) testing.
Functional testing evaluates what the system does (its functions). Performance, usability and portability are non-functional quality characteristics.
After a defect fix, the team re-runs tests on unchanged areas of the application to ensure the fix introduced no unintended side effects. What is this called?
Regression testing
Correct — it detects unintended side effects of changes.
Confirmation testing
Confirmation testing re-runs only the originally failed test after the fix.
Smoke testing
Smoke testing is a shallow check that the build is stable enough to test.
Exploratory testing
Exploratory testing is simultaneous learning, design and execution, not side-effect checking.
Regression testing checks that previously working functionality has not been broken by changes. Confirmation testing re-runs only the test that originally failed.
A maintenance change is made to a live system to make it run on a new operating system version, with no change in functionality. Which trigger for maintenance does this represent?
Migration to a new operating environment.
Correct — adapting to a new OS/platform is a recognised maintenance trigger.
Corrective maintenance to fix a production failure.
No defect is being fixed here; functionality is unchanged.
Enhancement to add a new feature.
No new functionality is added.
Retirement of the system.
The system is being kept running, not retired.
Migrating software to a new operating environment (new OS, platform or hardware) is an 'adaptive' or environment/migration maintenance trigger.
Besides functional and non-functional test types, the syllabus describes a test type that evaluates whether the internal structure or implementation of the test object has been exercised sufficiently, for example by measuring statement or branch coverage. Which test type is this?
White-box testing
Correct — white-box (structure-based) testing is the test type concerned with how thoroughly the internal structure of the test object has been exercised.
Non-functional testing
Non-functional testing evaluates how well the system behaves — performance, usability, reliability and similar characteristics — not how much of its code structure has been exercised.
Functional testing
Functional testing evaluates what the system does against its functional requirements, treating the internal structure as irrelevant to test selection.
Confirmation testing
Confirmation testing is change-related testing: the tests that previously failed are re-run to check that a fix works. It says nothing about structural coverage.
White-box testing (structure-based testing) derives tests from the internal structure or implementation of the test object and typically reports structural coverage such as statement or branch coverage.
Which of the following can be examined by static testing but NOT by dynamic testing?
Ambiguities and inconsistencies in a requirements document.
Correct — only static testing can review non-executable documents.
Memory leaks during execution.
Memory leaks appear only when the code runs — dynamic testing.
Actual response time of a transaction.
Response time requires execution — dynamic testing.
Incorrect results produced when running the program.
Observing wrong results requires execution — dynamic testing.
Static testing can find defects in work products that are not executable, such as requirements ambiguities and inconsistencies, which dynamic testing (which requires execution) cannot.
In which review type are the main purposes detecting defects, evaluating quality and building confidence, with a trained moderator/facilitator and a documented, formal process based on rules and checklists?
Inspection
Correct — the most formal review with a trained moderator and metrics.
Informal review
An informal review has no defined process or documented results.
Walkthrough
A walkthrough is led by the author and is less formal than inspection.
Technical review
A technical review is formal but focuses on technical decisions, often without a trained moderator and full metrics.
An inspection is the most formal review type: led by a trained moderator, follows a defined process with roles, rules, checklists and metrics.
Which of the following is a key success factor for a review, related to people rather than the process?
Conducting the review in an atmosphere of trust, without blaming participants.
Correct — a people-related factor that encourages openness.
Defining clear objectives for the review.
Important, but this is a process-related factor.
Using checklists appropriate to the work product.
A useful technique, but a process-related factor.
Keeping the work product small enough to review effectively.
A process/organisational factor, not a people factor.
People-related success factors include conducting reviews in an atmosphere of trust, without blame, so participants feel safe and engaged.
In a formal review, who is responsible for the document under review and usually fixes the defects found?
The author
Correct — the author owns the work product and applies the fixes.
The moderator (facilitator)
The moderator leads the review process, not the document's content.
The scribe (recorder)
The scribe records the findings during the meeting.
The review leader
The review leader plans the review overall but does not own the document.
The author creates and is responsible for the work product under review and typically performs the resulting changes.
The state diagram below models a media player. Treating each transition as a separate test case, what is the minimum number of test cases required to achieve 0-switch coverage (every valid transition exercised once)?
5
There are five valid transitions, and one test case per transition gives five.
3
3 is the number of states, not the number of transitions to cover.
4
This undercounts; the diagram has five valid transitions, not four.
6
This overcounts; there is no sixth valid transition in the diagram.
0-switch coverage requires each valid transition once. The diagram shows five transitions (Stopped→Playing, Playing→Paused, Playing→Stopped, Paused→Playing, Paused→Stopped), so five test cases.
An input field accepts an integer 'age' that the specification treats identically for 18 to 65 inclusive. Using equivalence partitioning, which set represents the THREE partitions for valid/invalid handling?
{ age < 18 } , { 18 ≤ age ≤ 65 } , { age > 65 }
Correct — one valid partition and two invalid partitions around it.
{ 17, 18 } , { 65, 66 }
These are boundary values, not the three equivalence partitions.
{ 18 } , { 65 } only
Only two single values; this omits the invalid partitions.
One partition for every integer from 18 to 65.
That defeats the purpose of partitioning into equivalent groups.
Equivalence partitioning yields one valid partition (18–65) and two invalid partitions (below 18 and above 65). One value per partition is enough for basic coverage.
A discount engine assigns a loyalty tier from an integer 'points' value: 0–199 = Bronze, 200–499 = Silver, 500–999 = Gold, 1000 and above = Platinum. Using two-value boundary value analysis (each boundary and its nearest neighbour), which set of values tests ALL boundaries between Bronze and Silver, and between Gold and Platinum?
{ 199, 200, 999, 1000 }
Correct — these are the boundary pairs for Bronze/Silver and Gold/Platinum.
{ 200, 500, 1000 }
Misses the lower neighbours (199 and 999) needed by two-value BVA.
{ 0, 199, 200, 499, 500, 999, 1000 }
Includes the Silver/Gold boundary (499/500) and 0, which are not requested.
{ 100, 350, 750, 1500 }
These are mid-partition values, not boundaries.
Two-value BVA tests each boundary value and its nearest neighbour on the other side. Bronze/Silver boundary is at 199/200; Gold/Platinum boundary is at 999/1000. So {199, 200, 999, 1000}.
Consider the loan application decision table below. An applicant has a credit score of 680 and an annual income of 60,000. According to the table, which action applies?
Manual review
Correct — score < 700 and income ≥ 50,000 matches rule R3.
Approve
Approve requires both conditions true (R1); the score condition is false here.
Reject
Reject (R4) needs both conditions false; income is at least 50,000 here.
Cannot be determined from the table
The inputs map clearly to rule R3, so the action is determined.
Credit score 680 is below 700 (condition 1 = F); income 60,000 is at least 50,000 (condition 2 = T). That is rule R3 (F, T), whose action is Manual review.
The state transition diagram below shows a document review workflow. Counting only the valid transitions shown, what is the minimum number of test cases required to achieve 0-switch (every valid transition at least once) coverage?
5
Correct — there are 5 valid transitions, each needing one test case for 0-switch coverage.
4
This misses one of the five valid transitions (e.g. retract).
3
Three covers only the states, not every valid transition.
6
There are only 5 valid transitions, not 6.
0-switch coverage requires exercising every valid transition once. The valid transitions are: submit, approve, reject, publish, retract = 5 transitions, so 5 test cases.
A function contains the following pseudo-code: IF (a > 0) THEN print 'X' ENDIF; IF (b > 0) THEN print 'Y' ENDIF. What is the minimum number of test cases needed for 100% statement coverage, and for 100% branch (decision) coverage, respectively?
1 for statement coverage, 2 for branch coverage
Correct — one test covers both statements; two tests cover all four branch outcomes.
2 for statement coverage, 2 for branch coverage
Statement coverage needs only 1 test here, not 2.
1 for statement coverage, 4 for branch coverage
Branch coverage needs only 2 tests; the two IFs are independent.
2 for statement coverage, 4 for branch coverage
Both counts are too high for this simple structure.
One test with a>0 and b>0 executes both print statements → 100% statement coverage with 1 test. For branch coverage each IF must be both true and false: a>0,b>0 then a≤0,b≤0 covers all four outcomes → 2 tests.
Which statement BEST characterises the relationship between statement coverage and branch coverage?
100% branch coverage implies 100% statement coverage, but not the reverse.
Correct — branch coverage subsumes statement coverage.
100% statement coverage implies 100% branch coverage.
False — you can execute every statement without taking every branch.
They are always equal in number of test cases.
Branch coverage generally requires at least as many, often more, test cases.
Neither has any relationship to the other.
They are related — branch coverage subsumes statement coverage.
100% branch (decision) coverage guarantees 100% statement coverage, but not vice versa: branch coverage is the stronger criterion.
Which of the following is the BEST description of when to use experience-based test techniques such as exploratory testing and error guessing?
When specifications are poor or time is short, to complement systematic techniques.
Correct — they leverage tester experience where formal coverage is impractical.
Only when full formal coverage measurement is required.
Experience-based techniques do not provide systematic coverage measures.
Only by testers with no domain knowledge.
They depend on the tester's experience and domain knowledge.
As a complete replacement for all black-box techniques.
They complement, not replace, specification-based techniques.
Experience-based techniques are valuable when specifications are sparse, time is limited, or to complement systematic techniques.
Which of the following is a black-box (specification-based) test technique?
Equivalence partitioning
Correct — derived from the specification, a black-box technique.
Statement testing
Statement testing is a white-box technique.
Branch testing
Branch testing is a white-box technique.
Error guessing
Error guessing is an experience-based technique.
Equivalence partitioning derives tests from the specification without reference to internal code structure. Statement and branch testing are white-box.
A web form field accepts a 'username' between 5 and 12 characters inclusive. Using two-value boundary value analysis on the length, which set of length values should be tested?
{ 4, 5, 12, 13 }
Correct — each boundary (5, 12) and its nearest invalid neighbour (4, 13).
{ 5, 12 }
Misses the neighbours just outside the valid range.
{ 1, 5, 12, 20 }
1 and 20 are not nearest neighbours of the boundaries.
{ 6, 11 }
These are inside the valid range, not at the boundaries.
Two-value BVA tests each boundary and its nearest neighbour: 5 with 4; 12 with 13. So {4, 5, 12, 13}.
When deriving test cases from a use case, which kinds of behaviour should test cases cover?
The basic flow plus alternative and exception flows.
Correct — all flows should be covered, not just the happy path.
Only the basic (main success) flow.
Alternative and exception flows must also be tested.
Only the internal code branches of the implementation.
Use-case testing is black-box, based on behaviour.
Only the boundary values of numeric inputs.
That is boundary value analysis, a different technique.
Use-case testing should cover the basic (main success) flow as well as alternative and exception flows.
In risk-based testing, how is the level of a product risk typically determined?
By combining the likelihood of occurrence and the impact if it occurs.
Correct — risk level = likelihood × impact.
Only by the number of defects already found in the area.
Past defects inform likelihood but are not the full definition.
Only by the size of the component in lines of code.
Size may correlate but does not define risk level.
By the number of testers available.
Resourcing affects effort, not the inherent risk level.
Risk level is the combination of the likelihood of the risk occurring and its impact if it does occur.
A test manager estimates a task using the three-point technique. Optimistic = 6 days, most likely = 12 days, pessimistic = 30 days. Using (a + 4m + b) / 6, what is the expected estimate?
14 days
Correct — 84 / 6 = 14.
12 days
12 is the most likely value, not the weighted estimate.
16 days
That is the simple average, not the three-point formula.
18 days
Does not match the formula result of 14.
(6 + 4×12 + 30) / 6 = 84 / 6 = 14 days.
Which of the following BEST describes the purpose of exit criteria (definition of done) for a test activity?
They define the conditions to be met before the activity can be considered complete.
Correct — exit criteria signal when testing is done.
They define the conditions needed before testing can start.
Those are entry criteria.
They list all defects found during testing.
That is the content of defect reports.
They specify the test data to be used.
Test data is defined during design/implementation.
Exit criteria define the conditions that must be met to consider a test activity or level complete.
Which document describes the scope, approach, resources and schedule of the intended test activities for a project, and is the main planning output of a test manager?
The test plan
Correct — it captures scope, approach, resources and schedule.
The test summary report
It describes results after testing, not the plan.
The defect report
It documents an individual defect.
The test case specification
It specifies individual test cases, not the overall plan.
The test plan documents scope, objectives, approach, resources, schedule and risks for the testing of a project or test level.
A defect report is being written. Which information is MOST important to enable a developer to reproduce the problem?
Clear steps to reproduce, with the actual and expected results.
Correct — reproduction steps are key to diagnosing the defect.
The name of the tester who found the defect.
Useful but not essential for reproduction.
The total number of defects found that day.
Unrelated to reproducing this defect.
The expected delivery date of the next release.
Schedule info is not needed to reproduce.
Clear steps to reproduce, with actual and expected results, are essential to recreate and diagnose the defect.
A team must regression test four features. Risk levels (likelihood × impact): Payments = 9, Login = 6, Search = 4, Help pages = 2. There is time to test only two before release. Following risk-based testing, which two should be prioritised?
Payments and Login
Correct — the two highest risk scores (9 and 6).
Search and Help pages
These have the lowest risk scores.
Payments and Help pages
Login (6) outranks Help pages (2).
Login and Search
Payments (9) is the highest risk and must be included.
Risk-based testing prioritises the highest-risk items: Payments (9) and Login (6).
Which of the following is an example of a project risk (rather than a product risk)?
The test environment is not delivered on time.
Correct — a project/management risk.
A calculation in the software produces wrong results.
A product risk (quality).
The application crashes under heavy load.
A product (performance) risk.
Sensitive user data can be accessed without authorisation.
A security product risk.
Project risks relate to management/control of the project, e.g. late delivery of the test environment. Product risks concern product quality.
A test progress report shows execution is significantly behind schedule with many high-priority tests remaining. What is the MOST appropriate test control action?
Reprioritise testing to focus the remaining time on the highest risks.
Correct — control adapts the plan toward the most important tests.
Ignore the report and continue with the original order.
Ignoring deviations defeats test control.
Stop writing defect reports to save time.
Defect reporting is essential.
Mark all remaining tests as passed without running them.
Falsifying results is unethical and dangerous.
Test control takes corrective actions on deviations, e.g. reprioritising tests toward the highest risks in the remaining time.
Which TWO of the following are typically included in a test completion (summary) report? (Choose two.)
A summary of the testing performed and its results.
Correct — a core element.
An evaluation of testing against the exit criteria.
Correct — assesses whether exit criteria were met.
The full source code of the application.
Source code is not part of the report.
The detailed software design specification.
Design specs are inputs, not part of the report.
A completion report includes a summary of testing performed and an evaluation against exit criteria. Source code and detailed design are not part of it.
Which of the following is a potential RISK of introducing a test automation tool into an organisation?
Underestimating the effort required to maintain the automated tests.
Correct — maintenance effort is a known tool risk.
Reducing the effort of repetitive manual regression tasks.
A benefit, not a risk.
Improving the consistency of test execution.
A benefit of automation.
Providing objective coverage measurements.
A benefit, not a risk.
Common risks include underestimating the effort to maintain the tool and over-reliance on it. Benefits like reduced repetitive work are not risks.
Which category of test tool would BEST support managing the testing process, including traceability of requirements, test cases and results?
A test management tool
Correct — manages the process and provides traceability.
A performance testing tool
It measures performance.
A static analysis tool
It analyses code without execution.
A test data preparation tool
It creates test data.
Test management tools support planning, monitoring and control, including traceability between requirements, test cases, runs and defects.