ISTQB Foundation (CTFL v4.0) Mock Exam #2 — 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 set of regression tests has been run unchanged for many releases and now rarely finds new defects. Which testing principle explains this?
The pesticide paradox.
Correct — unchanged tests become less effective at finding new defects over time.
Exhaustive testing is impossible.
This is about the infeasibility of testing everything, not declining effectiveness of repeated tests.
Defects cluster together.
Describes uneven defect distribution, not the fading value of repeated tests.
Testing is context dependent.
True, but unrelated to repeated tests losing effectiveness.
The pesticide paradox: repeating the same tests stops finding new defects; tests must be reviewed and updated, and new tests added.
Safety-critical medical software is tested far more rigorously than a simple internal marketing website. Which testing principle does this illustrate?
Testing is context dependent.
Correct — the amount and type of testing depend on the context and risk.
The absence-of-errors fallacy.
That concerns building the wrong product, not adapting rigour to context.
Early testing saves time and money.
Concerns timing of testing, not contextual rigour.
Exhaustive testing is impossible.
Concerns the infeasibility of complete testing, not contextual adaptation.
Testing is context dependent: the testing performed depends on factors such as risk, domain and criticality.
A tester runs many tests on a module and finds no failures. What can be correctly concluded?
The module may still contain defects that these tests did not reveal.
Correct — passing tests do not prove the absence of defects.
The module is now proven to be defect-free.
No amount of testing can prove the absence of defects.
Further testing of this module is pointless.
Additional tests, especially new ones, can still find defects.
The requirements must have been perfect.
Test results say nothing about the correctness of the requirements.
Testing can show the presence of defects but never prove their absence; passing tests reduce risk but do not guarantee a defect-free module.
Which TWO of the following statements correctly use the ISTQB terms error, defect and failure? (Choose two.)
A human error can lead to a defect being introduced in the code.
Correct — a mistake (error) can result in a defect in a work product.
A failure occurs when a defect in the code is executed.
Correct — failures are the observable effect of executing a defect.
A failure in the code always causes a human error.
The causal chain runs error → defect → failure, not the reverse.
Every defect in the code will always cause a failure.
A defect causes a failure only if the affected code is executed under the right conditions.
An error (mistake) by a person can introduce a defect (fault) in a work product; executing the defect can cause a failure (observable wrong behaviour).
Which question is answered by validation, as opposed to verification?
Are we building the right product for the users' needs?
Correct — validation checks fitness for the intended use and user needs.
Does the product conform to its written specification?
That is verification, not validation.
Does the code follow the coding standards?
Conformance to standards is a verification concern.
Has each module been built according to its design?
Conformance to design is verification.
Verification asks 'are we building the product right?' (conforms to specification). Validation asks 'are we building the right product?' (meets users' needs).
Which of the following best describes the 'test basis'?
The source of information from which test cases are derived.
Correct — the test basis (requirements, designs, etc.) is what tests are derived from.
The hardware on which the tests are executed.
That is the test environment, not the test basis.
The set of expected results for the tests.
Expected results come from the test basis but are not the basis itself.
The list of defects found so far.
Defect data is an output of testing, not the test basis.
The test basis is the body of knowledge used as the basis for test analysis and design (e.g., requirements, design, user stories, risk analysis).
What is a recognised benefit of having an appropriate degree of independence in testing?
Independent testers are likely to recognise different kinds of failures than the author would.
Correct — independence brings a different perspective and reduces author bias.
Independent testers can guarantee a defect-free product.
No degree of independence can guarantee the absence of defects.
Independence removes the need for the author to test at all.
Authors still benefit from testing their own work; independence complements it.
Maximum independence is always the best choice.
Too much independence can cause communication problems and is not always best.
Independent testers tend to recognise different kinds of failures and are less affected by the author's assumptions, though too much independence can hurt communication.
How do quality assurance (QA) and testing differ?
QA focuses on the process to achieve quality, while testing is a quality-control activity focused on work products.
Correct — QA is process-oriented (prevention); testing is product-oriented quality control.
QA and testing are exactly the same thing.
They are related but distinct; QA is broader and process-focused.
Testing is process-oriented while QA only examines the product.
This reverses the correct definitions.
QA is performed only after release, testing only before.
Both can span the lifecycle; the distinction is process vs product focus.
QA is process-oriented and aims to ensure appropriate levels of quality across the whole process; testing is one quality-control activity focused on the product/work products.
A developer writes automated tests that check a single function in isolation, using stubs to replace its dependencies. Which test level is this?
Component (unit) testing.
Correct — testing a single component in isolation with stubs is component testing.
System testing.
System testing exercises the whole integrated system, not a single function in isolation.
Acceptance testing.
Acceptance testing establishes readiness for use by users/customers.
Integration testing.
Integration testing checks interactions between components, not a component in isolation.
Component (unit) testing verifies individual components in isolation, often using stubs/drivers to stand in for dependencies.
After a defect is fixed, the team re-runs a broad set of previously passing tests to ensure the change has not introduced new defects elsewhere. Which test type is this?
Regression testing.
Correct — re-running tests to detect unintended side effects of a change is regression testing.
Confirmation testing.
Confirmation testing re-runs the specific failed test to verify the fix, not a broad set.
Smoke testing.
Smoke testing is a shallow check that the build is stable enough to test further.
Acceptance testing.
Acceptance testing establishes readiness for use, not side effects of a fix.
Regression testing checks that a change has not adversely affected unchanged parts. Confirmation (re-)testing checks that the specific defect is actually fixed.
Which of the following best describes a 'shift-left' approach to testing?
Performing testing activities earlier in the lifecycle, such as reviewing requirements and designing tests before code is written.
Correct — shift-left moves testing effort earlier to detect defects sooner.
Delaying all testing until just before release.
That is the opposite of shift-left.
Moving all testing to a separate independent team.
Shift-left is about timing, not organisational independence.
Replacing manual testing entirely with automation.
Shift-left concerns when testing happens, not manual vs automated.
Shift-left means performing testing activities earlier in the lifecycle (e.g., reviewing requirements, writing tests before code) to find defects sooner.
Which of the following typically triggers maintenance testing?
A change such as a patch, enhancement, or migration to a new environment for a live system.
Correct — modifications and migrations of an operational system trigger maintenance testing.
The very first development of a brand-new system.
Initial development is not maintenance; maintenance applies to existing operational systems.
Writing the original requirements specification.
This is an early development activity, not maintenance testing.
Designing the very first set of unit tests.
This is part of initial development, not maintenance.
Maintenance testing is performed on an operational system due to modifications, migration, or retirement of the software.
In an iterative-incremental lifecycle (e.g., Agile), how does testing typically differ from a sequential (e.g., V-model) lifecycle?
Testing occurs continuously within each short iteration, with frequent regression testing.
Correct — iterative approaches integrate testing throughout each iteration.
Testing is only performed once, at the very end of the project.
This is closer to a poorly run sequential model and not characteristic of iterative development.
No regression testing is ever needed.
Frequent changes make regression testing more important, not less.
Test levels and test types no longer apply.
Test levels and types still apply; only their timing and cadence change.
In iterative-incremental development, testing happens continuously within short iterations, with frequent regression testing, rather than mostly after a long development phase.
In one test-first approach, testers, developers and business representatives jointly turn the acceptance criteria of a user story into tests before the story is implemented, and those tests then guide the development work. Which approach is this?
Acceptance test-driven development (ATDD)
Correct — ATDD starts from the acceptance criteria agreed with stakeholders and turns them into tests before implementation begins.
Test-driven development (TDD)
TDD is also test-first, but it is developer-centred: unit tests for a small piece of code are written first and code is then written to make them pass. It does not start from stakeholder acceptance criteria.
Behaviour-driven development (BDD)
BDD is a closely related test-first approach, but its defining feature is expressing the desired behaviour in a structured natural-language format (given/when/then) that can be automated directly, rather than deriving tests from the acceptance criteria as such.
Regression testing
Regression testing is change-related testing performed after code exists, to detect unintended side effects. It is not a test-first development approach at all.
Acceptance test-driven development (ATDD) derives tests collaboratively from acceptance criteria before implementation. TDD is developer-centred and starts from unit tests; BDD expresses the desired behaviour in a structured given/when/then notation.
In which review type does the author typically lead the session, step through the work product, and gather feedback, often to build a shared understanding?
Walkthrough.
Correct — walkthroughs are typically led by the author to step through and gather feedback.
Inspection.
Inspections are led by a trained moderator, not the author, and are the most formal review.
Audit.
An audit assesses compliance with standards/regulations, not an author-led walkthrough.
Static analysis.
Static analysis is tool-based examination of code, not a review meeting.
A walkthrough is usually led by the author and is used to find defects, share knowledge and build consensus; it is less formal than an inspection.
Which sequence correctly orders activities of a formal review?
Planning, initiate review, individual review, communication and analysis, fixing and reporting.
Correct — this is the standard order of formal review activities.
Fixing, planning, individual review, reporting, initiate review.
Fixing cannot precede planning and review; the order is wrong.
Individual review, planning, fixing, initiate review, communication.
Planning and initiation must come before individual review.
Communication, fixing, planning, individual review, initiate review.
Planning must come first; this ordering is incorrect.
A formal review follows: planning, initiate review (kick-off), individual review (preparation), issue communication and analysis (review meeting), and fixing/reporting.
Which TWO of the following are recognised review types? (Choose two.)
Technical review.
A recognised, typically peer/expert-based review type.
Inspection.
The most formal recognised review type.
Compilation.
Compilation translates code; it is not a review type.
Unit testing.
Unit testing is dynamic testing, not a static review type.
Recognised review types include informal review, walkthrough, technical review and inspection. 'Compilation' and 'unit testing' are not review types.
Which of the following is a success factor for reviews?
Defects found are welcomed and expressed objectively, in a blame-free atmosphere.
Correct — a constructive, no-blame culture is a key review success factor.
The review is used to evaluate the author's performance.
Using reviews to judge people undermines them; reviews target the work product.
The largest possible document is reviewed in a single session.
Reviewing too much at once reduces effectiveness; sessions should be appropriately sized.
Only the author attends, to save time.
Reviews need appropriate reviewers; the author alone defeats the purpose.
Successful reviews have clear objectives, the right people involved, a constructive (no-blame) atmosphere, and defects are seen as opportunities to improve.
For the same routine (one IF with no ELSE followed by a statement), what is the minimum number of test cases for 100% branch (decision) coverage?
2
One test makes the decision true, the other false.
1
One test covers only one outcome of the decision.
3
Two outcomes need only two cases.
5
Matches statement count, not branch coverage.
One test for IF true and one for IF false = 2.
Using the media player state transition diagram below, the player is currently in state S2 (Playing). Which of the following events is NOT accepted (has no defined transition) in this state?
play
Correct — there is no transition for 'play' from the Playing state in the diagram.
pause
'pause' is a defined transition from Playing to Paused.
stop
'stop' is a defined transition from Playing to Stopped.
Both pause and stop are undefined.
Both are defined transitions from Playing, so this is incorrect.
From S2 (Playing) the diagram defines 'pause' (to S3) and 'stop' (to S1). There is no transition for 'play' from S2, so 'play' is not accepted in the Playing state.
For the control flow graph below, what is the cyclomatic complexity? (Use V(G) = Edges − Nodes + 2.)
2
Correct — 7 edges − 7 nodes + 2 = 2; there is one decision point (node 2).
1
A single decision yields V(G) = 2, not 1; 1 would mean no decisions.
3
There is only one decision node, so the value is 2, not 3.
7
7 is the number of edges, not the cyclomatic complexity.
The graph has 7 nodes and 7 edges (1-2, 2-3, 2-4, 4-5, 3-6, 5-6, 6-7). V(G) = 7 − 7 + 2 = 2, consistent with a single decision at node 2.
Consider the insurance decision table below. A driver is 30 years old and has made a claim in the last year. According to the table, which action applies?
Apply a surcharge (rule R3).
Correct — R3 has conditions F (not under 25) and T (claim made) and triggers the surcharge.
Offer a no-claims bonus (rule R4).
R4 requires no claims in the last year (F); this driver made a claim (T).
No action applies.
R3 explicitly applies a surcharge for this combination.
Apply a surcharge and offer a bonus.
These actions are mutually exclusive across the rules; only the surcharge applies under R3.
Age under 25 = F and claims in last year = T matches rule R3 (F, T), whose action is 'Apply surcharge'.
A field accepts whole numbers from 10 to 20 inclusive. Using three-value boundary value analysis, which values should be tested around the lower boundary of 10?
9, 10, 11
Correct — three-value BVA tests the boundary (10) and its immediate neighbours (9 and 11).
10, 11, 12
This omits the value just below the boundary (9).
8, 9, 10
This omits 11 and includes a value (8) not adjacent to the boundary.
9, 11
Three-value BVA must also include the boundary value 10 itself.
Three-value BVA tests the boundary and the values on each side of it. For the lower boundary 10, that is 9, 10 and 11.
A web form's 'country' field accepts one of 195 valid country names; anything else is rejected. Using equivalence partitioning, how many partitions are most appropriate to identify at minimum?
Two: one valid partition and one invalid partition.
Correct — accepted countries form one partition and everything rejected forms another.
195: one partition per valid country.
Each valid country is handled the same way, so they belong to a single valid partition.
One: only valid inputs need testing.
Invalid inputs form their own partition and must also be tested.
196: one per valid country plus one invalid.
Valid countries do not each need their own partition under EP.
EP groups inputs that are handled the same way. Here there is one valid partition (any accepted country) and one invalid partition (anything not accepted) = two partitions.
Why is it valuable to design test cases for invalid (unexpected) transitions in state transition testing?
To verify the system correctly handles events that are not allowed in the current state.
Correct — invalid-transition tests check robust handling of disallowed events.
To reduce the total number of states in the model.
Testing transitions does not change the number of states in the model.
Because valid transitions never contain defects.
Valid transitions can also contain defects and must be tested too.
To achieve 100% statement coverage automatically.
State transition testing is black-box and does not by itself guarantee statement coverage.
Testing invalid transitions checks that the system correctly rejects or handles events that should not be allowed in the current state, a common source of defects.
A decision table has three independent Boolean conditions. Before any simplification, how many distinct rules (columns) does the full table contain?
8
Correct — 2^3 = 8 combinations of three Boolean conditions.
6
2^3 is 8, not 6 (this confuses multiplication with exponentiation).
3
3 is the number of conditions, not the number of rules.
9
9 is 3 squared; the number of combinations is 2 to the power of 3 = 8.
For n independent Boolean conditions, the full table has 2^n rules. For 3 conditions that is 2^3 = 8.
Which statement about statement and branch (decision) coverage is correct?
100% branch coverage guarantees 100% statement coverage, but not vice versa.
Correct — branch coverage subsumes statement coverage.
100% statement coverage guarantees 100% branch coverage.
Statement coverage can be 100% while some branches (e.g., an empty else) are untaken.
The two coverage measures are always equal.
They can differ; branch coverage is generally harder to achieve.
Neither measure has any relationship to the other.
They are related: branch coverage subsumes statement coverage.
Achieving 100% branch coverage guarantees 100% statement coverage, but not the other way round; branch coverage is the stronger criterion.
A tester uses a high-level list of areas, rules and conditions to check, derived from experience, to guide testing without prescribing exact steps. Which technique is this?
Checklist-based testing.
Correct — using an experience-derived checklist to guide testing is checklist-based testing.
Boundary value analysis.
BVA targets the edges of input ranges, not a checklist of areas.
Decision table testing.
Decision tables capture combinations of conditions, not experience-based checklists.
Statement testing.
Statement testing is a white-box coverage technique.
Checklist-based testing uses a checklist of items to cover, based on experience and knowledge of what is important; it is an experience-based technique.
An input field accepts a discount percentage as an integer from 1 to 100 inclusive. Using three-value boundary value analysis (for each boundary, test the boundary value, the value just below it, and the value just above it), how many distinct test values are required, assuming none overlap?
6
Three values per boundary times two boundaries = six distinct values.
4
4 is two-value BVA (two values per boundary), not three-value.
2
2 covers only the boundary values themselves.
8
Overcounts; three-value BVA needs three values per boundary, not four.
Lower boundary 1 → 0, 1, 2; upper boundary 100 → 99, 100, 101. That is six distinct values.
Which of the following is the best example of an entry criterion for system testing?
A stable build is deployed to a configured, available test environment.
Correct — this is a precondition (entry criterion) for starting system testing.
All planned system tests have passed.
That is an exit criterion, describing completion, not entry.
No high-severity defects remain open.
Also an exit criterion, not an entry condition.
The test summary report has been signed off.
Sign-off happens at the end, so this is not an entry criterion.
Entry criteria are the preconditions that must be met before testing can meaningfully start, such as a stable build deployed in a ready test environment.
The 'test pyramid' model generally suggests which distribution of automated tests?
Many low-level (unit/component) tests, fewer integration tests, and few end-to-end UI tests.
Correct — the pyramid favours a broad base of fast low-level tests.
Mostly end-to-end UI tests, with very few unit tests.
That is the inverted 'ice-cream cone' anti-pattern, not the pyramid.
An equal number of tests at every level.
The pyramid deliberately has more tests at lower levels.
Only manual tests at all levels.
The pyramid is about distribution of automated tests across levels.
The test pyramid suggests many fast, low-level tests (e.g., unit/component), fewer integration/API tests, and relatively few slow, high-level end-to-end UI tests.
How does risk-based testing typically use the assessed level of risk?
Higher-risk items receive more and earlier testing than lower-risk items.
Correct — effort is allocated in proportion to risk.
Every item receives exactly the same amount of testing regardless of risk.
That ignores risk and is not risk-based testing.
Lower-risk items are always tested first.
Risk-based testing prioritises higher-risk items, not lower-risk ones.
Risk levels are used only after release, never during testing.
Risk is used to plan and steer testing throughout, not only after release.
Risk-based testing prioritises and allocates more, earlier and deeper testing to higher-risk items, and less effort to lower-risk items.
What is the role of configuration management in support of testing?
It uniquely identifies and version-controls test items and testware so tests run against known versions.
Correct — CM maintains the integrity and traceability of items and testware.
It writes the detailed test cases for each requirement.
Test design produces test cases; CM manages versions and integrity.
It decides which defects will be fixed.
Defect triage decides fixes; CM controls versions and configurations.
It estimates the effort needed for testing.
Estimation is a planning activity, not configuration management.
Configuration management ensures that testware and the items under test are identified, version-controlled and traceable, so tests are run against known versions.
What is the difference between the severity and the priority of a defect?
Severity is the impact on the system; priority is how urgently it should be fixed.
Correct — severity is about impact, priority is about urgency, and they can differ.
Severity and priority always have the same value.
A high-severity defect can be low priority and vice versa.
Priority is the technical impact; severity is the business urgency.
This reverses the definitions.
Both terms refer only to how reproducible the defect is.
Reproducibility is a separate attribute from severity and priority.
Severity reflects the impact of the defect on the system; priority reflects how urgently it should be fixed from a business perspective. They are independent.
Which of the following tasks is typically the responsibility of a test manager rather than a tester?
Developing and reviewing the test plan and overall test strategy.
Correct — planning and strategy are test management responsibilities.
Designing and implementing individual test cases.
This is typically a tester's task.
Executing tests and logging the results.
Execution and logging are typically performed by testers.
Setting up test data for a specific test case.
Preparing test data is usually a tester's task.
The test manager plans, monitors and controls the test activities (strategy, planning, reporting), while testers design, implement and execute tests.
A team estimates test effort by analysing the effort spent on testing in several previous, similar projects. Which estimation approach is this?
A metrics-based estimation technique.
Correct — using historical data from similar projects is metrics-based estimation.
An expert-based estimation technique.
Expert-based estimation relies on the judgement of experts, not historical metrics.
Boundary value analysis.
BVA is a test design technique, not an estimation approach.
Exploratory testing.
Exploratory testing is a test technique, not an estimation method.
Metrics-based estimation uses data from previous or similar projects (e.g., past effort, defect rates) to forecast the effort needed.
Which TWO of the following are commonly used as test monitoring metrics? (Choose two.)
Percentage of planned test cases executed.
A standard measure of test progress.
Number of defects found, grouped by severity.
Defect metrics are a core part of test monitoring.
Number of words in the marketing brochure.
Not a test metric.
The office temperature during testing.
Irrelevant to test monitoring.
Test monitoring uses metrics such as test case execution progress, defect information (counts, density, trends) and coverage achieved. Lines of marketing copy and team morale ratings are not standard test metrics.
A test manager applies the three-point (PERT) estimation technique to a task with optimistic = 2 days, most likely = 5 days, and pessimistic = 14 days. Using E = (O + 4M + P) / 6, what is the estimate?
6 days
(2 + 20 + 14) / 6 = 36 / 6 = 6.
5 days
5 is the most likely value, not the weighted PERT estimate.
7 days
7 is the simple average (2+5+14)/3, not the PERT weighted mean.
8 days
Does not match the formula; the correct weighted estimate is 6.
E = (2 + 4×5 + 14) / 6 = (2 + 20 + 14) / 6 = 36 / 6 = 6 days.
A tool that runs predefined automated scripts against the application and compares actual results to expected results belongs to which category?
Test execution tools.
Correct — running automated scripts and comparing results is the role of test execution tools.
Static analysis tools.
Static analysis examines code without executing it.
Requirements management tools.
These manage requirements and traceability, not test execution.
Test data preparation tools.
These generate or mask test data; they do not execute tests.
Test execution tools run automated tests against the system under test and compare actual to expected results, supporting regression testing.
Why is it good practice to run a pilot project before rolling out a new test tool across the whole organisation?
To assess how well the tool fits existing processes and to learn how to use it effectively before wider adoption.
Correct — a pilot reduces risk by evaluating fit and building know-how first.
To guarantee that the tool will eliminate all manual testing.
Tools support testing but do not eliminate the need for manual testing.
To prove the tool can find every defect in the system.
No tool can find every defect; a pilot does not claim this.
Because tools never require any maintenance once installed.
Tools and their scripts require ongoing maintenance.
A pilot evaluates how the tool fits the organisation's processes and infrastructure, decides on usage standards, and assesses costs and benefits before a full rollout.