ISTQB Foundation (CTFL v4.0) Mock Exam #1 — 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 of the following best describes the difference between testing and debugging?
Testing identifies failures caused by defects; debugging finds, analyses and removes the defect.
Correct — dynamic testing reveals failures, while debugging is the act of diagnosing and fixing their cause.
Testing and debugging are two names for the same activity.
They are distinct activities with different goals and are often performed by different people.
Debugging proves that the software is free of defects.
No activity can prove the absence of defects; this is a testing principle, and it is not what debugging does.
Testing fixes the defects it finds during execution.
Fixing defects is debugging/development work, not testing.
Testing is concerned with finding failures (evidence of defects); debugging is the development activity that locates, analyses and fixes the underlying defect.
A project manager states: 'We will keep testing until we have run every possible combination of inputs, so the product will be defect-free.' Which testing principle does this statement violate?
Exhaustive testing is impossible.
Correct — testing everything is not feasible, so techniques and risk are used to focus effort.
Tests wear out.
The 'pesticide paradox' is about repeated tests finding fewer new defects, not about exhaustive testing.
Defects cluster together.
This principle is about the uneven distribution of defects, not about the feasibility of complete testing.
Testing is context dependent.
True as a principle, but it is not the one being violated here.
Exhaustive testing (testing all input/precondition combinations) is impossible except for trivial cases; risk and priorities are used instead.
Which TWO of the following are objectives of testing? (Choose two.)
Finding defects and failures.
A primary objective of testing is to detect defects before release.
Building confidence about the level of quality.
Gaining confidence that quality is sufficient is a core objective of testing.
Proving that the software contains no defects.
Impossible — testing can show the presence of defects, not their absence.
Repairing the defects that are found.
Repair is debugging/development, not a testing objective.
Testing both finds defects and builds confidence in the quality level; it cannot prove the absence of defects and fixing is not a testing objective.
A developer mistypes a formula in the source code. The program later produces an incorrect total on screen during a test run. In ISTQB terms, what is the incorrect total on screen?
A failure.
Correct — a failure is the observable incorrect result of executing code that contains a defect.
An error.
The error (mistake) was the human action of mistyping the formula.
A defect.
The defect is the faulty formula in the code, not the wrong total displayed.
A root cause.
The root cause is the underlying reason for the error; the wrong total is the visible failure.
Error (mistake) → Defect (in the code) → Failure (observed wrong behaviour when executed).
During testing of a large system, the team observes that the majority of defects are concentrated in two of the twenty modules. Which testing principle does this illustrate?
Defects cluster together.
Correct — most defects tend to be concentrated in a small number of components.
Testing shows the presence, not the absence, of defects.
True as a principle but it does not describe defect concentration.
Early testing saves time and money.
This is about when to test, not where defects concentrate.
The pesticide paradox.
That principle is about tests losing effectiveness over time, not clustering.
Defects cluster: a small number of modules usually contain most of the defects (related to the Pareto principle).
A product passed all of its tests with no remaining failures, yet after release users complained that the product did not meet their needs. Which testing principle does this situation demonstrate?
The absence-of-errors fallacy.
Correct — a system can be defect-free against its spec yet still fail to meet user needs.
Exhaustive testing is impossible.
Not relevant — the issue is fitness for purpose, not test completeness.
Defects cluster together.
Concerns where defects are located, not user needs.
Testing is context dependent.
True, but it does not describe the gap between passing tests and unmet needs.
The 'absence-of-errors fallacy': finding and fixing defects does not help if the system built does not fulfil users' needs and expectations.
Why is it generally beneficial to involve testing activities as early as possible in the software development lifecycle?
Defects found early are typically cheaper to remove and may be prevented altogether.
Correct — the cost of fixing a defect rises the later it is found.
It guarantees that no defects will reach production.
No approach can guarantee a defect-free release.
It removes the need for any dynamic testing later.
Early (often static) testing complements but does not replace later dynamic testing.
It allows the test team to skip writing a test plan.
Planning is still required regardless of when testing starts.
Early testing (shift-left) detects defects when they are cheaper and easier to fix and helps prevent defects in later work products.
Which of the following is an example of root cause analysis rather than simply recording a failure?
Determining that several defects share a common source in an unclear requirement, and improving the requirements review process.
Correct — this addresses the underlying source to prevent recurrence.
Logging the steps to reproduce a crash in the defect report.
This documents the failure but does not analyse its underlying cause.
Re-running the failed test to confirm the failure.
This is confirmation, not root cause analysis.
Assigning a severity and priority to the defect.
Triage classifies the defect but does not identify its source.
Root cause analysis looks beyond the symptom to the underlying source (e.g., process or knowledge gap) so similar defects can be prevented.
Two independently developed modules are combined, and testing focuses on whether they exchange data correctly through their interface. Which test level is being performed?
Integration testing.
Correct — it targets interfaces and interactions between integrated components.
Component testing.
Component (unit) testing checks a single module in isolation.
System testing.
System testing checks the behaviour of the whole, end-to-end system.
Acceptance testing.
Acceptance testing establishes readiness for use by users/customers.
Integration testing focuses on the interactions and interfaces between components or systems.
A team measures the system's response time under increasing user load. Which test type does this represent?
Non-functional testing.
Correct — response time under load is a performance (non-functional) characteristic.
Functional testing.
Functional testing checks what the system does against functional requirements.
White-box testing.
White-box testing is based on internal structure, not on load/performance per se.
Confirmation testing.
Confirmation testing re-runs tests after a fix to confirm the defect is gone.
Non-functional testing evaluates characteristics such as performance, reliability, usability and security — i.e. how well the system behaves rather than what it does.
A regulator requires evidence that a banking application complies with mandatory legal standards before it can go live. Which form of acceptance testing is this?
Regulatory acceptance testing.
Correct — it provides evidence of compliance with laws/regulations.
Alpha testing.
Alpha testing is simulated/real operational testing by potential users at the developer's site.
User acceptance testing (UAT).
UAT validates fitness for use by end users, not specifically legal compliance.
Operational acceptance testing.
OAT covers operational aspects such as backup/restore and maintenance, not legal compliance.
Regulatory acceptance testing demonstrates compliance with rules set by a regulatory body; contractual acceptance demonstrates compliance with a contract.
Which of the following is a typical benefit that a strong continuous integration (CI) pipeline brings to testing?
Rapid, automated feedback on whether a change has broken existing functionality.
Correct — CI runs automated tests on each change, surfacing regressions early.
It removes the need for any test design.
Tests still have to be designed; CI only automates their execution.
It guarantees 100% test coverage.
CI does not by itself guarantee any particular coverage level.
It eliminates the need for acceptance testing.
Acceptance testing remains necessary to establish readiness for use.
CI enables fast, automated feedback: code changes trigger automated build and tests, so regressions are detected quickly.
Which TWO of the following are recognised test levels in the ISTQB Foundation syllabus? (Choose two.)
System testing.
A recognised test level focusing on the whole system.
Component testing.
A recognised test level focusing on individual components/units.
Regression testing.
Regression testing is a change-related test type, not a test level.
Performance testing.
Performance testing is a non-functional test type, not a test level.
The four test levels are component, integration, system and acceptance testing. Regression and confirmation are change-related test types, not levels.
At the end of each iteration a team holds a meeting to discuss what went well, what went badly and what could be done better, and agrees on concrete actions. What is a recognised benefit of such retrospective meetings for testing?
Process improvements are identified and agreed, for example higher test effectiveness and efficiency or better quality of the testware.
Correct — the value of a retrospective lies in the agreed improvement actions that make the next iteration's testing better.
They replace the need for test monitoring and control during the iteration.
A retrospective looks back after the iteration has finished. Monitoring and control take place while the work is running and are still needed.
They are the meeting in which the anomalies found in a work product are formally logged and classified.
That is part of a review (static testing), where anomalies in a specific work product are discussed and given a status and severity. A retrospective is about the process, not one document.
Their main purpose is to decide whether the product may be released.
That is a release decision based on exit criteria and residual risk. A retrospective produces improvement actions, not a go/no-go verdict.
Retrospectives lead to agreed process improvements, for example increased test effectiveness and efficiency, better quality of the testware, improved teamwork and learning, and better handling of the test basis.
Which of the following is a key characteristic of static testing?
It examines work products without executing the software.
Correct — static testing (reviews, static analysis) does not run the code.
It requires the code to be running on the target environment.
That describes dynamic testing, not static testing.
It can only be applied to source code.
Static testing applies to requirements, designs, user stories and more, not just code.
It can only find failures, not defects.
Static testing finds defects directly; failures require execution.
Static testing examines work products without executing the code (reviews and static analysis), and can be applied very early.
A review follows a documented procedure, uses entry and exit criteria, collects metrics, and is led by a trained moderator. Which review type is this?
Inspection.
Correct — inspections are the most formal review, with metrics, rules and a trained moderator.
Informal review.
Informal reviews have no formal process, roles or documented results.
Walkthrough.
A walkthrough is typically led by the author and is less formal than an inspection.
Ad hoc review.
Ad hoc is an informal, unstructured approach, not the formal one described.
An inspection is the most formal review type, with defined roles, rules, metrics and a moderator.
In a formal review, who is primarily responsible for the work product under review and for fixing the defects found in it?
The author.
Correct — the author created the work product and is responsible for correcting it.
The moderator (facilitator).
The moderator leads the review meeting; they do not own the work product.
The scribe.
The scribe records the issues raised; they do not fix the product.
The review leader / manager.
These roles plan or decide on the review but do not own the work product.
The author owns the work product and fixes the defects; the moderator/facilitator leads the review, the scribe records, and reviewers identify issues.
Which of the following defects is a static analysis tool most likely to detect?
A variable that is used before it has been assigned a value.
Correct — data-flow anomalies like this are typical static analysis findings.
A slow response time when 1,000 users log in at once.
This is a runtime performance issue requiring execution, not static analysis.
A misunderstanding of the customer's actual business need.
This is a requirements/validation problem, not something a static analyser detects in code.
A memory leak that only appears after hours of operation.
This emerges at runtime over time and generally needs dynamic testing.
Static analysis examines code/structure without executing it, detecting things like undefined variables, unreachable code and violations of coding standards.
A field accepts an integer age from 18 to 65 inclusive. Using equivalence partitioning, which set best represents one value from each of the three partitions (one invalid-low, one valid, one invalid-high)?
10, 40, 80
Correct — 10 is invalid-low, 40 is valid, 80 is invalid-high: one value from each partition.
18, 40, 65
All three values fall inside the single valid partition, so two partitions are untested.
17, 18, 19
These probe boundaries (BVA) but cover only the low edge, not all three partitions.
40, 50, 60
All three are in the valid partition; the invalid partitions are not represented.
Equivalence partitioning groups inputs that should be treated the same; one representative per partition is sufficient. Valid: 18-65; invalid below: <18; invalid above: >65.
An input field accepts whole numbers from 1 to 100 inclusive. Using two-value boundary value analysis, which set contains exactly the boundary values that should be tested?
0, 1, 100, 101
Correct — the lower boundary (1) and its outside neighbour (0), plus the upper boundary (100) and its outside neighbour (101).
1, 50, 100
50 is a partition midpoint, not a boundary; the outside neighbours 0 and 101 are missing.
0, 50, 101
Misses the actual boundaries 1 and 100.
1, 2, 99, 100
These are the three-value inner neighbours; two-value BVA uses the outside neighbours 0 and 101.
Two-value BVA tests each boundary and its nearest neighbour just outside the range. For 1-100 that is 0, 1, 100, 101.
Consider the decision table below for a checkout. A customer is NOT a registered customer but places an order with a total of $150. According to the table, which action(s) apply?
Neither free shipping nor a discount is applied (Rule 3).
Correct — Rule 3 has conditions F (not registered) and T (order >= 100) and shows '-' for both actions.
Free shipping and a 5% discount (Rule 1).
Rule 1 requires the customer to be registered (T); this customer is not.
A 5% discount only (Rule 2).
Rule 2 requires registered = T and order < 100; both conditions differ here.
Free shipping only.
Free shipping applies only under Rule 1, which needs a registered customer.
Not registered = F and order >= 100 = T matches Rule 3 (F, T), which triggers neither 'Free shipping' nor '5% discount'.
Using the state transition diagram below, the system is in state S1 (Awaiting PIN). Which sequence of events will move the system to state S3 (Account locked)?
Three consecutive wrong PIN entries.
Correct — the diagram locks the account on the 3rd wrong PIN.
One wrong PIN entry.
A single wrong PIN loops back to S1; it does not lock the account.
A correct PIN entry.
A correct PIN moves to S2 (Access granted), not S3.
Two wrong PIN entries followed by a correct PIN.
After two wrong attempts the system is still at S1; a correct PIN then goes to S2.
From S1, a correct PIN goes to S2; the first two wrong PINs loop back to S1; the third consecutive wrong PIN triggers the transition to S3 (locked).
For the control flow graph below, how many test cases are required to achieve full branch (decision) coverage, assuming each decision is exercised both ways at least once?
2
Correct — two paths can exercise both outcomes of the branch at node 2 and both outcomes of the loop decision at node 5.
1
A single path cannot take both sides of the branch and the loop decision.
4
Branch coverage does not require every combination of decision outcomes, so 4 is more than needed.
6
This overcounts; branch coverage here is achievable with far fewer than six tests.
There are two decisions: the branch at node 2 (to 3 or 4) and the loop decision at node 5 (loop back to 2 or continue to 6). Two well-chosen paths can cover both true/false outcomes of each decision.
In state transition testing, what does achieving '0-switch coverage' (also called Chow's 0-switch) require?
Every valid single transition is exercised at least once.
Correct — 0-switch coverage covers all individual valid transitions.
Every valid pair of consecutive transitions is exercised.
That defines 1-switch coverage, not 0-switch.
Every invalid transition is attempted.
Testing invalid transitions is a separate concern, not what 0-switch coverage measures.
Every state is visited at least once, regardless of transitions.
Visiting states is not sufficient; 0-switch is about covering the transitions themselves.
0-switch coverage requires exercising every valid single transition once; 1-switch coverage requires every valid pair of consecutive transitions.
Which situation is the strongest candidate for using decision table testing?
The output depends on several conditions that can be combined in different ways.
Correct — decision tables systematically capture combinations of conditions and their resulting actions.
A single numeric input must be checked at the edges of its valid range.
That is boundary value analysis, not a decision table.
The system moves between modes depending on events over time.
That points to state transition testing.
There are no requirements, only a running build to explore.
That suggests exploratory testing, an experience-based technique.
Decision tables are ideal when system behaviour depends on combinations of conditions, ensuring important combinations are not overlooked.
Use case testing derives test cases primarily from which of the following?
The basic flow and the alternative/exception flows of user-system interactions.
Correct — use cases describe these flows, which become the basis for test cases.
The internal control flow graph of the code.
That is white-box (structure-based) testing, not use case testing.
The boundaries of each numeric input field.
That describes boundary value analysis.
The tester's intuition about likely defects.
That is error guessing, an experience-based technique.
Use case testing derives tests from the interactions between actors and the system, covering the basic (main) flow and alternative/exception flows.
Which statement correctly describes the relationship between equivalence partitioning and boundary value analysis?
Boundary value analysis builds on equivalence partitioning by testing the edges of the partitions.
Correct — BVA refines EP by targeting the boundaries between partitions.
They are completely unrelated techniques.
They are closely related; BVA extends EP.
Equivalence partitioning is a white-box technique and BVA is black-box.
Both are black-box (specification-based) techniques.
Boundary value analysis replaces the need for equivalence partitioning.
BVA complements EP; both are typically used together.
BVA is an extension of equivalence partitioning that focuses on the boundaries (edges) of the partitions, where defects often occur.
A web form accepts a user's age as an integer. The valid range is 18 to 65 inclusive, and values outside this range must be rejected. Using two-value boundary value analysis (for each boundary, test the boundary value and its nearest neighbour just outside the valid range), which set of age values should be selected to exercise both boundaries?
17, 18, 65 and 66
Tests each boundary (18, 65) and its nearest outside neighbour (17, 66), exactly as two-value BVA requires.
18 and 65
Only the boundary values; it omits the outside neighbours that two-value BVA also requires.
17, 18, 19, 64, 65 and 66
This is three-value BVA, which additionally tests the inside neighbour (19, 64).
0, 18, 65 and 100
0 and 100 are arbitrary values, not the boundary neighbours BVA requires.
Two-value BVA tests each boundary plus the value immediately outside it: lower boundary 18 → 17 and 18; upper boundary 65 → 65 and 66.
For the same routine (a single IF with no ELSE, followed by a final statement), what is the minimum number of test cases required to achieve 100% branch (decision) coverage?
2
One test takes the true branch, the other the false outcome.
1
One test covers only one of the two decision outcomes.
3
Two cases are sufficient for a single binary decision.
4
Over-estimates; only two outcomes exist.
One test for the IF true and one for the IF false outcome = 2.
Which of the following is the best example of an exit criterion (definition of done) for a test level?
All planned tests have been run and no high-severity defects remain open.
Correct — this defines the conditions under which testing may be considered complete.
The test environment is available and test data is prepared.
That is an entry criterion (a precondition for starting), not an exit criterion.
The requirements have been baselined.
Also an entry criterion / precondition, not an exit criterion.
The testers have been assigned to the project.
This is a resourcing/planning matter, not a completion criterion.
Exit criteria define when testing is considered complete enough to stop, e.g., planned coverage achieved and no open high-severity defects.
What is the main purpose of test monitoring and control?
To gather information about test progress and take corrective action where needed.
Correct — monitoring measures progress and control steers it toward the objectives.
To design the detailed test cases.
Test design is a separate test activity, not monitoring and control.
To fix the defects found during testing.
Fixing defects is debugging/development work.
To set up the test environment.
Environment setup is part of test implementation, not monitoring and control.
Test monitoring gathers information on test progress; test control uses that information to take corrective actions to meet the test objectives.
In risk-based testing, the level of risk of an item is usually assessed by considering which two factors?
The likelihood of the problem occurring and its impact if it does.
Correct — risk level = likelihood x impact.
The number of test cases and the number of testers.
These are effort/resource figures, not the definition of risk.
The size of the code and the programming language used.
These may influence effort but do not define the risk level.
The cost of the tools and the test environment.
Costs are budget concerns, not the two factors of risk.
Risk level is a combination of the likelihood (probability) of a problem occurring and the impact (harm) if it does occur.
Which of the following is an example of a project risk (as opposed to a product risk)?
Key testers leave the team before the test phase is complete.
Correct — a staffing/management issue is a project risk.
The payment calculation produces incorrect amounts.
A defect in the product's behaviour is a product risk.
The system is too slow under peak load.
A quality-of-product (performance) concern is a product risk.
The user interface is hard to use.
A usability issue with the product is a product risk.
Project risks relate to managing and executing the project (e.g., staffing, schedule, supplier). Product risks relate to the quality of the product itself.
Which information is essential in a good defect report to help developers reproduce the problem?
Clear steps to reproduce, with the expected and actual results.
Correct — reproduction steps plus expected/actual results are key to diagnosing the defect.
The tester's opinion of the developer who wrote the code.
Defect reports should be objective and factual, not personal.
A guarantee that the defect will be fixed before release.
A report cannot guarantee a fix; that is a triage/management decision.
The total number of test cases in the project.
Project-wide counts do not help reproduce a specific defect.
A useful defect report includes steps to reproduce, expected vs actual results, environment and severity/priority, so the issue can be reproduced and triaged.
A team asks several experienced testers to independently estimate the test effort, then discusses and converges on a consensus estimate over a few rounds. Which estimation approach is this?
An expert-based technique (e.g., Wideband Delphi).
Correct — estimates from experts converged through discussion are expert-based.
A metrics-based technique using historical data.
Metrics-based estimation uses past project data, not expert consensus rounds.
Boundary value analysis.
BVA is a test design technique, not an estimation approach.
Risk-based prioritisation.
Prioritising by risk is not an estimation technique for effort.
This is an expert-based estimation technique; the iterative, anonymous-then-discuss form is known as Wideband Delphi.
Which of the following is a typical metric reported in a test progress (status) report?
Number of test cases run, passed, failed and blocked.
Correct — execution status is a standard test progress metric.
The personal salaries of the development team.
Salaries are not a test progress metric.
The brand of laptops used by the testers.
Irrelevant to test progress reporting.
The marketing budget for the product launch.
A business/marketing figure, not a test metric.
Test progress reports commonly include test case execution status (passed/failed/blocked), defect counts and trends, and coverage achieved.
During test estimation a team uses the three-point (PERT) technique. For a test activity they assess optimistic = 4 days, most likely = 9 days, and pessimistic = 20 days. Using the formula E = (O + 4M + P) / 6, what is the estimated effort?
10 days
(4 + 36 + 20) / 6 = 60 / 6 = 10.
9 days
9 is the most likely value, not the weighted PERT estimate.
11 days
11 is the simple average (4+9+20)/3, not the PERT weighted mean.
12 days
Does not match the formula; the correct weighted estimate is 10.
E = (4 + 4×9 + 20) / 6 = (4 + 36 + 20) / 6 = 60 / 6 = 10 days.
Four product risks are rated 1-5: R1 L=2 I=3; R2 L=4 I=5; R3 L=3 I=3; R4 L=5 I=2. If risk level = Likelihood x Impact, which should be tested FIRST?
R2 (risk level 20)
4*5 = 20 is the highest of the four.
R4 (risk level 10)
5*2 = 10 is lower than R2's 20.
R3 (risk level 9)
3*3 = 9 is lower than R2's 20.
R1 (risk level 6)
2*3 = 6 is the lowest.
R2 has the highest product (20).
A tool that records defects, links them to requirements and tracks their status through the lifecycle belongs to which category?
Test management / defect management tools.
Correct — tracking defects and traceability is a test management tool function.
Performance testing tools.
Performance tools generate load and measure response, not defect tracking.
Static analysis tools.
Static analysis examines code without executing it; it does not manage defects.
Test data preparation tools.
These create or mask test data, not track defects.
Test management tools (including defect/incident management) support the management of testing, traceability and reporting.
Which of the following is a realistic risk of introducing test automation, rather than a benefit?
The effort to maintain the automated tests can be underestimated.
Correct — maintenance of automated scripts is a common, often underestimated cost/risk.
Automated regression tests can be run more often and consistently.
This is a benefit of automation, not a risk.
Repetitive tests can be executed faster than by hand.
This is a benefit, not a risk.
Objective, repeatable results are produced for the same inputs.
Repeatability is a benefit of automation, not a risk.
Automation has costs and risks: maintenance effort can be underestimated, over-reliance on the tool, and unrealistic expectations. Benefits include repeatability and faster regression runs.