ISTQB Foundation (CTFL v4.0) Mock Exam #10 — 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 statement best describes the difference between testing and debugging?
Testing identifies failures caused by defects; debugging locates, analyses and fixes those defects.
Correct ISTQB distinction between the two activities.
Testing fixes defects; debugging only finds them.
Reversed — fixing is part of debugging/development.
Testing and debugging are two names for the same activity.
They are distinct activities with different goals.
Debugging is performed only by testers.
Debugging is typically a development activity.
Testing finds failures; debugging locates and fixes the underlying defects.
A junior tester proposes testing every possible input combination of a form to guarantee it is defect-free. Which testing principle explains why this is not feasible?
Exhaustive testing is impossible.
Testing everything is not feasible; use risk and techniques to focus.
Defect clustering.
This principle is about defects concentrating in few modules.
Pesticide paradox.
This is about repeated tests losing effectiveness over time.
Tests show the presence of defects, not their absence.
True principle, but it does not explain infeasibility of exhaustive testing.
Exhaustive testing is impossible except for trivial cases.
Which of the following are objectives of testing? (Choose TWO.)
Finding defects.
A primary objective of testing.
Building confidence in the quality level.
Also a core objective of testing.
Proving the software has no defects.
Impossible — testing cannot prove the absence of defects.
Repairing the defects that are found.
Fixing is debugging/development, not testing.
Testing finds defects and builds confidence; it cannot prove their absence, and fixing is not testing.
A developer types > instead of >= in a comparison. At run time the program rejects a valid boundary value and the user sees a wrong message. Map these to the ISTQB terms error, defect and failure.
The mistype is the error (mistake); the wrong operator in the code is the defect; the rejected valid value is the failure.
Correct error to defect to failure chain.
The wrong operator is the error; the mistype is the defect; the message is the failure.
Error and defect are swapped.
All three terms describe the same event.
They denote distinct stages.
The failure is the wrong code; the defect is the user-visible message.
Failure is the run-time effect, not the code.
The human mistake is the error, the wrong code is the defect, the observed wrong behaviour is the failure.
Why is root cause analysis of defects valuable for an organisation?
Addressing root causes can prevent whole classes of future defects.
Process improvement reduces recurrence.
It assigns blame to the developer who caused the defect.
Root cause analysis is not about blame.
It guarantees the next release has no defects.
No activity can guarantee zero defects.
It replaces the need for dynamic testing.
It complements, not replaces, testing.
Removing root causes can prevent whole classes of future defects (process improvement).
Which statement correctly illustrates that testing is context dependent?
A safety-critical medical device is tested more rigorously than a throwaway internal prototype.
Context and risk drive test intensity.
All software must be tested identically regardless of risk.
Contradicts context dependence.
Context only affects the programming language, not testing.
Context affects the whole test approach.
Context dependence means testing is optional.
It means the approach varies, not that testing is skipped.
Test intensity should match the risk and context of the product.
Which TWO statements about a tester's mindset and independence are correct?
Curiosity and attention to detail help testers find subtle defects.
A constructive testing mindset improves detection.
A degree of independence can increase the effectiveness of defect detection.
Independence reduces author bias.
Testers and developers should never communicate.
Collaboration is essential.
Complete independence always finds more defects than any other arrangement.
Overstated; independence has trade-offs.
Curiosity and a degree of independence help; total isolation or absolute claims are wrong.
Setting up a separate test team with a high degree of independence brings recognised benefits, but the syllabus also lists drawbacks. Which of the following is a drawback of a high degree of test independence?
Developers may lose their own sense of responsibility for quality, and the independent team can become isolated or be seen as a bottleneck.
Correct — these are exactly the drawbacks the syllabus associates with a high degree of independence.
Independent testers are less willing to question the assumptions made by the authors of the work products.
This reverses the effect: independence makes testers more willing to challenge assumptions, because they were not involved in creating the work product. That is a benefit, not a drawback.
An independent test team is not allowed to use the requirements specification as a test basis.
Nothing restricts the test basis according to who tests. Independent testers use the same requirements, designs and other sources as anyone else.
Independent testing makes a whole-team approach to quality impossible.
The two are complementary: different degrees of independence can coexist with shared, whole-team responsibility for quality. The real drawback is the risk of isolation, not a formal impossibility.
Independent testers may become isolated from the development team, may be seen as a bottleneck or as the sole owners of quality, and developers may lose their own sense of responsibility for quality.
Why does fixing a defect found during requirements review typically cost less than fixing the same defect in production?
The defect is removed before it propagates into design, code and dependent components.
Early testing limits downstream rework cost.
Requirements defects are always trivial.
Severity is unrelated to when it is found.
Production fixes are free.
Production fixes are usually the most expensive.
Reviews automatically fix the defects they find.
Reviews detect, they do not fix.
Early removal prevents the defect from propagating into design, code and dependent work.
Which test level focuses on testing the interfaces and interactions between integrated components or systems?
Integration testing.
Targets interfaces between integrated components/systems.
Component testing.
Tests modules in isolation, not their interactions.
System testing.
Tests the whole system behaviour, not specifically interfaces.
Acceptance testing.
Validates fitness for use by stakeholders.
Integration testing exercises interfaces and interactions between integrated parts.
A tester verifies that the system still serves 5000 concurrent users within 2 seconds after a code change. Which test type is this primarily?
Non-functional (performance) testing.
It evaluates how well the system performs, not what it does.
Functional testing.
Functional tests check what the system does, not performance.
White-box (structural) testing.
That is based on internal structure, not user load.
Confirmation testing.
That re-checks a single fixed defect.
Checking response time under load is non-functional (performance) testing.
After a defect fix, a tester first re-runs the test that originally failed to verify the fix, then runs nearby tests to ensure nothing else broke. Name the two activities in order.
Confirmation testing, then regression testing.
Confirm the fix works, then check for unintended side effects.
Regression testing, then confirmation testing.
Order is reversed.
System testing, then acceptance testing.
Those are test levels, not change-related activities.
Smoke testing, then exploratory testing.
Neither matches the described purpose.
First confirmation testing of the fix, then regression testing of the surrounding area.
Which TWO of the following are test LEVELS (not test types or change-related testing)?
Component integration testing.
A recognised test level in CTFL v4.0.
Acceptance testing.
A test level focused on readiness for use.
Performance testing.
That is a non-functional test type.
Regression testing.
That is change-related testing, not a level.
Component integration and acceptance are levels; performance is a type and regression is change-related.
Which acceptance testing form is performed by potential users at the developer's site rather than in the field?
Alpha testing.
Performed by potential users at the developer's site.
Beta testing.
Performed by users in their own environment.
Operational acceptance testing.
Checks operational aspects like backup/restore.
Contractual acceptance testing.
Checks compliance with contract criteria.
Alpha testing is conducted at the developer's site; beta testing is in the user's environment.
Which benefit is characteristic of static testing compared with dynamic testing?
It can find defects (e.g. in requirements) before any code is executed.
Static testing examines work products without running them.
It measures actual response time under load.
That requires dynamic execution.
It always replaces the need for dynamic testing.
The two are complementary.
It can only be applied to source code.
It applies to requirements, designs and more.
Static testing can find defects in work products before any code is executed.
In a formal review meeting, who is primarily responsible for recording the defects and issues raised?
The scribe (recorder).
Documents the issues and decisions of the review.
The moderator (facilitator).
Leads the meeting but does not primarily record issues.
The author.
Owns the work product, does not record on behalf of the team.
Any reviewer.
Reviewers find issues; recording is the scribe's role.
The scribe (recorder) documents issues raised during the review.
Which TWO review types are typically the most formal, with defined entry/exit criteria and metrics?
Inspection.
The most formal review type with metrics and roles.
Technical review.
A documented, often formal review by technical peers.
Informal review.
By definition has no formal process.
Ad-hoc desk check.
An informal, unstructured check.
Inspection and technical review are the more formal types; informal and ad-hoc are not.
Which TWO of the following are typical benefits of static testing? (Choose two.)
Detecting defects early, before code is executed.
Correct — early detection reduces fixing cost.
Finding defects that are hard to detect by dynamic testing (e.g. unreachable code).
Correct — static analysis can reveal such structural defects.
Measuring the actual performance of the running system.
Static testing does not execute the system, so it cannot measure performance.
Confirming the system behaves correctly with real user data.
Confirming runtime behaviour requires dynamic testing.
Static testing detects defects early (cheaper to fix) and can find defects that dynamic testing cannot easily find, such as unreachable code or requirement inconsistencies. It does not execute code or measure performance.
An online ticketing system sets the price by age: ages 0-17 pay the child fare, ages 18-64 pay the standard fare, and ages 65 and over pay the senior fare. Ages are entered as whole numbers. Using equivalence partitioning on VALID age inputs only, what is the minimum number of test cases needed to cover every valid price partition exactly once?
3
One representative value per valid partition.
2
Three valid partitions cannot be covered by two cases.
4
Only three valid partitions exist; invalid ones were excluded.
6
That would count boundaries, not partitions.
There are three valid partitions (child, standard, senior); one representative each gives 3.
A quantity field accepts integers from 1 to 100 inclusive; values outside are rejected. Using the 2-value boundary value analysis approach (each boundary plus its nearest neighbour), which set of values tests BOTH boundaries?
{0, 1, 100, 101}
Each boundary (1, 100) plus its nearest outside neighbour (0, 101).
{1, 100}
Boundaries alone omit the neighbouring values.
{0, 1, 2, 99, 100, 101}
That is the 3-value approach (six values).
{1, 2, 99, 100}
Uses inside neighbours instead of the outside neighbours.
2-value BVA tests each boundary and its nearest neighbour: {0,1} and {100,101}.
For the same field accepting integers 1 to 100 inclusive, how many distinct values does the 3-value boundary value analysis approach require to cover BOTH boundaries (the boundary plus the value just below and just above each)?
6
Three values per boundary, two boundaries, no overlap.
4
That is the 2-value approach.
8
Over-counts; only three values per boundary are needed.
3
Three values cover only one boundary.
Lower {0,1,2} and upper {99,100,101} = six distinct values.
Use the decision table below. A subscriber on the Premium plan has a valid payment, but is starting a fourth simultaneous stream, which exceeds their device limit. Which rule applies and what is the resulting action?
Rule R2 - Deny (device limit exceeded)
Payment Y, Premium Y, Device OK N is exactly column R2.
Rule R1 - Allow 4K/HD
R1 requires Device limit OK = Y.
Rule R5 - Deny (payment)
R5 requires Payment valid = N.
Rule R4 - Deny (device limit)
R4 requires Plan = Premium N (Standard).
Payment Y, Premium Y, Device limit OK = N matches R2: Deny (device limit).
In the decision table below, whenever Payment valid = N (rules R5-R8) the action is always Deny (payment), regardless of the other two conditions. Using don't-care simplification, how many of the eight columns can be merged into a single combined rule?
4 (R5-R8 collapse into one rule)
All four share Deny (payment) when Payment = N.
2
More than two columns share the identical action here.
8
Only the four payment-invalid columns collapse, not all eight.
1
One column cannot be 'merged'; four merge into one.
R5-R8 share the same action and differ only in don't-care conditions, so 4 collapse into 1.
A tester needs to derive tests from a business rule that combines several conditions producing different outcomes. Which black-box technique is most appropriate?
Decision table testing
Designed for combinations of conditions and outcomes.
State transition testing
Best for event-driven state changes, not condition combinations.
Boundary value analysis
Targets edges of ordered ranges, not logic combinations.
Statement testing
A white-box technique based on code, not business rules.
Decision table testing systematically covers combinations of conditions and their actions.
Using the ATM session state machine below, which event sequence is a VALID path that starts and ends in the Idle state?
insert card -> correct PIN -> withdraw -> cash taken -> exit -> card removed
Every transition exists in the diagram and returns to Idle.
insert card -> withdraw -> cash taken
There is no transition from AwaitPIN to Dispensing without a correct PIN.
insert card -> 3rd wrong PIN -> card removed
From Locked the transition to Idle is 'card retained', not 'card removed'.
insert card -> correct PIN -> exit -> withdraw
After exit the machine is in CardReturned; withdraw is not valid there.
The valid round trip is insert card, correct PIN, withdraw, cash taken, exit, card removed.
Consider this routine with four executable statements: (1) INPUT x; (2) IF x > 10; (3) PRINT big; (4) PRINT done. The PRINT big statement runs only when the IF is true. A single test executes with x = 5. What statement coverage does this one test achieve?
75%
Statements 1, 2 and 4 execute; statement 3 is skipped: 3/4.
100%
Statement 3 (PRINT big) is not reached when x = 5.
50%
Three of four statements execute, not two.
25%
Only one statement skipped, three executed.
With x = 5 the IF is false, so 3 of 4 statements run = 75%.
Which TWO of the following are black-box (specification-based) test techniques?
Equivalence partitioning
Derived from the specification, not the code.
State transition testing
Based on specified states and events (black-box).
Statement testing
A white-box technique based on code structure.
Branch testing
A white-box technique based on decisions in the code.
Equivalence partitioning and state transition testing are black-box; statement and branch testing are white-box.
A tester investigates an application without predefined scripts, simultaneously designing and running tests and learning from each result to guide the next. Which technique is this?
Exploratory testing
Concurrent test design, execution and learning.
Checklist-based testing
Guided by a fixed checklist, not free exploration.
Decision table testing
A specification-based technique with predefined cases.
Error guessing
Anticipates specific likely errors, not open-ended exploration.
Designing and executing tests concurrently while learning is exploratory testing.
Which statement best characterises exploratory testing?
Test design, execution and learning are performed concurrently, often in time-boxed sessions.
Correct — exploratory testing interleaves learning, design and execution.
All test cases are fully scripted in advance before any execution.
That describes scripted testing, the opposite of exploratory testing.
It can only be performed by automated tools.
Exploratory testing is primarily a human, manual activity.
It guarantees measurable structural coverage.
Exploratory testing does not by itself guarantee a structural coverage figure.
In exploratory testing, test design, execution and learning happen concurrently; it is often organised in time-boxed, chartered sessions and is effective when specifications are sparse.
Which of the following is typically documented in a test plan?
Scope, objectives, schedule and entry/exit criteria for the test activities
These are core contents of a test plan.
The exact list of defects that will be found
Defects cannot be known in advance.
The full source code of the system
Source code is not part of a test plan.
Marketing copy for the release
Irrelevant to test planning.
A test plan documents scope, objectives, schedule and entry/exit criteria.
A key tester unexpectedly leaving in the middle of the project is an example of which kind of risk?
Project risk
It threatens project management/delivery, not the product itself.
Product risk
Product risk concerns quality of the deliverable itself.
Residual risk
Residual risk is what remains after mitigation.
Risk level
Risk level is a measure, not a category of risk.
Staffing problems affect the project's ability to deliver: a project risk.
How does risk-based testing primarily influence the allocation of test effort?
More and deeper testing is allocated to higher-risk areas
Effort follows risk to maximise value.
Effort is spread equally regardless of risk
That ignores the purpose of risk-based testing.
Only low-risk areas are tested
High-risk areas are precisely where most testing is needed.
Testing is skipped entirely for risky areas
Risk increases, not removes, the need to test.
Higher-risk areas receive more and deeper testing.
Which TWO are realistic ENTRY criteria for starting a test level?
The test environment is available and configured
Needed before execution can begin.
Test cases and test data are ready
Required inputs to start testing.
All defects have already been fixed
That is unrealistic as an entry criterion.
The product has been released to customers
Release is after testing, not an entry criterion.
A ready environment and ready test cases/data are typical entry criteria.
Which item is essential content of a good defect report?
Steps to reproduce, expected and actual results
Core information to analyse and fix the defect.
The developer's home address
Irrelevant and inappropriate.
A guess about who is to blame
Defect reports should be factual, not accusatory.
The marketing budget
Unrelated to the defect.
Steps to reproduce plus expected and actual results let developers act on the report.
A team estimates a test task using three-point estimation: optimistic = 3 days, most likely = 6 days, pessimistic = 15 days. Using the formula (a + 4m + b) / 6, what is the expected duration?
7 days
(3 + 4*6 + 15)/6 = 42/6 = 7.
6 days
6 is the most likely value, not the weighted estimate.
8 days
Result of an arithmetic slip; the correct value is 7.
9 days
Does not match the formula result of 7.
(3 + 24 + 15) / 6 = 42 / 6 = 7 days.
Four product risks are rated on a 1-5 scale: R1 L=3 I=4; R2 L=4 I=4; R3 L=5 I=2; R4 L=2 I=5. If the risk level is the product of Likelihood (L) and Impact (I), which risk should be tested FIRST?
R2 (risk level 16)
4*4 = 16 is the highest of all four.
R1 (risk level 12)
3*4 = 12 is lower than R2's 16.
R3 (risk level 10)
5*2 = 10 is lower than R2's 16.
R4 (risk level 10)
2*5 = 10 is lower than R2's 16.
R2 has the highest product (16) and is tested first.
Which TWO are useful metrics for monitoring test progress?
Number of test cases run versus planned
Shows execution progress against the plan.
Defect detection and closure trends over time
Indicates quality and convergence.
The number of lines in the test plan document
Document length is not a progress metric.
The testers' average typing speed
Irrelevant to test progress.
Tests run vs planned and defect trends are meaningful progress metrics.
Why is configuration management important for testing?
It ensures test items, testware and environments are versioned and reproducible
Reproducibility depends on controlled versions.
It guarantees the software has no defects
CM does not remove defects.
It replaces the need for a test plan
CM complements, not replaces, planning.
It automatically writes the test cases
CM manages versions, it does not author tests.
It versions test items, testware and environments so results are reproducible.
Which tool type primarily supports linking requirements, test cases and defects, and reporting on them?
Test management tool
Manages traceability and reporting across the test process.
Performance testing tool
Generates load and measures performance, not traceability.
Static analysis tool
Analyses code without executing it.
Coverage measurement tool
Measures structural coverage, not traceability.
A test management tool links requirements, tests and defects and reports on them.
Which TWO are genuine benefits of test automation?
Reduces repetitive manual effort for regression tests
Frees testers for higher-value work.
Improves consistency and repeatability of execution
Machines run the same steps the same way.
Guarantees a defect-free product
No technique can guarantee zero defects.
Eliminates the need for any test design
Automation executes tests that still must be designed.
Automation reduces repetitive effort and improves repeatability; it does not guarantee defect-free software or remove test design.