ISTQB Foundation (CTFL v4.0) Mock Exam #11 — 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.
In a large system the test manager observes that about 80% of the failures come from 3 of the 20 modules, and focuses extra testing there. Which testing principle does this apply?
Defect clustering
A small number of modules usually contain most defects.
Pesticide paradox
That is about repeated tests losing effectiveness, not where defects cluster.
Exhaustive testing is impossible
True, but unrelated to focusing on high-defect modules.
Testing is context dependent
A different principle about adapting to context.
Defects tend to cluster in a few modules; concentrating effort there is defect clustering.
Which statement best distinguishes testing from quality assurance (QA)?
Testing evaluates the product to find defects; QA focuses on processes to prevent defects.
Standard product vs process distinction.
Testing and QA are exactly the same thing.
They are related but distinct.
QA is performed only after release.
QA is process-focused and ongoing.
Testing improves processes, QA finds defects.
Reversed: testing finds defects, QA improves processes.
Testing is product-oriented (evaluating the product); QA is process-oriented (improving processes).
Which TWO of the following are among the seven testing principles?
Testing shows the presence of defects, not their absence
One of the seven principles.
Pesticide paradox
Repeating the same tests stops finding new defects.
Testing guarantees a defect-free product
No principle claims this; it is impossible.
Exhaustive testing is always feasible
The opposite is a principle: exhaustive testing is impossible.
'Tests show presence of defects, not absence' and the 'pesticide paradox' are principles; the other two are false.
During which test activity does a team mainly identify the test conditions (i.e. what should be tested), based on the test basis?
Test analysis
Test analysis derives test conditions from the test basis.
Test implementation
That builds test procedures/data, after design.
Test execution
That runs the tests, much later.
Test completion
That wraps up after execution ends.
Identifying what to test (test conditions) happens during test analysis.
Why is it valuable to maintain traceability between the test basis and the test cases?
It lets the team assess test coverage and the impact of requirement changes
Traceability links requirements to tests for coverage and impact analysis.
It automatically fixes failing tests
Traceability does not fix anything.
It removes the need for a test basis
The test basis is what you trace to.
It guarantees 100% defect detection
No technique guarantees that.
Traceability lets you assess coverage and the impact of changes.
A test passes in the test environment but the same scenario fails in production. Besides a code defect, which is a plausible cause of the failure?
Environmental differences (configuration, data, integrations) between the two environments
Failures can stem from environmental conditions, not only code defects.
Failures can only ever be caused by code defects
Failures may also arise from environment, data or usage conditions.
The test environment is irrelevant to results
Environment strongly affects results.
Passing in test guarantees passing in production
Different environments can behave differently.
Failures can be caused by environmental conditions or data, not only by code defects.
Which TWO statements about quality and testing responsibility are correct in CTFL v4.0?
Quality is a whole-team responsibility
Modern practice shares quality across the team.
Independent testing can find defects the author may miss
Independence reduces author bias.
Only the dedicated test team is responsible for quality
Quality is shared, not owned by testers alone.
Developers should never test their own code
They can and should; independent testing complements it.
Quality is a whole-team responsibility and independent testing can reveal different defects than the author would.
Every activity of the test process creates its own testware. Which of the following items is a typical output of the test monitoring and control activity rather than of another test activity?
Test progress reports
Correct — monitoring gathers information on progress and quality and reports it, so that control decisions can be taken during the test effort.
The test plan
The test plan is the main output of test planning. Monitoring and control compares reality against this plan; it does not produce it.
Test procedures and test data
These are created during test implementation, when the tests are organised and everything needed for execution is prepared.
The test completion report
This report is produced by test completion at the end of a test level or project and summarises the whole effort, not the ongoing progress.
Test monitoring and control produces test progress reports (and control directives). The test plan comes from test planning, test procedures and test data from test implementation, and the test completion report from test completion.
In which development approach is testing typically integrated continuously across short, repeated iterations with frequent feedback?
Agile/iterative development
Testing is continuous within each short iteration.
Sequential (Waterfall) development
Testing is concentrated in a later phase, not continuous.
Big-bang integration
That is an integration strategy, not a development lifecycle.
No development model integrates testing continuously
Agile does exactly this.
Iterative/Agile approaches integrate testing continuously across short iterations.
Component (unit) testing primarily checks what?
Individual components or units in isolation
That is the scope of component testing.
End-to-end business workflows
That is system or acceptance testing.
Interfaces between integrated components
That is integration testing.
User satisfaction in production
That relates to operational/acceptance feedback.
Component testing checks individual modules/units in isolation.
Verifying that a web application is operable by users relying on a screen reader is primarily which test type?
Non-functional (accessibility/usability) testing
Accessibility is a non-functional quality characteristic.
Functional testing
Functional tests check what the system does, not how usable it is.
White-box testing
That is based on internal structure.
Confirmation testing
That re-checks a fixed defect.
Accessibility/usability is a non-functional quality characteristic.
What typically triggers maintenance testing?
A modification, migration or retirement of a system already in operation
These are the standard maintenance testing triggers.
Writing the first line of code
That is initial development, not maintenance.
Drafting the initial requirements
That precedes any operation.
Designing the first test cases
Test design is part of normal development.
Maintenance testing is triggered by modification, migration or retirement of an operational system.
Which TWO of the following are NON-FUNCTIONAL test types?
Performance (load) testing
Evaluates how well the system performs.
Usability testing
Evaluates ease of use, a non-functional characteristic.
Integration testing
That is a test level, not a non-functional type.
Smoke testing
A shallow functional check of basic stability.
Performance and usability are non-functional; integration is a level and smoke is a (functional) test set.
After a change to an operational system, how is the scope of the required regression testing best determined?
By impact analysis of the change to identify affected areas
Impact analysis scopes regression testing rationally.
By always re-running every existing test regardless of the change
Often infeasible; impact analysis focuses effort.
By never running regression tests after changes
Changes risk regressions; some testing is needed.
By choosing tests at random
Random selection ignores actual risk and impact.
Impact analysis identifies which areas may be affected and therefore need regression testing.
Which kind of issue can a static analysis tool typically detect WITHOUT executing the code?
Coding-standard violations and unreachable code
Static analysis inspects code structure without running it.
Actual response time under heavy load
That requires dynamic execution.
Memory leaks observed at run time
Run-time behaviour needs execution.
User satisfaction scores
That comes from user feedback, not static analysis.
Static analysis finds coding-standard violations, unreachable code, undefined variables, etc.
In the generic review process, which activity comes FIRST?
Planning
Defining scope and which work products to review comes first.
Issue communication and analysis
That happens after the review meeting.
Individual review
That follows initiation/kick-off.
Fixing and reporting
That is near the end.
The generic review process starts with planning.
Which TWO are genuine benefits of reviews (static testing)?
Early detection of defects in work products
Reviews find defects before code runs.
Knowledge sharing among participants
Reviews spread understanding across the team.
Measuring response time under load
That requires dynamic performance testing.
Guaranteeing a defect-free product
No activity can guarantee zero defects.
Reviews enable early defect detection and knowledge sharing; they don't measure performance or guarantee zero defects.
Static testing comprises both reviews and static analysis. Which statement correctly describes what distinguishes static analysis from a review?
Static analysis is normally performed by tools that check code or other formal artefacts against rules and standards, whereas a review is a human examination of a work product.
Correct — the essential difference is who or what performs the examination: tools versus people.
Static analysis executes the code with predefined inputs, whereas a review does not execute anything.
Neither of them executes the test object. As soon as code is executed the activity is dynamic testing, not static testing.
Static analysis can only be applied after the code has been compiled and deployed to a test environment.
Static analysis tools work directly on source code or models and need neither a deployment nor a running system; that is one of their advantages.
A review is fully automated by tools, whereas static analysis must always be carried out manually.
The roles are reversed. Static analysis is the tool-supported part of static testing; reviews rely on human judgement, even if tools may support their administration.
Static analysis is tool-driven: tools examine code, models or other formal artefacts against coding standards and rules. A review is a human examination of a work product. Neither executes the test object.
A grading system assigns a band by integer mark: 0-39 fail, 40-59 pass, 60-79 merit, 80-100 distinction. Using equivalence partitioning on VALID marks only, what is the minimum number of test cases to cover each valid band exactly once?
4
One representative value for each of the four valid bands.
3
There are four valid bands, not three.
2
Two cases cannot cover four partitions.
8
That would count boundaries, not partitions.
There are four valid bands, so four test cases (one representative each).
A field accepts integers from 10 to 50 inclusive; values outside are rejected. Using the 2-value boundary value analysis approach (each boundary plus its nearest neighbour), which set tests BOTH boundaries?
{9, 10, 50, 51}
Boundary plus its nearest outside neighbour at each end.
{10, 50}
Boundaries alone omit the neighbours.
{9, 10, 11, 49, 50, 51}
That is the 3-value approach (six values).
{10, 11, 49, 50}
Uses inside neighbours instead of outside ones.
Each boundary (10, 50) plus its nearest outside neighbour (9, 51): {9,10,50,51}.
For the same field accepting integers 10 to 50 inclusive, how many distinct values does the 3-value boundary value analysis approach require to cover BOTH boundaries?
6
Three values per boundary, two boundaries, no overlap.
4
That is the 2-value approach.
8
Over-counts; three values per boundary suffice.
3
Three values cover only one boundary.
Lower {9,10,11} and upper {49,50,51} = six distinct values.
Use the decision table below. A 22-year-old driver (under 25) takes premium insurance and has a clean driving record. Which rule applies and what is the outcome?
Rule R5 - Approve with young-driver surcharge
Age N, Premium Y, Clean Y is exactly column R5.
Rule R1 - Approve, no surcharge
R1 requires Age>=25 = Y.
Rule R6 - Approve + young + risk surcharge
R6 requires Clean record = N.
Rule R8 - Decline
R8 requires Premium = N and Clean = N.
Age>=25 = N, Premium = Y, Clean = Y matches R5: Approve + young-driver surcharge.
In the decision table below, the two Decline rules (R4 and R8) both have Premium insurance = N and Clean record = N, and differ only in the driver-age condition. Using don't-care simplification, how many columns merge into a single combined rule?
2 (R4 and R8 merge into one rule)
Both Decline when Premium = N and Clean = N, age is don't-care.
4
Only the two Decline columns share an identical action here.
8
Only two columns collapse, not all eight.
1
One column cannot 'merge'; two merge into one.
R4 and R8 share the same action and differ only in a don't-care condition, so 2 merge into 1.
For which situation is state transition testing the MOST appropriate technique?
An order whose allowed actions depend on its current status (e.g. paid, shipped)
Behaviour depends on state and events - ideal for state transition testing.
A single numeric input field with an allowed range
That suits boundary value analysis.
A business rule combining several independent conditions
That suits decision table testing.
Measuring code coverage of a function
That is structural (white-box) testing.
State transition testing fits systems whose behaviour depends on the current state and incoming events.
Using the order-lifecycle state machine below, which event sequence is a VALID path from Created to Delivered?
Created -> pay -> Paid -> pack -> Packed -> ship -> Shipped -> deliver -> Delivered
Every transition exists in the diagram in this order.
Created -> pack -> ship -> deliver
You cannot pack before paying; there is no Created->Packed transition.
Created -> pay -> Paid -> ship -> deliver
There is no Paid->Shipped transition; packing is required first.
Created -> pay -> Paid -> cancel -> Delivered
Cancel leads to Cancelled, not Delivered.
The valid path is pay, pack, ship, deliver.
Consider this routine with five executable statements: (1) INPUT n; (2) total = 0; (3) IF n > 0; (4) total = n * 2; (5) PRINT total. Statement 4 runs only when the IF is true. A single test runs with n = 0. What statement coverage does it achieve?
80%
Statements 1, 2, 3 and 5 execute; statement 4 is skipped: 4/5.
100%
Statement 4 is not reached when n = 0.
60%
Four of five statements run, not three.
40%
Only one statement is skipped, four execute.
With n = 0 the IF is false, so 4 of 5 statements run = 80%.
Which TWO of the following are white-box (structure-based) test techniques?
Statement testing
Based on executing code statements.
Branch testing
Based on covering decision outcomes in code.
Equivalence partitioning
A black-box, specification-based technique.
Decision table testing
A black-box, specification-based technique.
Statement and branch testing are white-box; equivalence partitioning and decision tables are black-box.
A tester, drawing on experience, lists likely problem inputs (empty fields, zero, very large numbers, special characters) and tests them. Which technique is this?
Error guessing
An experience-based technique anticipating likely defects.
Equivalence partitioning
A systematic black-box technique, not experience-driven.
Boundary value analysis
Systematic, focused on range edges.
State transition testing
Based on states and events, not guessing.
Anticipating likely error-prone inputs from experience is error guessing.
Which TWO of the following are white-box (structure-based) test techniques? (Choose two.)
Statement testing.
Based on executing statements in the code — a white-box technique.
Branch testing.
Based on exercising decision outcomes in the code — a white-box technique.
Equivalence partitioning.
A black-box (specification-based) technique.
Use case testing.
A black-box (specification-based) technique.
White-box techniques are based on the internal structure of the code, e.g., statement testing and branch testing. Equivalence partitioning and use case testing are black-box.
A test approach in which test design and execution begin only after the software is delivered, reacting to the system as built, is best described as:
A reactive test approach.
Correct — tests are designed and run in reaction to the delivered system.
A preventive test approach.
Preventive approaches design tests early, before the code is built.
A white-box test approach.
White-box refers to using internal structure, not the timing of test design.
A confirmation test approach.
Confirmation testing re-tests after a fix; it is not an overall approach defined by timing.
A reactive approach designs and runs tests in response to the delivered software (e.g., exploratory testing). A preventive approach designs tests early, before the software exists.
Which of the following is an example of an EXIT criterion for a test level?
Planned coverage has been achieved and no high-severity defects remain open
Exit criteria define when testing can stop.
The test environment has been set up
That is an entry criterion.
Requirements have been baselined
An entry/readiness condition, not exit.
A test tool has been purchased
Unrelated to exit criteria.
Planned coverage achieved with no open high-severity defects is a typical exit criterion.
In risk analysis, what does the 'impact' of a risk refer to?
The consequence or harm if the risk materialises
Impact measures how bad the outcome would be.
The probability that the risk will occur
That is likelihood, not impact.
The number of testers assigned
Unrelated to risk impact.
The cost of the test tool
Unrelated to risk impact.
Impact is the magnitude of harm/consequence if the risk materialises.
During a test cycle, the manager re-prioritises and reassigns tests because a high-risk area is failing badly. This is an example of which activity?
Test control
Test control takes corrective actions based on monitoring information.
Test monitoring
Monitoring gathers the information; acting on it is control.
Test planning
Planning happens before execution, not as a reaction.
Test completion
Completion wraps up after execution ends.
Taking corrective action based on monitoring is test control.
Which TWO items typically belong in a test completion (summary) report?
A summary of the testing performed and the results
Core content of a completion report.
Residual risks and lessons learned
Helps stakeholders decide and improve.
The full source code of the system
Not part of a completion report.
Each developer's salary
Irrelevant and inappropriate.
A summary of testing performed/results and residual risks/lessons learned belong in a completion report.
A purely cosmetic text typo on the landing page is fixed urgently because a major launch is tomorrow. What does this illustrate?
Severity and priority are independent - a low-severity defect can be high priority
Business context can raise priority regardless of severity.
Severity and priority are always the same
They are distinct attributes and can differ.
Cosmetic defects must never be fixed
Sometimes they matter a lot (e.g. brand launch).
Priority is set only by developers
Priority is typically a business/stakeholder decision.
Severity and priority are different: a low-severity defect can have high priority.
Using three-point estimation with optimistic = 2 days, most likely = 5 days, pessimistic = 14 days, what is the expected duration via (a + 4m + b) / 6?
6 days
(2 + 4*5 + 14)/6 = 36/6 = 6.
5 days
5 is the most likely value, not the weighted estimate.
7 days
Does not match the formula result of 6.
8 days
Arithmetic slip; the correct value is 6.
(2 + 20 + 14) / 6 = 36 / 6 = 6 days.
Which TWO factors typically influence a test effort estimate?
The size and complexity of the product
Bigger, more complex products need more testing.
The required quality level and product risk
Higher quality/risk needs deeper testing.
The testers' favourite colour
Irrelevant to effort.
The number of meeting rooms in the building
Irrelevant to test effort.
Product size/complexity and required quality/risk level drive test effort.
How does a test strategy differ from a test plan?
A test strategy describes a general, organisation- or programme-level test approach, while a test plan is specific to a project or level
Strategy is generic; the plan applies it to a context.
They are identical documents with different names
They operate at different levels of abstraction.
A test plan is always more generic than a test strategy
Reversed: the strategy is the more generic one.
A test strategy lists the exact test cases to run
That level of detail belongs to design, not strategy.
A test strategy is a general, organisation- or programme-level approach; a test plan is project/level-specific.
Which tool type checks source code for standard violations and suspicious constructs WITHOUT executing it?
Static analysis tool
Examines code structure without execution.
Performance testing tool
Runs the system under load.
Test management tool
Manages tests and traceability, not code analysis.
Test execution (automation) tool
Runs test scripts dynamically.
A static analysis tool inspects code without running it.
Which TWO are sensible considerations when selecting a test tool for an organisation?
Compatibility with existing tools and processes
Integration avoids friction and rework.
Evaluation of vendor support and ongoing maintenance
Long-term support affects total cost and risk.
How catchy the tool's marketing slogan is
Irrelevant to tool effectiveness.
A vendor guarantee of a defect-free product
No tool can guarantee zero defects.
Fit with existing tools/processes and vendor support/maintenance are sensible selection criteria.