ISTQB Foundation (CTFL v4.0) Mock Exam #15 — 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 is a typical objective of testing?
Evaluating work products and finding defects
Finding defects and evaluating quality is a core objective of testing.
Proving that the software contains no defects
Exhaustive proof of no defects is impossible; testing can only show defects are present.
Fixing the defects found during execution
Fixing defects is debugging, a development activity, not a testing objective.
Guaranteeing the system is fit for every possible use
Testing reduces risk but cannot guarantee fitness for all uses.
Testing has several objectives, including finding defects, building confidence in the quality level, and providing information for decision-making. Proving the absence of defects is impossible.
A team runs the same automated regression suite unchanged for months and finds almost no new defects. Which testing principle best explains this?
The pesticide paradox
Repeated identical tests lose their ability to find new defects over time.
Tests show the presence of defects, not their absence
True as a principle, but it does not explain why repetition stops finding defects.
Defects cluster together
Defect clustering concerns where defects concentrate, not the effect of repeating tests.
Early testing saves time and money
This principle is about test timing, not about repeated tests losing effectiveness.
The pesticide paradox states that repeating the same tests stops finding new defects; tests must be reviewed and revised.
A developer mistypes a formula in a spreadsheet. The wrong formula stays in the code, and when the report is generated it shows an incorrect total. Match error, defect and failure in order.
Mistyping = error; wrong formula in code = defect; incorrect total = failure
This is the correct causal chain: error → defect → failure.
Mistyping = defect; wrong formula = failure; incorrect total = error
The order is wrong; a mistake by a person is an error, not a defect.
Mistyping = failure; wrong formula = error; incorrect total = defect
Incorrect; the observable wrong output is the failure, not the mistake.
All three are the same thing described differently
Error, defect and failure are distinct concepts with a causal relationship.
A human mistake (error) introduces a defect in the code, which when executed produces a failure (observable wrong behaviour).
Which statement about the difference between testing and debugging is correct?
Testing can trigger failures; debugging finds and fixes the underlying defects
This correctly separates the two activities and who typically performs them.
Testing and debugging are two names for the same activity
They are distinct activities with different goals.
Debugging always precedes testing
Testing typically reveals failures first; debugging follows to fix defects.
Only testers debug, never developers
Debugging is typically performed by developers, not testers.
Testing can trigger failures caused by defects; debugging is the development activity of finding, analysing and fixing those defects.
During a review of the requirements, the team checks 'Are we building the product right?' according to the specification. Which activity is this?
Verification
Checking conformance to the specification is verification.
Validation
Validation asks whether the right product is built for real needs, not conformance to spec.
Debugging
Debugging is fixing defects, unrelated to this check.
Retesting
Retesting confirms a fix; it is not about conformance to specification.
Verification checks whether a work product meets its specification; validation checks whether it meets the users' actual needs.
Why is root cause analysis of defects valuable?
It supports process improvement to prevent similar defects
Identifying the source enables preventive action, reducing future defects.
It guarantees the current defect will never reappear
Analysis reduces recurrence risk but cannot guarantee it.
It replaces the need for test execution
Root cause analysis complements, it does not replace, test execution.
It assigns blame to the responsible developer
The goal is improvement, not blame.
Analysing the underlying cause of defects supports process improvement to prevent similar defects in the future.
Which TWO are examples of the mindset and skills a good tester should have?
Curiosity and attention to detail
These help testers notice anomalies and design thorough tests.
Good communication and critical thinking
Testers must report findings clearly and question assumptions.
Authority to approve project budgets
Budget approval is a management responsibility, not a tester skill.
Always writing the production code under test
Writing production code is a development task, not a defining tester skill.
Testers benefit from curiosity, attention to detail, good communication and critical thinking. Writing production code and approving budgets are not testing skills.
The ISTQB test process is described as a set of activities, but in practice these activities are not carried out strictly one after the other. Which TWO statements correctly describe how they relate in practice? (Choose two.)
Activities may overlap, run in parallel or be repeated — for example test design for later features continues while earlier tests are already being executed.
Correct — the process is not strictly sequential; iteration and overlap are normal, especially in iterative and incremental lifecycles.
Test monitoring and control accompanies the other activities continuously, instead of occupying a fixed position between two of them.
Correct — monitoring and control runs throughout the test effort, feeding information back and adjusting the other activities as needed.
Test planning is performed once at the start of the project and is never revisited afterwards.
Plans are updated as monitoring and control reveals deviations or as risks and priorities change; planning is revisited throughout the project.
Test analysis must be fully finished for the whole system before any test design may start.
This describes a rigid sequence that the syllabus does not require. Analysis and design commonly proceed feature by feature, with design starting as soon as the relevant test conditions exist.
The test activities may overlap, run in parallel and be iterated, and test monitoring and control is a continuous activity that accompanies the whole test effort rather than occupying a single slot in a sequence.
In a sequential (V-model) lifecycle, when should test analysis and design for the system test level ideally begin?
As soon as the system requirements are available
Test design can start against the requirements, in parallel with development.
Only after all code has been written
Waiting until code is complete contradicts the early-testing principle.
Only after component testing has fully passed
System test design need not wait for component testing to finish.
During the maintenance phase
That is far too late; design should align with the requirements phase.
In the V-model, test activities for each level begin as soon as the corresponding basis (e.g. system requirements) is available, in parallel with development — an application of early testing.
A team introduces static analysis and unit tests during coding and reviews requirements before development starts. Which approach are they applying?
A shift-left approach
Moving test activities earlier is exactly the shift-left idea.
A shift-right approach
Shift-right emphasises testing in production/operation, not earlier activities.
Big-bang integration
That is an integration strategy, unrelated to timing of test activities.
Exploratory testing
Exploratory testing is an experience-based technique, not a lifecycle timing choice.
'Shift left' means performing testing activities earlier in the lifecycle, such as reviewing requirements and testing during coding.
Tests are executed to verify that interfaces and interactions between integrated modules work correctly, before the whole system is tested. Which test level is this?
Integration testing
It specifically targets interfaces and interactions between modules.
Component testing
Component testing checks modules in isolation, not their interactions.
Acceptance testing
Acceptance testing validates readiness for use, typically by users, later in the process.
Regression testing
Regression testing is a test type re-run after changes, not a level about interfaces.
Integration testing focuses on interactions between components or systems; it sits between component and system testing.
A tester measures response time under load and checks the system stays within an agreed threshold. Which test type is this?
Non-functional testing
Performance/response time is a non-functional quality characteristic.
Functional testing
Functional testing checks what the system does, not how well it performs.
White-box testing
White-box testing derives tests from internal structure, not measured against a performance threshold.
Confirmation testing
Confirmation testing re-runs a test after a fix; it is not about performance.
Non-functional testing evaluates characteristics such as performance efficiency, usability and reliability. Response time under load is performance (non-functional).
A bank deploys a security patch to a live payment system that has been in production for years. What kind of testing is primarily triggered?
Maintenance testing
Changes to an operational system trigger maintenance testing with impact analysis.
Component testing
Component testing targets new modules in isolation, not changes to a live system.
Acceptance testing only
Acceptance may occur, but the driver here is a change to an operational system.
No testing is needed for a patch
Patches to live systems require testing to manage regression risk.
Maintenance testing is triggered by modifications to a system in operation, such as patches, upgrades or migrations, and includes impact analysis and regression testing.
After a defect is fixed, the team wants to (a) confirm the fix works and (b) ensure nothing else broke. Which TWO statements correctly describe confirmation and regression testing?
Confirmation testing re-runs the previously failed test after the fix
Confirmation testing verifies the specific defect is resolved.
Regression testing checks that unchanged parts still work after the change
Regression testing detects unintended side effects of changes.
Confirmation testing measures performance under peak load
That describes performance testing, not confirmation testing.
Regression testing is only ever done manually
Regression testing is a strong candidate for automation and is not manual-only.
Confirmation (re-)testing re-executes the failed test after the fix; regression testing checks that unchanged areas still work after the change.
What is a key benefit of static testing compared with dynamic testing?
Defects can be found earlier, before code is executed
Static testing catches defects in early work products, reducing later cost.
It measures actual runtime performance
Runtime behaviour requires dynamic testing, not static testing.
It removes the need for any dynamic testing
Static and dynamic testing are complementary, not substitutes.
It can only be applied to source code
Static testing applies to many work products, including requirements and designs.
Static testing examines work products without executing code, so it can find defects (e.g. in requirements) earlier and cheaper than dynamic testing.
A formal review is led by a trained moderator, uses defined roles and entry/exit criteria, collects metrics, and follows a documented process. Which review type is this?
Inspection
Inspection is the most formal review type with a moderator, roles and metrics.
Informal review
An informal review has no defined process, roles or metrics.
Walkthrough
A walkthrough is led by the author and is less formal than an inspection.
Ad-hoc pair review
This is informal and lacks the defined roles and metrics of an inspection.
An inspection is the most formal review type: led by a trained moderator/facilitator, with defined roles, rules, checklists, metrics and formal exit criteria.
In a formal review, who is primarily responsible for the work product being reviewed and for fixing the identified defects?
The author
The author owns the work product and corrects the defects found.
The moderator/facilitator
The moderator runs the review process; they do not own or fix the work product.
The scribe/recorder
The scribe documents findings but is not responsible for the work product.
The management representative
Management may sponsor the review but is not responsible for fixing the work product.
The author is responsible for the work product under review and for correcting the defects found.
A very large requirements specification is reviewed repeatedly, but the reviews find little and the reviewers complain about fatigue and lack of preparation time. Which TWO measures address recognised success factors for reviews? (Choose two.)
Split the specification into small chunks so that reviewers do not lose their concentration during individual review.
Correct — keeping the reviewed portions small is an explicit success factor, because reviewer effectiveness drops sharply once concentration is lost.
Have management allocate adequate time in the schedule for review preparation and follow-up.
Correct — management support, including sufficient time for preparation and for acting on the findings, is one of the organisational success factors for reviews.
Report the number of anomalies found in each document in the author's individual performance appraisal.
This turns reviews into personal evaluation and destroys the trust they depend on. Anomalies must be raised objectively about the work product, never used to judge the person who wrote it.
Drop the reviews and rely on additional dynamic testing of the finished product instead.
Dynamic testing cannot examine a requirements document at all, and problems such as ambiguities or contradictions would then surface much later and cost far more to fix.
Recognised success factors include splitting large work products into small chunks so reviewers keep their concentration, and management support that provides adequate time in the schedule for preparation and follow-up. Reviews must also stay objective and never be used to evaluate people.
Which statement best describes equivalence partitioning (EP)?
Data is divided into groups expected to be handled the same way, testing one value per group
This is the definition of equivalence partitioning.
Every possible input value must be tested individually
That is exhaustive testing, which EP explicitly avoids.
Only values at the edges of ranges are tested
Testing edges is boundary value analysis, not equivalence partitioning.
Tests are derived from the code's control flow
Deriving from control flow is a white-box technique, not EP.
EP divides input (or output) data into partitions expected to be processed the same way; one value per partition is representative, reducing the number of test cases.
A field 'age' accepts integers. The rules are: 0–17 = 'minor', 18–64 = 'adult', 65 and above = 'senior', and any value below 0 is invalid. Using equivalence partitioning, what is the MINIMUM number of test cases to cover every partition exactly once?
4
Four partitions (invalid, minor, adult, senior) require four test cases.
3
This misses the invalid (<0) partition.
6
There are only four partitions, not six.
8
Eight would over-count; EP needs one value per partition.
Partitions: invalid (<0), minor (0–17), adult (18–64), senior (≥65). That is 4 partitions, so a minimum of 4 test cases, one per partition.
A numeric input accepts values from 1 to 100 inclusive. Using 2-value boundary value analysis, which set of values tests the boundaries of the valid range?
0, 1, 100, 101
These are the two boundary pairs for the range 1..100 in 2-value BVA.
1, 50, 100
50 is a mid-partition value, not a boundary; the neighbours 0 and 101 are missing.
0, 1, 2, 99, 100, 101
This mixes in 3-value BVA neighbours (2 and 99) not needed for 2-value BVA.
1, 100
This omits the neighbouring invalid values 0 and 101 needed by 2-value BVA.
2-value BVA uses the boundary and its nearest neighbour on the other side. For 1..100 the boundary pairs are {0,1} at the lower bound and {100,101} at the upper bound.
A temperature field accepts 10 to 30 inclusive. Using 3-value boundary value analysis, how many distinct boundary values are tested across both the lower and upper boundaries?
6
Lower {9,10,11} and upper {29,30,31} give six distinct values.
4
Four values corresponds to 2-value BVA, not 3-value.
3
Three covers only one boundary; both boundaries are needed.
8
Eight over-counts; each boundary contributes three values, totalling six.
3-value BVA tests each boundary plus the value on each side. Lower: 9,10,11. Upper: 29,30,31. That is 6 distinct values.
R5 — 25%
Member=N, Tuesday=Y, Senior=Y matches R5, giving 25%.
R1 — 40%
R1 requires the customer to also be a loyalty member (Member=Y).
R6 — 20%
R6 requires senior=N; here the customer is a senior.
R7 — 10%
R7 requires Tuesday=N; here the showing is on a Tuesday.
Member = N, Tuesday = Y, Senior = Y. That combination is rule R5, which gives a 25% discount.
The cinema decision table has three independent binary conditions (member?, Tuesday?, senior?) and no combinations are infeasible. How many rule columns are required for full decision-table coverage?
8
2^3 = 8 combinations of three binary conditions.
6
Six understates the count; three binary conditions give eight combinations.
3
Three is the number of conditions, not the number of rules.
16
16 = 2^4 would require four conditions, not three.
With three independent binary conditions and no infeasible combinations, full coverage needs 2^3 = 8 rules, matching R1–R8.
start → pause → resume → submit → grade
Every transition in this sequence exists in the state machine.
start → grade → submit
grade is only valid from Submitted, so it cannot follow start directly.
pause → start → submit
pause is not valid from NotStarted; the session must start first.
start → submit → resume
resume is only valid from Paused, not from Submitted.
Valid transitions: start (NotStarted→InProgress), pause (InProgress→Paused), resume (Paused→InProgress), submit (InProgress→Submitted), grade (Submitted→Graded). The sequence start, pause, resume, submit, grade follows all of them.
5
There are exactly five valid transitions to cover once each.
4
Four misses one transition; there are five in total.
6
There are only five valid transitions, not six.
5 states means 5, but including invalid transitions gives more
0-switch coverage counts valid transitions only, which is five.
0-switch (single transition) coverage requires exercising every valid transition once. The machine has 5 transitions (start, pause, resume, submit, grade), so 5 test cases.
Which technique derives test cases from sequences of interactions between an actor and the system to test end-to-end business flows?
Use case testing
It derives tests from actor-system interaction sequences.
Statement testing
Statement testing is a white-box technique based on code, not interactions.
Boundary value analysis
BVA targets range boundaries of individual inputs, not interaction flows.
Decision table testing
Decision tables model combinations of conditions, not actor interaction sequences.
Use case testing derives tests from use cases, describing interactions between actors and the system, and is effective for end-to-end and integration scenarios.
Which TWO of the following are experience-based test techniques?
Error guessing
Error guessing uses the tester's experience of likely defects.
Exploratory testing
Exploratory testing relies on the tester learning and designing tests concurrently.
Equivalence partitioning
EP is a black-box, specification-based technique, not experience-based.
Decision table testing
Decision table testing is specification-based, derived from condition combinations.
Experience-based techniques rely on the tester's knowledge and intuition. Error guessing and exploratory testing are experience-based; equivalence partitioning and decision table testing are black-box (specification-based).
Which TWO of the following are black-box (specification-based) test techniques? (Select TWO.)
Boundary value analysis.
Correct — BVA is a specification-based (black-box) technique.
State transition testing.
Correct — it derives tests from a behavioural specification (state model).
Statement testing.
Statement testing is a white-box technique based on code.
Branch testing.
Branch testing is a white-box technique based on the control flow.
Error guessing.
Error guessing is an experience-based technique, not specification-based.
Black-box techniques include equivalence partitioning, boundary value analysis, decision table testing and state transition testing. Statement and branch testing are white-box; error guessing is experience-based.
A tester estimates a task using three-point (PERT) estimation with optimistic = 5 days, most likely = 8 days, and pessimistic = 17 days. What is the estimated effort using the formula (a + 4m + b) / 6?
9 days
(5 + 32 + 17)/6 = 54/6 = 9.
10 days
10 would ignore the 4× weighting of the most likely value.
8 days
8 is just the most likely value, not the PERT weighted mean.
11 days
11 is a simple average of 5, 8, 17 (30/3=10) or miscalculation; the correct PERT value is 9.
(5 + 4×8 + 17) / 6 = (5 + 32 + 17) / 6 = 54 / 6 = 9 days.
Which two factors determine the level of a product risk?
The likelihood of occurrence and the impact if it occurs
Risk level = likelihood × impact.
The number of testers and the test budget
These are resourcing factors, not the definition of risk level.
The programming language and the IDE used
Tooling choices do not define product risk level.
The number of test cases and their length
Test case counts do not determine risk level.
Risk level is determined by the likelihood of the risk occurring and the impact (harm) if it does occur.
Which of the following is a common test progress metric used in test monitoring?
Percentage of planned test cases executed
This is a standard test progress metric.
The number of lines of comments in the code
Comment count is not a test progress metric.
The salary of the test team
Salary is not a progress metric.
The office temperature during testing
This is irrelevant to test progress.
Test monitoring uses metrics such as the percentage of planned test cases executed, pass/fail rates, and defect discovery/closure trends to track progress against the plan.
A team defines a rule that system testing may only begin once the build is deployed to the test environment and all critical component defects are fixed. What is this an example of?
Entry criteria
These are preconditions that must hold before testing can start.
Exit criteria
Exit criteria define when testing can stop, not when it may start.
A test charter
A test charter guides an exploratory session, not entry preconditions.
A defect report
A defect report documents a specific failure, not activity preconditions.
Entry criteria (definition of ready) are the preconditions that must be met before a given test activity can begin.
Which TWO items are typically documented in a test plan?
Test scope and objectives
Scope and objectives are core content of a test plan.
Entry and exit criteria
Entry/exit criteria are standard elements of a test plan.
The full source code of the application
Source code is not documented inside a test plan.
The exact code diff of each bug fix
Code diffs belong in version control, not the test plan.
A test plan typically documents the test scope/objectives, approach, schedule, resources, and entry/exit criteria. The source code and individual bug fixes are not part of the test plan.
What is the main purpose of configuration management in the context of testing?
To identify and control versions of testware and software items so tests are reproducible
This is exactly what configuration management provides.
To write the production source code
Writing code is a development task, not configuration management.
To prioritise risks by likelihood and impact
That is risk analysis, a separate management activity.
To guarantee zero defects in the release
No activity can guarantee zero defects.
Configuration management establishes and maintains the integrity of work products (test cases, testware, software items) by uniquely identifying and version-controlling them, so tests are traceable and reproducible.
Which TWO pieces of information should a well-written defect report contain?
Steps to reproduce the failure
Reproduction steps let developers confirm and locate the defect.
Expected result versus actual result
Comparing expected and actual clarifies why the behaviour is a defect.
The name of the developer to blame
Defect reports should be objective, not assign blame.
A binding deadline by which the fix must be delivered
Scheduling fixes is a management decision, not part of the defect report itself.
A good defect report includes steps to reproduce, expected vs actual results, severity/priority, and environment. It should not contain blame or a mandated fix time.
A test manager estimates effort by analysing measured data from previous similar projects (e.g. historical defect and productivity figures). Which estimation approach is this?
Metrics-based estimation
It uses measured data from previous projects.
Expert-based estimation
Expert-based estimation relies on judgement, not measured historical data.
Boundary value analysis
BVA is a test design technique, not an estimation approach.
Exploratory estimation
This is not a recognised estimation technique in the syllabus.
Metrics-based estimation uses data from past projects; expert-based estimation relies on the judgement of experienced people.
Which of the following BEST describes the role of configuration management in supporting testing?
It identifies and version-controls test items and test ware so testing is reproducible.
Correct — CM underpins reproducible, controlled testing.
It designs the test cases automatically.
CM does not design test cases.
It guarantees that the software has no defects.
CM cannot guarantee the absence of defects.
It approves the project budget.
Budget approval is a management function.
Configuration management ensures test items and test ware are identified, version-controlled and tracked, so testing is reproducible.
A team uses a tool that captures and replays user interactions and compares actual results against expected results automatically. Which category of test tool is this?
Test execution (capture/playback) tool
It automates running tests and comparing results.
Static analysis tool
Static analysis examines code without executing it, unlike this tool.
Requirements management tool
That manages requirements, not automated test execution.
Performance testing tool
Performance tools generate load and measure timing, not capture/replay of UI interactions with result comparison.
Test execution tools (including capture/playback) run tests automatically and compare actual to expected results, supporting regression testing.
Which TWO are potential risks or costs of introducing test automation?
Ongoing maintenance effort as the application changes
Automated scripts must be updated when the system under test changes.
Initial investment in tooling and skills
Tools, setup and training represent significant upfront cost.
It guarantees that all defects will be found
No approach can guarantee finding all defects.
It removes the need to design test cases
Automation executes tests; it does not replace test analysis and design.
Automation brings maintenance overhead for test scripts and requires initial investment/skills. It does not remove the need for test design, nor does it guarantee finding all defects.