ISTQB Foundation (CTFL v4.0) Mock Exam #13 — 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.
A developer steps through code in a debugger to locate why a calculation returns the wrong total, then changes the faulty line. According to the ISTQB distinction, what is this activity called?
Debugging
Locating, diagnosing and fixing a defect is debugging, a development activity.
Dynamic testing
Dynamic testing executes code to observe failures, not to fix the cause.
Confirmation testing
Confirmation testing re-runs a test after a fix; it does not perform the fix.
Static analysis
Static analysis inspects code without executing it and does not fix defects.
Testing finds failures; debugging finds, analyses and fixes the underlying defect.
A team runs an exhaustive-looking suite every night and the build is always green, yet users keep reporting crashes in production. Which testing principle best explains this situation?
Testing shows the presence, not the absence, of defects
Green tests cannot prove there are no defects; untested conditions can still fail.
Exhaustive testing is impossible
True in general, but the issue here is that passing tests don't guarantee defect-freedom, not the count of combinations.
Tests wear out (pesticide paradox)
That principle is about repeated tests finding fewer new defects over time, not about green builds hiding crashes.
Defects cluster together
Clustering predicts where defects concentrate; it does not explain why passing tests miss production crashes.
Tests passing only show the absence of the failures the tests cover, never the absence of all defects.
During a sprint review the product owner says, 'I have far more confidence releasing now that the regression pack is green.' Which test objective is being served here?
Building confidence about the level of quality
A passing regression suite increases stakeholder confidence in quality — a core objective.
Preventing defects
Defect prevention happens earlier (e.g. reviewing requirements), not by observing a green pack at review.
Finding defects
Here no new defects were found; the statement is about confidence, not detection.
Complying with contractual requirements
No contract or regulation is mentioned; the driver is stakeholder confidence.
Building confidence in the level of quality is a recognised objective of testing alongside finding defects.
A tester types '30/02/2026' into a date field. The field accepts it and the system later miscomputes an invoice date. Identify the error, defect and failure in order.
Error: developer's faulty assumption about validation; defect: missing date-range check in code; failure: wrong invoice date
The human mistake is the error, the resulting flaw in code is the defect, and the observable wrong output is the failure.
Error: wrong invoice date; defect: tester's typo; failure: missing validation
This reverses the chain — the wrong invoice date is the failure, not the error.
Error: missing validation; defect: wrong invoice date; failure: developer's assumption
Missing validation is the defect and the developer's assumption is the error — the roles are swapped.
All three terms describe the same single event
They are distinct, causally linked concepts, not synonyms.
Error (mistake) → defect (fault in code) → failure (observed wrong behaviour) form the causal chain.
Which statement best describes why a whole-team approach with tester independence is valued, despite developers also testing their own code?
Independent testers carry different assumptions and are less subject to author bias
Different perspectives surface defects that authors, anchored in their own mental model, miss.
Independent testers can guarantee defect-free software
No testing can guarantee defect-freedom; independence only improves detection.
Developers should never test their own code
Developers do test their own code; independence complements, not replaces, this.
Independence removes the need for test design techniques
Independence does not replace systematic techniques; both are needed.
Independent testers bring different assumptions and biases, so they tend to find defects authors overlook.
A bank requires that every test activity be traceable to a documented requirement, and an auditor reviews this trace. Which two test objectives are most directly served? (Choose two.)
Complying with contractual, legal or regulatory requirements
Auditable traceability is a classic compliance-driven objective.
Providing information to stakeholders for informed decisions
The trace gives stakeholders evidence about coverage to base release decisions on.
Reducing the cost of cloud hosting
Hosting cost is unrelated to requirement traceability objectives.
Guaranteeing the absence of defects
No objective can guarantee defect absence; traceability does not change that principle.
Traceability to requirements supports both compliance/contractual verification and providing information for decisions.
Which pair correctly matches a typical activity of the test process with its purpose?
Test analysis — determining 'what to test' by identifying test conditions
Test analysis evaluates the test basis to derive test conditions.
Test implementation — deciding overall test objectives and scope
Objectives and scope belong to test planning, not test implementation.
Test completion — executing test cases for the first time
First execution is part of test execution; completion archives assets and reports results.
Test design — monitoring progress against the plan
Monitoring is a control activity; test design creates test cases from conditions.
Test analysis identifies testable features and defines test conditions ('what to test').
Halfway through a test cycle the reports show that only 40% of the planned tests have been run. The test manager therefore reduces the scope of the regression suite and re-prioritises the remaining tests. In ISTQB terms, this decision is an example of:
Test control
Correct — taking corrective action on the basis of monitoring information (re-prioritising, re-scoping, re-allocating effort) is test control.
Test monitoring
Monitoring is the part that produced the 40% figure by collecting and reporting progress data. The decision taken afterwards belongs to control.
Test planning
Planning establishes the objectives, approach and schedule before the cycle starts. Here an existing plan is being steered during execution, which is control.
Test completion
Test completion takes place when the test cycle or project ends: testware is archived, results are reported and lessons learned are captured. Nothing is re-prioritised there.
Test monitoring gathers and reports information about progress; test control uses that information to take corrective actions such as re-prioritising tests or changing the test scope, so that the test objectives can still be met.
A team adopts a shift-left approach. Which concrete action best embodies it?
Testers review user stories and acceptance criteria during refinement, before coding starts
Engaging in reviews before code is written is a textbook shift-left activity.
Adding more manual exploratory testing in the final hardening sprint
Concentrating effort at the end is shift-right in time, the opposite of shift-left.
Monitoring the live system with production logging
Production monitoring is a shift-right practice, valuable but not shift-left.
Delaying all testing until a complete build is available
Waiting for a complete build pushes testing later, contradicting shift-left.
Shift-left means starting test activities earlier, e.g. reviewing requirements and writing tests before code.
On the left side of a V-model, system test cases are designed in parallel with which work product?
The system/software requirements specification
System tests verify the system against its requirements specification, designed alongside it.
The detailed component (unit) design
Component design corresponds to component testing, not system testing.
The business case / feasibility study
A business case precedes requirements and is not the basis for system test design.
The source code
Source code is built on the right-hand descent; system tests are designed earlier from requirements.
In the V-model each test level is designed against its corresponding development level; system tests map to the system/software requirements specification.
A release candidate has passed system testing. Before go-live, real end users in the business department validate that the software supports their daily workflow against business needs. Which test level is this?
Acceptance testing
Validating fitness for use against business needs by users is acceptance testing.
Integration testing
Integration testing checks interfaces between components/systems, not business fitness.
Component testing
Component testing targets isolated units, performed by developers, not business users.
Component integration testing
This still concerns internal interfaces, not user validation of business workflows.
Acceptance testing validates fitness for use and readiness for deployment from the user/business perspective.
After a defect in the payment module is fixed, the team re-runs the exact failing test to verify the fix, then also re-runs neighbouring tests in the checkout flow that previously passed. Name the two test types in that order.
Confirmation testing, then regression testing
Re-running the failed test is confirmation; re-running previously passing neighbours is regression.
Regression testing, then confirmation testing
The order is reversed — you confirm the fix first, then look for regressions.
Smoke testing, then retesting
A smoke test is a broad sanity check, not the targeted re-run of the failed case.
Maintenance testing, then confirmation testing
Maintenance testing is a broader context (changes to a deployed system), not these two specific re-runs.
Confirmation testing verifies the fix; regression testing checks that the change did not break previously working behaviour.
A mobile app has been live for two years. A new OS version is released and a tax-law change requires updated calculations. Which two activities are examples of maintenance testing triggers? (Choose two.)
Upgrading to the new operating system version (operational environment change)
Migration/upgrade of the operating environment is a recognised maintenance-testing trigger.
Modifying the calculation logic for the new tax law
A corrective/adaptive modification to live software triggers maintenance testing.
Writing the very first unit tests during initial development
Initial development tests are not maintenance testing, which applies after deployment.
Choosing the colour scheme of the marketing website
A cosmetic choice on a separate website is not a maintenance-testing trigger for the app.
Maintenance testing is triggered by modifications, migration/upgrade of environment, and retirement; here OS upgrade and a regulatory change both qualify.
Which is an example of a non-functional test type rather than a functional one?
Measuring page response time under 1,000 concurrent users (performance efficiency)
Performance efficiency is a non-functional quality characteristic ('how well').
Checking that a valid login navigates to the dashboard
Verifying what the system does (login outcome) is functional testing.
Verifying the discount is applied to the cart total
Computing the correct discount is a functional behaviour.
Confirming an error message appears for an empty mandatory field
Validating mandatory-field behaviour is functional testing.
Performance, usability, reliability, portability and security are non-functional quality characteristics.
A requirements document is examined in a formal review led by a trained moderator, with defined roles, individual preparation, a logged meeting and metrics collected. Which review type is this?
Inspection
The trained moderator, defined roles, preparation and metrics are hallmarks of an inspection.
Informal review
An informal review has no defined process, roles or metrics — the opposite of this case.
Walkthrough
A walkthrough is author-led and need not collect metrics or use a trained moderator.
Ad hoc desk check
A desk check is an informal, individual check without the formal apparatus described.
An inspection is the most formal review: trained moderator, roles, entry/exit criteria, preparation, and metrics.
Why is static testing of a requirements specification often more cost-effective than waiting for dynamic testing to expose the same problem?
Defects found in requirements are removed before they propagate into design, code and tests
Removing a requirements defect early avoids the multiplied cost of fixing it downstream.
Static testing executes the code faster than dynamic testing
Static testing does not execute code at all, so it cannot 'execute faster'.
Static testing guarantees no defects will reach production
No technique guarantees zero escaped defects.
Static testing makes dynamic testing unnecessary
The two are complementary; static testing cannot find runtime/behavioural failures.
Static testing finds defects early, before they propagate into code and tests, lowering the cost of removal.
Which two anomalies can a requirements review realistically detect that dynamic testing typically cannot? (Choose two.)
An ambiguous requirement that two readers interpret differently
Ambiguity is a documentation defect a review reveals; running code cannot expose it.
A requirement that is missing entirely from the specification
An omission can be spotted by reviewers comparing against needs; dynamic tests only check what exists.
A memory leak that appears only after hours of runtime
A runtime memory leak is a dynamic-only failure, not detectable by a static review.
A timing race condition under heavy concurrent load
A concurrency race manifests only at runtime and is found by dynamic testing.
Reviews can catch ambiguities, contradictions, missing requirements and standards deviations — issues not visible by executing code.
The review process starts with a planning activity. Which of the following is determined during this activity, before the reviewers receive the work product?
The scope and purpose of the review, the review type and roles, the checklists to be used and, for more formal reviews, the entry and exit criteria.
Correct — all of these are settled in review planning, so that the reviewers know what they are looking for and how the review will be judged complete.
The status and severity assigned to each anomaly that was found.
Anomalies do not exist yet at planning time. They are discussed and given a status and severity later, during issue communication and analysis.
The corrections that the author will make to the work product.
Corrections are decided and carried out in the final activity, fixing and reporting, once the anomalies have been accepted.
The individual findings of each reviewer.
Individual findings are produced during the individual review activity, when each reviewer examines the work product on their own.
Review planning defines the scope and purpose of the review, the work product to be reviewed, the quality characteristics to be evaluated, the review type and roles, the checklists to be used, the effort and, for more formal reviews, the entry and exit criteria.
A registration form has an 'age' field that accepts whole numbers. The business rule states: ages 18 to 65 inclusive are accepted; below 18 the application is rejected; above 65 the application is referred for manual review. Using equivalence partitioning on the age field only, what is the minimum number of test cases needed to cover every valid and invalid partition exactly once?
3
One value from each of the three outcome partitions (e.g. 40, 10, 80) gives full partition coverage.
2
Two cases cannot cover three distinct partitions; one partition would be left untested.
4
Four would test one partition redundantly; only three partitions exist for the outcome.
6
Six corresponds to boundary analysis, not minimum partition coverage.
There are three partitions for the outcome (accept 18–65, reject <18, refer >65). EP requires at least one value per partition → 3 test cases.
Reuse the same age field, where the valid range is 18 to 65 inclusive (integers). Applying 2-value boundary value analysis (each boundary plus its nearest neighbour on the invalid side), exactly which set of age values should be tested?
17, 18, 65, 66
Each boundary (18, 65) plus the nearest invalid neighbour (17, 66) — four values.
17, 18, 19, 64, 65, 66
That is 3-value BVA (boundary plus both neighbours), not 2-value.
18, 65
Only the boundaries themselves — the nearest invalid neighbours are missing.
18, 19, 64, 65
These are the boundaries and their valid-side neighbours; 2-value BVA uses the invalid-side neighbour.
2-value BVA tests each boundary and the value immediately outside it: for [18,65] that is 17, 18, 65, 66.
A discount engine grants free shipping when the order subtotal is at least €50 and at most €500 (inclusive). Using 3-value boundary value analysis on the subtotal, how many distinct test values are required to cover both boundaries?
6
Two boundaries × three values each (49/50/51 and 499/500/501) = 6 distinct values.
4
Four is 2-value BVA, not 3-value.
3
Three covers only one boundary; there are two boundaries to test.
8
Eight overcounts; 3-value BVA needs exactly three values per boundary.
3-value BVA tests the boundary and the values just below and just above it: lower 49,50,51 and upper 499,500,501 → 6 values.
Rule R6 → Paid upgrade offer
R6 has Gold=N, Available=Y, Rate>=200=N, mapping to the 'Paid upgrade offer' action.
Rule R5 → Free upgrade
R5 requires Rate>=200=Y, but €180 is below 200, so R5 does not fire.
Rule R2 → Free upgrade
R2 requires Gold=Y; this guest is not a Gold member.
Rule R7 → No upgrade
R7 requires Available=N, but a room is available, so R7 does not match.
Gold=N, Available=Y, Rate €180 means 'Paid rate >= 200?' = N. That matches column R6, whose action is 'Paid upgrade offer'.
4 rules collapse into 1
R3, R4, R7, R8 share Available=N and the same action, so they merge into a single don't-care rule.
2 rules collapse into 1
More than two rules have Available=N; all four qualify, not just two.
3 rules collapse into 1
Four rules (R3, R4, R7, R8), not three, share the don't-care condition.
No rules can be collapsed
Collapsing is valid precisely because four rules give the same action under a don't-care condition.
Rules R3, R4, R7, R8 all have Room available=N and the same action 'No upgrade'; the other conditions are don't-care, so these four rules collapse into one.
Which statement about equivalence partitioning is correct?
All values within one partition are assumed to be processed in the same way, so one representative value can be tested
This is the defining assumption that makes EP reduce the number of tests.
Partitions must always overlap to ensure full coverage
Valid partitions are disjoint; overlapping would break the equivalence assumption.
Equivalence partitioning applies only to invalid inputs
EP applies to both valid and invalid partitions.
It requires testing every possible value in each partition
That would be exhaustive testing, which EP is designed to avoid.
The core assumption of EP is that all members of a partition are processed the same way, so testing one representative stands for the whole partition.
7
There are seven valid transitions, so 0-switch coverage needs seven test cases.
5
Five undercounts — it ignores both 'reject' transitions or the 'decline' transition.
4
Four equals the longest happy path, not the count of all transitions.
8
Eight overcounts; the initial start arrow is not a labelled state transition to be tested separately.
0-switch coverage needs one test per valid transition. The diagram has 7: review, pass(Screening→Interview), pass(Interview→Offer), reject(Screening), reject(Interview), accept, decline.
About 83% (5 of 6 statements)
Line 5 is not executed because b is not greater than 0; the other five run.
100%
Line 5 stays unexecuted, so coverage cannot be complete.
67%
67% would mean only 4 of 6 statements ran, but five execute.
50%
Half would be 3 of 6; five of the six statements actually execute.
With a=5,b=-1 lines 1,2,3,4,6 execute but line 5 (b>0 branch) is skipped: 5 of 6 statements = 83%.
Which two of the following are black-box (specification-based) test techniques? (Choose two.)
Equivalence partitioning
It derives tests from the specification of inputs/outputs, a black-box technique.
Boundary value analysis
BVA is specification-based, focusing on partition edges — black-box.
Statement coverage
Statement coverage measures executed code lines — a white-box technique.
Branch coverage
Branch coverage is based on the code's control flow — white-box, not black-box.
Equivalence partitioning and boundary value analysis are black-box; statement and branch coverage are white-box (structure-based).
A senior tester, with no formal test cases, probes a new feature by drawing on past defect experience and intuition, simultaneously designing and running tests in time-boxed sessions. Which two terms describe what is happening? (Choose two.)
Exploratory testing
Simultaneously designing and executing tests in time-boxed sessions is exploratory testing.
Error guessing
Drawing on experience of likely defects to target tests is error guessing.
Boundary value analysis
BVA is a systematic specification-based technique, not experience-based intuition.
Decision table testing
Decision tables are a structured specification-based technique requiring documented rules.
This is experience-based testing; error guessing and exploratory testing (often session-based) are its two recognised techniques here.
A senior tester lists likely problem areas — empty inputs, very long strings, special characters, simultaneous submissions — based on past experience of similar systems, then designs tests for them. Which test technique is this?
Error guessing.
Correct — anticipating likely defects from experience is error guessing.
Equivalence partitioning.
EP is specification-based, partitioning the input domain, not experience-driven guessing.
Decision table testing.
Decision tables model combinations of specified conditions, not experience-based guesses.
Branch testing.
Branch testing is a white-box technique based on code structure.
Error guessing is an experience-based technique where the tester anticipates likely defects based on knowledge of past failures and common mistakes.
A test plan states: 'Testing will not begin until the integrated build is deployed to the test environment and smoke tests pass.' What is this an example of?
Entry criteria
These are preconditions that must hold before test execution can start.
Exit criteria
Exit criteria define when to stop, not when to begin.
A test objective
An objective is a goal of testing, not a precondition to start.
A test oracle
A test oracle is a source of expected results, unrelated to start conditions.
Conditions that must be met before an activity can start are entry criteria (definition of ready).
A team labels 'the payment gateway provider may go bankrupt mid-project, delaying delivery' as a risk to manage. How should this risk be classified?
Project risk
Supplier and schedule threats affect the project's delivery capability — a project risk.
Product risk
A product risk concerns a quality deficiency in the deliverable itself, not supplier solvency.
A defect
A defect is an existing flaw, while this is a potential future event.
A failure
A failure is observed wrong behaviour at runtime, not a business/supplier threat.
A risk to the project's ability to deliver (schedule, resources, suppliers) is a project risk, not a product (quality) risk.
Which two of the following are product risks (as opposed to project risks)? (Choose two.)
The checkout may calculate VAT incorrectly for certain countries
A potential functional quality defect in the product is a product risk.
The app may respond too slowly under peak load, harming usability
A potential performance/quality shortfall in the deliverable is a product risk.
Two key testers may resign before the release
Staffing/resource threats are project risks, not product quality risks.
The test environment hardware may be delivered late
Late infrastructure delivery is a project (schedule/resource) risk.
Product risks relate to potential quality deficiencies of the deliverable; project risks relate to managing the project.
During execution a test manager tracks the percentage of planned test cases run and the number of open high-severity defects against the plan. What testing activity does this primarily support?
Test monitoring and control
Tracking metrics against the plan to steer the effort is monitoring and control.
Test analysis
Test analysis defines what to test; it is not progress tracking.
Test implementation
Implementation prepares test ware/environments, not metric tracking against the plan.
Test completion
Completion finalises and reports at the end; here tracking happens during execution.
Comparing actual progress against the plan using metrics is test monitoring and control.
A test lead estimates the effort to test a feature using the three-point (PERT) technique. The optimistic estimate is 4 days, the most likely is 10 days, and the pessimistic is 22 days. Using the formula (a + 4m + b) / 6, what is the expected effort?
11 days
(4 + 40 + 22)/6 = 66/6 = 11.
12 days
12 is the simple average of the three values, not the PERT weighted mean.
10 days
10 is the most likely value alone, ignoring the optimistic and pessimistic ends.
13 days
13 does not result from the formula; the correct weighted mean is 11.
(4 + 4×10 + 22) / 6 = (4 + 40 + 22) / 6 = 66 / 6 = 11 days.
Which two items are essential content of a good defect (incident) report? (Choose two.)
Clear steps to reproduce the problem
Reproduction steps let developers reliably recreate and diagnose the defect.
The expected result versus the actual result
Stating expected vs actual pinpoints exactly how behaviour deviates.
The home address of the developer who wrote the code
Personal details of the author are irrelevant and inappropriate in a defect report.
A guaranteed root-cause fix proposed by the tester
Diagnosing the root cause and the fix is debugging, not required content of the report.
A defect report should enable reproduction and assessment: steps to reproduce and the expected vs actual result are core.
Which task is typically the responsibility of a test manager rather than a tester?
Writing and maintaining the test plan and overall test strategy
Planning and strategy are core test-management responsibilities.
Designing test cases from the test conditions
Designing concrete test cases is a tester task.
Executing tests and logging the results
Execution and result logging are tester activities.
Setting up test data for individual test cases
Preparing test data is part of test implementation done by testers.
Test management tasks include planning, organising and leading the test effort; testers analyse, design, implement and execute tests.
An agile team agrees that a story is 'done' only when its acceptance tests pass, code is reviewed, and no high-severity defects remain open. What does this agreement represent?
The definition of done (a form of exit criteria)
It lists the conditions that must be satisfied for the story to be considered complete.
The definition of ready (entry criteria)
Definition of ready governs when work can start, not when it is complete.
A test charter
A test charter scopes an exploratory session, not story completion conditions.
A traceability matrix
A traceability matrix links items to requirements; it is not a completion agreement.
Shared completion conditions for a work item form the definition of done, an agile form of exit criteria.
A test plan defines that system testing may begin only when the build passes a smoke test and component testing is complete with no open critical defects. What are these conditions called?
Entry criteria
Correct — conditions required before testing can start.
Exit criteria
Exit criteria define when an activity is complete.
Test conditions
A test condition is a testable aspect, not a start gate.
Acceptance criteria
Acceptance criteria define when a user story is acceptable.
Conditions that must be met before a test activity can start are entry criteria.
Which is a realistic benefit of using a test execution (automation) tool for a stable regression suite?
Repetitive regression tests can be run more often and consistently, freeing testers for other work
Reliable repeatability and reduced manual effort on stable tests is a core automation benefit.
It removes the need to design test cases or maintain scripts
Automation still requires test design and ongoing script maintenance.
It guarantees the discovery of every defect
No tool can guarantee finding all defects; automation only runs the tests it is given.
It is best suited to one-off, rapidly changing exploratory checks
Automation suits stable, repeated tests; volatile exploratory checks are better done manually.
Automation excels at reliably repeating large volumes of tests, reducing repetitive manual effort for stable cases.
A tool scans source code for coding-standard violations and potential defects without running the program. Into which tool category does it fall?
A static analysis tool
It examines code without execution — the definition of static analysis tooling.
A test execution tool
Test execution tools run the software; this tool does not execute the program.
A performance testing tool
Performance tools measure runtime behaviour under load, which requires execution.
A test management tool
Test management tools organise test assets and reporting, not code analysis.
A tool that analyses code without executing it is a static analysis tool, supporting static testing.