ISTQB Foundation (CTFL v4.0) Mock Exam #4 — 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 why testing is necessary?
It reduces the risk of failures occurring during operation.
Correct — a key reason testing is necessary.
It guarantees the software contains no defects.
Testing cannot prove the absence of defects.
It replaces the need for requirements analysis.
Testing complements, not replaces, requirements work.
It makes debugging unnecessary.
Debugging is still needed to fix defects testing reveals.
Testing reduces the risk of failures in operation and helps determine whether quality is acceptable; it cannot guarantee defect-free software.
A tester strongly believes a feature works and only designs tests that confirm it. Which cognitive bias does this MOST clearly relate to?
Confirmation bias — favouring information that confirms existing beliefs.
Correct — the bias the human-factors principle warns about.
The pesticide paradox.
That concerns repeated tests losing effectiveness.
Defect clustering.
That concerns where defects concentrate.
Absence-of-errors fallacy.
That is about a defect-free system still being unfit for use.
This is confirmation bias: testers may unconsciously favour evidence that confirms expectations rather than seeking failures.
A system passed all tests and has very few defects, yet users reject it because it does not meet their needs. Which testing principle does this BEST illustrate?
Absence-of-errors fallacy.
Correct — a low-defect system can still fail to meet user needs.
Tests show the presence of defects.
True as a principle but not what this scenario illustrates.
Exhaustive testing is impossible.
Not the point here; the system was tested adequately.
Testing is context dependent.
A valid principle, but it does not describe this situation.
The 'absence-of-errors fallacy': finding and fixing defects does not help if the system does not meet users' needs.
Put these test process activities in the correct logical order: 1) test design, 2) test analysis, 3) test implementation, 4) test execution.
Analysis → Design → Implementation → Execution
Correct — the logical order.
Design → Analysis → Execution → Implementation
Analysis precedes design; implementation precedes execution.
Implementation → Analysis → Design → Execution
Analysis and design come before implementation.
Execution → Implementation → Design → Analysis
This is the reverse of the correct order.
Analysis (what to test) → design (how) → implementation (prepare environment/test ware) → execution.
Which of the following is a test condition rather than a test case?
"Validation of login with an invalid password"
Correct — a testable aspect without specific data.
Input user 'amy', password 'x', expect 'invalid credentials'.
Has inputs and expected result — a test case.
Enter 'amy'/'secret123' and expect the dashboard to load.
Specific data and result make this a test case.
Enter a 13-character password and expect rejection.
Specific value and result — a test case.
A test condition is a testable aspect (what to test). A test case adds specific inputs, preconditions and expected results.
Which TWO of the following are typically part of the test analysis activity? (Choose two.)
Identifying test conditions by analysing the test basis.
Correct — a core part of test analysis.
Detecting defects in the test basis, such as ambiguities.
Correct — analysis often uncovers test-basis defects.
Executing the test cases and logging results.
That is test execution.
Setting up the test environment and tools.
That belongs to test implementation.
Test analysis identifies test conditions and can detect defects in the test basis (e.g. ambiguities).
Why is whole-team responsibility for quality important in many modern (e.g. Agile) contexts?
It enables earlier defect prevention and detection across the team.
Correct — shared responsibility supports early quality.
It removes the need for any testing skills in the team.
Testing skills are still needed.
It means only developers are responsible for quality.
Whole-team means everyone shares it.
It guarantees zero defects in the delivered product.
No approach can guarantee zero defects.
When the whole team shares responsibility, defects are prevented and detected earlier rather than handed to a separate test team at the end.
In the ISTQB test process, one activity defines the objectives of testing and selects the approach that best meets those objectives within the given constraints, and its main output is the test plan. Which activity is this?
Test planning
Correct — test planning is the activity that sets the test objectives and chooses the approach and resources needed to reach them; the test plan is its output.
Test monitoring and control
This activity compares actual progress against the plan and triggers corrective action. It consumes the plan rather than creating it.
Test analysis
Test analysis derives test conditions from the test basis, i.e. it decides what to test. It does not define the overall test objectives or select the approach.
Test implementation
Test implementation creates and organises the testware needed for execution (test procedures, test suites, test data, environment). It comes after the approach has already been chosen.
Test planning defines test objectives and selects the approach (techniques, levels, entry/exit criteria, resources, schedule) that best achieves them within the project constraints. Its main testware output is the test plan.
Which of the following BEST characterises test-first approaches such as Test-Driven Development (TDD)?
Tests are written before the code, which is then written to pass them.
Correct — the defining characteristic of TDD.
Tests are written only after the system is fully complete.
That is the opposite of test-first.
No automated tests are used at all.
TDD relies heavily on automated unit tests.
Only acceptance tests are written, never unit tests.
TDD is primarily about unit-level tests.
In TDD, tests are written before the code; the code is then developed to make the tests pass.
Customer representatives test whether the delivered system supports their real business processes before go-live. Which form of acceptance testing is this?
User acceptance testing (UAT)
Correct — users validate against their real needs and processes.
Component integration testing
That checks interfaces between components.
Component testing
Component testing is at the lowest level, by developers.
Regression testing
Regression checks side effects after changes.
User acceptance testing validates that the system supports the users' real business processes and needs.
Which is the BEST example of a non-functional test addressing the quality characteristic 'reliability'?
Running the system continuously for 72 hours to check it does not fail or degrade.
Correct — endurance testing addresses reliability over time.
Checking that a transfer moves the correct amount of money.
A functional test, not reliability.
Measuring how quickly the page renders for one user.
Performance efficiency, not reliability.
Checking the UI labels are translated into French.
Localisation/usability, not reliability.
Reliability concerns the system continuing to function correctly over time, e.g. running for a long period without failure.
In a sequential (V-model) lifecycle, with which development phase is the design of system tests BEST associated?
The system requirements specification phase.
Correct — system tests verify the system requirements.
The detailed (component) design phase.
That pairs with component testing.
The coding phase.
Coding pairs with component testing.
The business requirements / contract phase.
That pairs with acceptance testing.
In the V-model, system test design is based on the system requirements specification, pairing it with the requirements phase.
Which testing type determines the compliance of a component or system with regulations, standards or contractual requirements?
Compliance (conformance) testing
Correct — verifies adherence to standards/regulations/contracts.
Smoke testing
Smoke testing checks basic build stability.
Usability testing
Usability addresses ease of use.
Confirmation testing
Verifies that a fix resolved a defect.
Compliance (conformance) testing checks adherence to laws, standards or contractual requirements.
Shortly before go-live, the operations team checks backup and restore, the disaster recovery procedure, user administration and the installation and uninstallation scripts in a production-like environment. Which form of acceptance testing is this?
Operational acceptance testing
Correct — these are exactly the operational tasks that OAT covers, and they are performed by the operations or system administration staff.
User acceptance testing
User acceptance testing is performed by business users and validates that the system supports their business processes and fitness for purpose, not the backup, recovery and administration procedures.
Alpha testing
Alpha testing is done by potential or existing users at the developing organisation's site. The distinguishing factor there is who tests and where, not the operational nature of the tasks.
Regulatory acceptance testing
Regulatory acceptance testing demonstrates compliance with laws, regulations and standards the system must satisfy. Backup, recovery and user administration are operational concerns, not regulatory evidence.
Operational acceptance testing (OAT) is performed by operations or system administration staff and covers tasks such as backup/restore, disaster recovery, user management, installation and maintenance of the system in its operational environment.
During which step of the review process do reviewers individually examine the work product to identify possible defects before the review meeting?
Individual review (individual preparation)
Correct — reviewers examine the product individually first.
Planning
Planning defines scope and participants.
Fixing and reporting
Occurs after issues are communicated.
Review initiation
Initiation distributes the work product.
The 'individual review' step is where reviewers examine the work product on their own and note potential defects.
Which review type is BEST when the main objective is to reach consensus among stakeholders on a document, led by the author who guides participants through it?
Walkthrough
Correct — author-led, aimed at understanding and consensus.
Inspection
Inspection is led by a trained moderator and is the most formal type.
Informal review
No defined structure for guided consensus.
Audit
An audit checks compliance against standards.
A walkthrough is led by the author who guides participants through the work product, often to gain understanding and consensus.
Which of the following is a typical work product that can be examined by static testing?
A requirements specification document.
Correct — documents are typical static-testing work products.
The measured response time under load.
A dynamic-testing result requiring execution.
The CPU usage during a stress test.
Runtime metrics require dynamic testing.
The actual crash log produced when the app fails.
A crash log comes from executing the system.
Static testing can examine requirements, design, code, test plans, user stories and contracts — anything readable and reviewable.
What is the MAIN distinction between a defect found by static testing and a failure found by dynamic testing?
Static testing finds defects directly; dynamic testing observes failures caused by defects.
Correct — static finds the defect, dynamic sees the symptom.
Static testing always finds more defects than dynamic testing.
Neither is universally superior; they are complementary.
Dynamic testing requires no test cases.
Dynamic testing uses test cases to execute the system.
Static testing executes the code in a controlled way.
Static testing does not execute the code.
Static testing finds defects directly in the work product without execution; dynamic testing observes failures caused by defects during execution.
Which TWO of the following are black-box (specification-based) test techniques? (Choose two.)
Decision table testing.
A specification-based (black-box) technique for combinations of conditions.
State transition testing.
A specification-based (black-box) technique based on states and transitions.
Statement testing.
Statement testing is white-box (structure-based).
Branch testing.
Branch testing is white-box (structure-based).
Black-box techniques include equivalence partitioning, boundary value analysis, decision tables, state transition and use case testing. Statement and branch testing are white-box.
For the ATM state machine below, how many test cases are required to achieve 0-switch coverage, i.e. to cover every valid single transition exactly once? (Count the self-transition 'wrong PIN (<3)' as one transition.)
9
Idle->AwaitPIN, AwaitPIN->Menu, AwaitPIN self-loop, AwaitPIN->Locked, Menu->Dispensing, Dispensing->Menu, Menu->CardReturned, CardReturned->Idle, Locked->Idle.
6
Undercounts; there are nine distinct transitions.
8
Misses one transition, e.g. the self-loop.
5
Far too few for 0-switch coverage here.
There are nine valid transitions, so 0-switch coverage needs nine test cases.
The thermostat state transition diagram below shows the valid transitions. Which of the following sequences of events is INVALID according to the diagram, starting from S1 (Off)?
turn on, then temp >= set
Correct — after 'turn on' the system is Idle; 'temp >= set' is only valid from Heating.
turn on, then temp < set, then temp >= set
Valid: Off→Idle→Heating→Idle.
turn on, then turn off
Valid: Off→Idle→Off.
turn on, then temp < set, then turn off
Valid: Off→Idle→Heating→Off.
From S1 (Off) the only valid event is 'turn on' to S2 (Idle). There is no transition from Off to Heating, so 'turn on' then 'temp >= set' (valid only from Heating) is invalid.
For the control flow graph below, a loop body (node 3 → node 4) may execute zero or more times before exiting. What is the minimum number of test cases required for 100% branch (decision) coverage of the single decision at node 2?
2
Correct — one test entering the loop and one skipping it cover both outcomes.
1
One test covers all statements but not both branch outcomes.
3
There is only one decision, so two outcomes suffice.
4
Too many; one decision needs only 2 tests.
The single decision at node 2 has two outcomes: enter the loop (true) and exit (false). Branch coverage requires both — one test entering the loop and one skipping it — so 2 test cases.
What is the MAIN purpose of collapsing (simplifying) a decision table by removing or merging redundant columns?
To reduce the number of test cases while keeping coverage of distinct outcomes.
Correct — merging don't-care columns reduces rules without losing coverage.
To add more conditions so coverage is increased.
Collapsing reduces, it does not add conditions.
To convert the decision table into a state transition diagram.
Different techniques; collapsing does not convert formats.
To guarantee 100% branch coverage of the code.
Decision tables are black-box; they don't guarantee code branch coverage.
Collapsing merges columns where some conditions do not affect the outcome (don't-care), reducing test cases while preserving coverage of distinct combinations.
A shipping cost depends on two conditions: 'Member' (yes/no) and 'Order >= $50' (yes/no). The behaviour differs for each of the four combinations. Using decision table testing for full coverage of all rules, what is the minimum number of test cases?
4
Correct — 2 × 2 = 4 distinct combinations, all with different behaviour.
2
Two tests cannot cover all four combinations.
3
Three leave one combination untested.
8
8 would be 2^3; here there are only two conditions.
Two binary conditions give 2 × 2 = 4 distinct combinations; since all four differ, none merge — 4 test cases.
Which white-box coverage criterion is satisfied when every executable statement in the code has been exercised at least once?
Statement coverage
Correct — it measures executable statements exercised.
Branch coverage
Branch coverage requires each decision outcome, a stronger criterion.
Path coverage
Path coverage requires all independent paths.
Equivalence partition coverage
A black-box criterion, not white-box.
Statement coverage measures the percentage of executable statements exercised; 100% means every statement ran at least once.
An online quiz grades a percentage score (integer 0–100): 0–39 = Fail, 40–69 = Pass, 70–100 = Distinction. Using equivalence partitioning, which set picks exactly ONE representative from EACH valid output partition?
{ 20, 55, 85 }
Correct — one value inside each of Fail, Pass and Distinction.
{ 39, 40, 69, 70 }
These are boundary values, and do not pick one per partition.
{ 10, 25, 35 }
All three fall in the Fail partition.
{ 55, 60, 65 }
All three fall in the Pass partition.
Three valid output partitions: Fail (0–39), Pass (40–69), Distinction (70–100). One representative each, e.g. {20, 55, 85}.
When is state transition testing the MOST appropriate technique to apply?
When the system's behaviour depends on its current state and the events it receives.
Correct — the technique models states, events and transitions.
When inputs are independent numeric ranges with no memory of past events.
That suits equivalence partitioning/BVA.
When the goal is to measure code statement coverage.
That is a white-box objective.
Only when there is no specification available.
It relies on a model derived from the specification.
It suits systems whose behaviour depends on current state and history, where events trigger transitions between states.
Which TWO of the following are white-box (structure-based) test techniques? (Choose two.)
Statement testing
Correct — based on code structure (white-box).
Branch testing
Correct — based on code decisions (white-box).
Equivalence partitioning
A black-box technique.
Use case testing
A black-box technique based on use cases.
Statement testing and branch testing derive tests from code structure. Equivalence partitioning and use-case testing are black-box.
A traffic light cycles through states Red → Green → Amber → Red, with one valid transition between each pair (Red→Green, Green→Amber, Amber→Red). How many test cases are needed for 0-switch (single transition) coverage?
3
Correct — three valid transitions, one test case each.
1
One test cannot exercise all three transitions.
6
6 relates to 1-switch (pairs), not 0-switch.
9
Far more than the three valid transitions.
0-switch coverage requires each valid single transition once. There are three valid transitions, so 3 test cases.
Four product risks are rated 1-5: R1 L=5 I=5; R2 L=2 I=4; R3 L=4 I=3; R4 L=3 I=5. If risk level = Likelihood x Impact, which should be tested FIRST?
R1 (risk level 25)
5*5 = 25 is the highest of the four.
R4 (risk level 15)
3*5 = 15 is lower than R1's 25.
R3 (risk level 12)
4*3 = 12 is lower than R1's 25.
R2 (risk level 8)
2*4 = 8 is the lowest.
R1 has the highest product (25).
Which of the following BEST describes the difference between test monitoring and test control?
Monitoring gathers information; control takes corrective actions based on it.
Correct — control acts on what monitoring reveals.
Monitoring fixes defects; control writes test cases.
Neither describes monitoring or control correctly.
They are the same activity with different names.
They are distinct, though closely related.
Control gathers metrics; monitoring approves the budget.
The roles are reversed and budget approval is not monitoring.
Monitoring gathers information about testing; control uses that information to take corrective actions.
Which of the following is the BEST example of a product-risk-based entry in a test plan?
"Incorrect interest calculation could cause financial loss — test thoroughly."
Correct — a product risk driving test focus.
"The test environment may be delivered two weeks late."
A project risk, not a product risk.
"Two testers may leave the project next month."
A staffing (project) risk.
"The test management tool licence may expire."
A tooling/project risk.
A product risk relates to a way the product could fail and harm stakeholders, e.g. an incorrect interest calculation causing financial loss.
A team executed 200 test cases. 150 passed, 30 failed, and 20 were blocked (not run). What is the percentage of executed test cases that passed (passes ÷ executed)?
About 83%
Correct — 150 / 180 ≈ 0.833.
75%
150 / 200 wrongly counts blocked as executed.
85%
Does not match 150 / 180 ≈ 83%.
90%
Overstates the pass rate.
Executed = passed + failed = 180 (blocked were not executed). 150 / 180 ≈ 0.833 ≈ 83%.
Which of the following is a typical attribute that should be recorded in a defect report to help with classification and analysis?
The severity and priority of the defect.
Correct — they support classification and prioritisation.
The personal opinion of the tester about the developer.
Defect reports must stay factual and neutral.
The total project budget.
Budget is unrelated to a defect report.
The number of meetings held that week.
Irrelevant to classifying a defect.
Defect reports record severity/priority, status, lifecycle phase and references, supporting classification and trend analysis.
Which of the following is an example of a coverage-based test metric used to monitor test progress?
Percentage of requirements covered by executed test cases.
Correct — a coverage-based progress metric.
The number of coffees consumed by the team.
Not a meaningful test metric.
The brand of the test management tool.
A tool attribute, not a metric.
The colour scheme of the dashboard.
Cosmetic, not a coverage metric.
Coverage metrics measure the proportion of items covered, e.g. the percentage of requirements covered by executed tests.
Which of the following BEST distinguishes severity from priority for a defect?
Severity is the impact of the defect; priority is the urgency of fixing it.
Correct — independent dimensions.
They always have the same value for a given defect.
They can differ.
Severity is set by management; priority is set by the compiler.
Priority is not determined by the compiler.
Priority is the impact; severity is the urgency.
This reverses the definitions.
Severity is the impact of the defect on the system; priority is the urgency of fixing it. They can differ.
When applying risk-based testing, what is the effect of a feature being assessed as high risk?
It receives earlier and more thorough testing than lower-risk areas.
Correct — risk drives the depth and timing of testing.
It is excluded from testing to save time.
High-risk areas are tested more, not excluded.
It is tested only after release.
High risks are tested before release.
It automatically has zero defects.
Risk level does not change the number of defects.
High-risk areas receive earlier and more thorough testing; lower-risk areas get less.
Which configuration management practice is MOST important for ensuring testing is repeatable and results are traceable?
Uniquely identifying and version-controlling test items and test ware.
Correct — version control underpins repeatability and traceability.
Deleting old test results to save storage.
Deleting results undermines traceability.
Letting each tester keep private, unversioned copies.
Unversioned private copies destroy repeatability.
Avoiding any documentation of versions.
Without version documentation results cannot be traced.
Configuration management uniquely identifies and version-controls test items and test ware, so testers know exactly which versions were tested.
Which of the following is a benefit of using a test execution (automation) tool for regression testing?
Large regression suites can be run quickly and consistently.
Correct — speed and consistency are key benefits.
It removes the need to design any test cases.
Test design is still required.
It guarantees that no defects remain.
No tool guarantees the absence of defects.
It eliminates all maintenance effort.
Automated tests require ongoing maintenance.
Automation tools can run large regression suites quickly and repeatably, providing consistent execution.
Which of the following is a key consideration when SELECTING a test tool for an organisation?
How well the tool fits the organisation's processes and maturity, with a cost-benefit assessment.
Correct — fit and ROI are central.
Only the colour of the tool's user interface.
Cosmetic, not meaningful.
Choosing the most expensive option available.
Price alone does not indicate suitability.
Selecting whichever tool a competitor uses.
A competitor's choice may not fit your context.
Tool selection should consider organisational maturity, fit with existing processes, required skills, vendor support and a cost-benefit assessment.