Free ISTQB CTFL v4.0 Practice Exam

Practise with 40 original ISTQB CTFL v4.0 questions from the current IT Mastery bank. Use testing scenarios, boundary values, decision tables, state diagrams, coverage calculations, and risk evidence to practise Foundation Level reasoning.

These are independent IT Mastery practice questions, not official ISTQB questions, copied live-exam content, or exam dumps.

Start Question 1 · Review your attempt

How to use this free exam

1. Record your answer before opening its explanation. This set contains 40 single-answer questions.
2. For a timed attempt, set your own 60-minute timer. This page does not run a timer, record answers, or calculate a score.
3. Award one point per correct question, for a total out of 40. Mark correct guesses for review too.
4. Read the explanation and identify the evidence that rules out the strongest competing answer.

Wide tables scroll horizontally. Code blocks offer Wrap lines and Copy code. Where a diagram appears, use Open full-size diagram or its Text description if you need more space.

ISTQB specifies 40 questions in 60 minutes and 26 points to pass. This set follows the published chapter allocation of 8/6/4/11/9/2. Confirm any approved extra time with your exam provider. Official exam details .

Practice-set coverage

Practice questions

Questions 1-25

Question 1

Topic: Test Analysis and Design

A team is using acceptance test-driven development for this user story:

As a signed-in customer, I want to upload a profile photo so that my account is recognizable.

Agreed criteria:

• A JPEG file up to and including 5.0 MB is accepted.
• A non-JPEG file or a file over 5.0 MB is rejected with Unsupported photo; the existing photo remains.
• An accepted photo is displayed within 3 seconds of submission.

Each scenario starts with an existing photo and uploads one of these files: 4.9 MB JPEG, 5.0 MB JPEG, 4 MB PNG, or 5.1 MB JPEG.

Which completed acceptance-test set is fully supported by the criteria?

Options:

• A. Both JPEG files up to 5.0 MB are accepted and displayed within 5 seconds; the PNG and 5.1 MB JPEG are rejected with Unsupported photo, and the existing photo remains.

• B. The three files no larger than 5.0 MB are accepted and displayed within 3 seconds; the 5.1 MB JPEG is rejected with Unsupported photo, and the existing photo remains.

• C. Both JPEG files up to 5.0 MB are accepted and displayed within 3 seconds; the PNG and 5.1 MB JPEG are rejected with Unsupported photo, and the existing photo remains.

• D. The 4.9 MB JPEG is accepted and displayed within 3 seconds; the 5.0 MB JPEG, PNG, and 5.1 MB JPEG are rejected with Unsupported photo, and the existing photo remains.

Best answer: C

Explanation: Acceptance test-driven development converts agreed criteria into concrete, stakeholder-readable examples with explicit preconditions, inputs, and expected results. The 4.9 MB and 5.0 MB JPEG files satisfy both the format rule and the inclusive size limit, so each must be accepted and displayed within 3 seconds. The PNG violates the format rule despite being below the size limit, while the 5.1 MB JPEG violates the size rule despite having the correct format. Both invalid files must produce the specified message and leave the existing photo unchanged.

The tests must preserve the exact inclusive boundary and timing threshold rather than weakening or reinterpreting them.

• Size-only interpretation incorrectly accepts the PNG even though file format is an independent acceptance condition.
• Relaxed display time permits 5 seconds, which does not demonstrate the required 3-second response.
• Exclusive boundary incorrectly rejects 5.0 MB even though the criterion explicitly includes that value.

Question 2

Topic: Managing Testing

A system test cycle has ended. Of 120 planned tests, 116 ran: 110 passed and 6 failed. Four were blocked by an unavailable interface. Two high-severity defects remain open, and peak-load behavior was not tested. Exit criteria required all planned tests to run and no open high-severity defects.

Which summary best communicates the testing outcomes and residual issues?

Options:

• A. Restate the planned scope and staffing assumptions, describe selected test techniques, and reproduce the original schedule and estimates.

• B. Describe each unresolved failure with reproduction steps and evidence, then record actual and expected results in separate defect records.

• C. Compare results with the execution schedule, assign blocked tests to a future cycle, and list detailed activities for that cycle.

• D. Compare results with objectives and exit criteria, note blocked scope, and summarize open defects and untested peak-load risk.

Best answer: D

Explanation: A test completion report evaluates completed testing against the test objectives, plan, and exit criteria. It summarizes results, significant deviations or impediments, unresolved defects, and residual product risks. Here, four tests were blocked and two high-severity defects remain open, so the stated exit criteria were not met. The untested peak-load behavior is also a residual risk that stakeholders need when making a release decision.

Detailed defect evidence belongs in defect reports, while schedules, staffing, and techniques primarily belong in test plans or progress reporting.

• Future-cycle activities focus on planning or progress rather than evaluating the completed cycle and its residual risks.
• Reproduction steps and evidence belong in individual defect reports, not the aggregate completion summary.
• Original scope, staffing, techniques, and estimates describe the test plan rather than actual outcomes and remaining issues.

Question 3

Topic: Fundamentals

A team prepares the following items for test execution:

Which interpretation is supported?

Options:

• A. D is prepared test data, while R states test data requirements.

• B. P is a test suite, while U is a test procedure.

• C. S is a test procedure, while P is an automated test script.

• D. E is an automated test script, while S is a test environment item.

Best answer: A

Explanation: Prepared test data contains concrete values available for execution, such as the synthetic records in accounts.csv. A test data requirement instead describes the characteristics or conditions that the data must satisfy.

A test procedure specifies an execution sequence, including setup and cleanup. An automated test script contains executable instructions. A test suite is a collection of test cases grouped for execution. Stubs, drivers, simulators, and service virtualization components are test environment items because they support or replace parts of the execution environment.

The artifact’s function, rather than its file format or automation level, determines its classification.

• Swapping the runbook and regression collection confuses an ordered procedure with a grouped test suite.
• Swapping executable code and the runbook confuses an automated script with execution instructions.
• The virtual gateway belongs to the environment, while the executable response checker is a test script.

Question 4

Topic: Testing in the Lifecycle

A DevOps team makes small commits throughout the day. Developers, testers, and business representatives agree on acceptance examples before coding. A continuous delivery pipeline runs fast component and component integration tests on every commit, runs slower system tests later, publishes results to a shared dashboard, and stops promotion when required checks fail.

Which interpretation best explains how this arrangement supports rapid testing feedback?

Options:

• A. Passing automated checks validates stakeholder needs, while collaborative acceptance activities add little feedback.

• B. Frequent automated checks reveal failures early, while tester-only diagnosis provides the quickest response.

• C. Frequent automated checks reveal failures early, while shared results enable prompt cross-role diagnosis.

• D. Broad system tests provide the quickest feedback, while component tests are more useful later.

Best answer: C

Explanation: Continuous integration shortens feedback by automatically testing each small integration, so failures relate to a limited set of changes. A delivery pipeline can run quick, lower-level tests before slower, broader tests and stop promotion when required checks fail. Collaboration adds speed because developers, testers, and business representatives share expectations and see results immediately, reducing handoffs during clarification and diagnosis.

Passing pipeline checks means only that the defined checks passed. It does not guarantee that every stakeholder need is satisfied or remove the value of acceptance activities. Fast automation and shared responsibility therefore reinforce each other.

• Restricting diagnosis to testers delays cross-role access to knowledge needed for rapid failure analysis.
• Starting with slower system tests lengthens the earliest feedback cycle compared with fast component-level checks.
• Passing automated checks does not prove that every stakeholder need has been validated.

Question 5

Topic: Static Testing

A technical review of a 200-page requirements specification records six findings. Analysis determines that:

• Three are confirmed defects in one section.
• Two are misunderstandings; the specification is accurate.
• One remains unresolved pending product owner clarification.

The review plan sets follow-up scope to corrected and directly affected content. Which handling and reporting outcome is most appropriate?

Options:

• A. Report all six statuses, assign four unresolved items for correction, correct the work product, then re-review the affected sections.

• B. Report all six statuses, assign three defects for correction and one anomaly for clarification, correct the defects, then re-review affected sections.

• C. Report all six statuses, assign three defects for correction and one anomaly for clarification, correct the defects, then re-review the entire specification.

• D. Report all six as defects, assign every finding for correction, correct the work product, then re-review the affected sections.

Best answer: B

Explanation: Review findings are initially anomalies, not automatically defects. Each finding must be analyzed and given an appropriate disposition. Confirmed defects are assigned to owners and corrected; misunderstandings can be closed with their analyzed status recorded; unresolved anomalies require clarification before deciding whether correction is necessary. The review report should communicate these statuses and the progress of corrective actions.

Follow-up review confirms that corrections are satisfactory and have not created related problems. For a large work product, the review may be repeated over selected parts when the review plan defines that scope. Here, the corrected and directly affected sections require follow-up, not the entire specification.

• Treating every finding as a defect ignores the analysis showing that two findings are misunderstandings and one is unresolved.
• Assigning four items for correction incorrectly treats the unresolved anomaly as a confirmed defect before clarification.
• Re-reviewing the entire specification exceeds the follow-up scope defined in the review plan.

Question 6

Topic: Test Analysis and Design

An order workflow uses the state model below. The initial state is Draft. Transition labels show event [guard] / action.

Test data: items = 2, amount = 1,500

An event with no defined transition in the current state displays Invalid event and leaves the state unchanged.

Which test case correctly exercises the high-value review route through to Shipped?

Options:

• A. submit -> clear -> approve -> dispatch; actions: Submitted -> reserve stock -> review task -> notice; final: Shipped

• B. submit -> approve -> clear -> dispatch; actions: Submitted -> review task -> reserve stock -> notice; final: Shipped

• C. submit -> approve -> dispatch -> clear; actions: Submitted -> review task -> notice -> reserve stock; final: Shipped

• D. submit -> approve -> clear -> dispatch; actions: Submitted -> reserve stock -> review task -> notice; final: Shipped

Best answer: B

Explanation: State transition tests follow events from the initial state while evaluating each guard and action. With two items, submit moves the order from Draft to Pending and displays Submitted. Because the amount is greater than 1,000, approve moves it to Manual Review and creates a review task. The clear event then moves it to Approved and reserves stock. Finally, dispatch moves it to Shipped and sends the notice.

Events must be valid in the current state. For example, dispatch cannot ship an order while it remains in Manual Review.

• Reserving stock during high-value approval incorrectly applies the action from the amount <= 1,000 branch.
• Dispatching before clearance is invalid in Manual Review, so it cannot send the notice or reach Shipped.
• Clearing while Pending is invalid; the subsequent approval enters Manual Review, where dispatch is also invalid.

Question 7

Topic: Managing Testing

A team performs weekly product risk monitoring during system testing.

Monitoring evidence:

• Known risk: peak-load checkout latency could cause abandoned purchases.
• Mitigation: prioritize load tests and deploy a caching change.
• Success indicator: 95th-percentile response time <= 2.5 seconds.
• Latest result: 2.1 seconds under the defined peak load.
• New observation: payment retries rose from 0.3% to 2.8% after an interface change, indicating possible duplicate-charge exposure not recorded in the current product risk information.

Which interpretation and response best reflect risk monitoring?

Options:

• A. Record the latency mitigation as currently effective, assess retries as an emerging product risk, and adjust risk control.

• B. Record the latency mitigation as ineffective, treat retries as supporting evidence, and expand the existing performance controls.

• C. Record the latency mitigation as complete, manage retries only as a defect, and keep product risk information unchanged.

• D. Keep the known risk status unchanged, await confirmed duplicate charges, and then assess retries as a product risk.

Best answer: A

Explanation: Risk monitoring provides continuous oversight of product risks and their controls. The measured latency satisfies the stated success indicator, so current evidence supports that the mitigation is effective; it does not prove the risk has permanently disappeared. The retry increase concerns a different failure mode and possible impact that are absent from the current risk information. It should be treated as an emerging product risk, analyzed for likelihood and impact, and used to update risk status, testing priorities, or other controls as warranted. A new risk does not automatically invalidate an effective mitigation for an existing risk, and analysis should not wait until customer harm occurs.

• Treating retries as proof of ineffective latency mitigation incorrectly combines separate failure modes and controls.
• Defect-only handling overlooks the need to update product risk information when new exposure emerges.
• Waiting for confirmed duplicate charges defeats the preventive purpose of identifying and analyzing emerging risks.

Question 8

Topic: Fundamentals

Developers test their own changes before integration. A tester outside the development team later finds cross-component workflow defects that the developers missed. During the retrospective, participants report that the tester is excluded from feature discussions and that defect discussions are becoming blame-focused.

Which interpretation is best supported by this situation?

Options:

• A. The separate perspective can replace developer testing, while duplicated execution can waste effort and delay feedback.

• B. The separate perspective exposes different defects, while social separation can cause blame and poor communication.

• C. The separate perspective makes release decisions objective, while early collaboration can compromise the tester’s independence.

• D. The separate perspective transfers quality accountability, while limited implementation knowledge can reduce component coverage.

Best answer: B

Explanation: Independent testing can improve defect detection because testers may have different backgrounds, assumptions, and technical perspectives from those who created the software. In this situation, that different perspective helped reveal cross-component workflow defects missed by the developers. However, independence does not require organizational or social isolation. Excluding the tester from feature discussions and allowing defect discussions to become blame-focused can weaken communication, create an adversarial relationship, and reduce shared responsibility for quality. The appropriate balance preserves an independent testing perspective while supporting close collaboration with the development team.

• Replacing developer testing is inappropriate because independent testing complements rather than eliminates testing by developers.
• Transferring quality accountability conflicts with the whole-team responsibility for quality.
• Early collaboration does not remove independence; testers can collaborate while retaining a different perspective.

Question 9

Topic: Test Analysis and Design

An online store uses these discount rules. A Guest cannot enter a promotion code; such combinations are infeasible. In the table, “any total” means basket total does not affect that rule.

Which test set covers every feasible rule exactly once with the expected results?

Options:

• A. (Guest, $80, No -> 0%); (Guest, $120, No -> 5%); (Member, $80, No -> 0%); (Member, $120, No -> 10%); (Guest, $80, Yes -> 20%)

• B. (Guest, $120, No -> 5%); (Member, $80, No -> 0%); (Member, $120, No -> 10%); (Member, $80, Yes -> 20%); (Member, $120, Yes -> 20%)

• C. (Guest, $80, No -> 0%); (Guest, $120, No -> 5%); (Member, $80, No -> 0%); (Member, $120, No -> 10%); (Member, $80, Yes -> 20%)

• D. (Guest, $80, No -> 0%); (Guest, $120, No -> 5%); (Member, $80, No -> 10%); (Member, $120, No -> 10%); (Member, $80, Yes -> 20%)

Best answer: C

Explanation: Decision table tests should cover each feasible rule. The four no-promotion rules remain distinct because account type and basket-total partition determine the discount. The promotion rule requires only one Member test: “any total” makes basket total irrelevant to that rule, so testing both $80 and $120 would repeat the same rule. Guest-with-promotion combinations are excluded because the specification declares them infeasible.

An irrelevant condition may take different values without changing a rule’s action. An infeasible combination cannot occur within the specified model and therefore does not represent a feasible rule to cover.

• Testing both Member totals with a promotion repeats rule 5 and leaves the Guest-below-$100 rule uncovered.
• Testing a Guest with a promotion uses an infeasible combination and fails to cover the feasible Member-promotion rule.
• Expecting 10% for a Member below $100 incorrectly extends total irrelevance beyond the promotion rule.

Question 10

Topic: Testing in the Lifecycle

An organization will retire its payroll system after moving legally retained records to an archive. Records must remain retrievable for seven years. The export format and archive retrieval service are new, while payroll calculations are unchanged and will not operate after retirement. A limited test window requires risk-based selection; incorrect mapping or failed restoration has high impact.

Which maintenance-testing scope is most appropriate?

Options:

• A. Test retirement steps, archive restoration and retrieval, and changed export and retrieval paths.

• B. Test retirement steps, archive export totals, and retrieval after a retention request occurs.

• C. Test the changed export format and archive retrieval service through interface-level regression.

• D. Test retirement steps, archive restoration and retrieval, and broad regression of payroll calculations.

Best answer: A

Explanation: Maintenance testing can be triggered by modification, planned retirement, or archiving. Its scope should reflect the risks introduced by the change and the activities required during retirement. Here, the new export format and retrieval service need tests against their specified behavior. Regression testing should cover any existing behavior affected by those changes; it is not the name for every test of a newly introduced path. The retirement steps also need verification because the legacy system will be shut down. The archive must support restoration and retrieval for the required seven-year period, so those capabilities need testing before retirement. Broad testing of unchanged payroll calculations has lower relevance within the limited window, while interface testing alone does not demonstrate end-to-end restoration.

• Broad calculation regression spends the limited window on unchanged functions that will not operate after retirement.
• Deferring retrieval leaves the retention requirement unverified before the legacy system is shut down.
• Interface-level regression does not verify the retirement process or prove that archived records can be restored end to end.

Question 11

Topic: Test Tools

A team needs evidence that response-time targets are met under concurrent use, automatic test feedback after each build, and identical test stacks that can run in parallel. It selects a performance-testing tool, a delivery-pipeline orchestrator, and containers.

Which interpretation best explains how these tools support testing?

Options:

• A. The performance tool provisions parallel stacks; the orchestrator creates concurrent workload; containers assess response-time targets.

• B. The performance tool creates workload and measurements; the orchestrator triggers suites and reports status; containers provide repeatable parallel environments.

• C. The performance tool replays transactions; the orchestrator provisions container instances; containers aggregate pipeline test results.

• D. The performance tool checks business outputs; the orchestrator isolates runtime dependencies; containers locate response-time bottlenecks.

Best answer: B

Explanation: Non-functional testing tools evaluate quality characteristics such as performance efficiency. A performance-testing tool can generate concurrent activity and collect measurements such as response times. A delivery-pipeline orchestrator triggers test suites after builds and makes their status available for rapid feedback. Environment tools such as containers package runtime dependencies, helping teams create consistent test instances and scale them for parallel execution.

Although a pipeline can provision containers, containers do not generate test reports or determine whether performance targets have been met. Those conclusions come from the relevant test tools and their results.

• Checking business outputs primarily concerns functional testing and misassigns environment isolation and performance analysis.
• Provisioning stacks and generating workload are reversed; containers support environments, while performance tools produce load and measurements.
• Pipeline orchestration may provision containers, but containers do not aggregate test results for pipeline feedback.

Question 12

Topic: Managing Testing

A test manager prioritizes tests by selecting the test that covers the most currently uncovered items, then recalculating after each selection. All items have equal importance, and I1 is already covered.

Which test execution order follows this prioritization rule?

Options:

• A. T2, T4, T1, T3

• B. T2, T3, T4, T1

• C. T2, T4, T3, T1

• D. T4, T2, T3, T1

Best answer: C

Explanation: Additional coverage must be recalculated after every selected test. Initially, T2 adds seven uncovered items, more than any other test. After selecting T2, T4 adds four new items (I9 through I12), while T3 adds three and T1 adds two. After selecting T4, T3 adds I13 and I14, whereas T1 adds only I15. Finally, T1 adds the remaining uncovered item.

The priority is determined by changing marginal coverage, not each test’s original total coverage.

• Selecting T3 second overlooks that T4 adds four uncovered items after T2, while T3 adds three.
• Starting with T4 ignores that T2 has the greatest initial additional coverage.
• Selecting T1 third overlooks that T3 adds two uncovered items at that stage, while T1 adds one.

Question 13

Topic: Fundamentals

A tester evaluates a checkout requirement. First, the tester identifies “payment with an expired card” as something to test. Next, the tester specifies the card data, expected rejection message, cart precondition, and payment-gateway simulator needed for execution.

How should these activities be classified?

Options:

• A. Both are test analysis because they refine testable requirement information.

• B. The first is test analysis; the second is test design.

• C. The first is test design; the second is test analysis.

• D. Both are test design because they produce information supporting test execution.

Best answer: B

Explanation: Test analysis determines what should be tested by evaluating the test basis and identifying test conditions. Here, payment with an expired card is the test condition. Test design determines how to test those conditions. It elaborates coverage items and test cases and identifies requirements for test data, the test environment, and other testware. The card data, expected result, precondition, and gateway simulator therefore belong to test design.

The key distinction is the transition from identifying a test target to defining how that target will be tested.

• Reversing the activities conflicts with analysis identifying test conditions before design elaborates them into test cases.
• Classifying both as analysis confuses supporting execution details with identifying what needs testing.
• Classifying both as design overlooks that the initial test condition is an output of test analysis.

Question 14

Topic: Test Analysis and Design

An inherited pricing service has source code and an executable build, but no complete record of its intended pricing rules. Testers inspect control flow during review, design tests from the code, and achieve 100% statement and branch coverage.

Which interpretation of structural testing is best supported?

Options:

• A. It can establish exhaustive execution-path coverage, but cannot confirm that those paths meet stakeholder needs.

• B. It can assess the implemented structure, but cannot expose required behavior absent from the implementation.

• C. It can establish coverage of required behavior, but cannot confirm the correctness of observed outputs.

• D. It cannot assess the implementation meaningfully until requirements define the intended behavior of every branch.

Best answer: B

Explanation: Structural testing derives tests and coverage from the software’s internal structure. Source code can therefore support static review, test design, and objective statement or branch coverage even when requirements are incomplete. However, these measures describe only what exists in the implementation. A missing pricing rule produces no corresponding statements or branches, so full structural coverage cannot detect its absence. Full statement and branch coverage also does not prove output correctness or exhaustive path coverage.

Structural testing remains valuable with incomplete requirements, but it must be complemented by specification-based and stakeholder-focused testing to identify omitted behavior.

• Treating implementation coverage as required-behavior coverage overlooks rules that may never have been coded.
• Declaring structural assessment unusable ignores that code structure can still be reviewed and covered directly.
• Equating branch coverage with exhaustive path coverage ignores combinations and repetitions of branches across paths.

Question 15

Topic: Static Testing

An organization is preparing a review of a requirements specification. Responsibilities must be assigned for deciding what will be reviewed, providing staff and time, choosing participants, and arranging when and where the review occurs. Which assignment is consistent with CTFL review responsibilities?

Options:

• A. Management selects review scope and provides resources; the review leader selects participants and organizes the review.

• B. The review leader selects review scope and provides resources; management selects participants and organizes the review.

• C. The review leader selects review scope and participants; management provides resources and organizes the review.

• D. Management selects review scope and participants; the review leader provides resources and organizes the review.

Best answer: A

Explanation: Management and the review leader operate at different responsibility levels. Management decides which work products will be reviewed and provides necessary resources, such as staff and time. The review leader takes overall responsibility for the specific review, decides who will participate, and organizes when and where it will occur.

The key distinction is that management establishes review scope and resources, while the review leader organizes the review’s execution.

• Assigning scope and resources to the review leader reverses the two roles.
• Giving participant selection to management shifts an organizational duty away from the review leader.
• Giving review logistics to management incorrectly transfers the review leader’s organizational responsibility.

Question 16

Topic: Managing Testing

A team must schedule four tests in four consecutive slots using one shared environment. A prerequisite must finish in an earlier slot. In each slot, the team selects the highest-priority test that is executable. Priorities rank Critical, High, then Medium.

Which test order meets these conditions?

Options:

• A. Login baseline; Accessibility; Refund; Checkout

• B. Accessibility; Login baseline; Checkout; Refund

• C. Login baseline; Checkout; Accessibility; Refund

• D. Login baseline; Accessibility; Checkout; Refund

Best answer: D

Explanation: An executable schedule first filters tests by completed prerequisites and available resources, then applies priority among the runnable tests. In slot 1, Login baseline and Accessibility are runnable, so the higher-priority Login baseline runs first. Checkout then has its prerequisite satisfied, but its simulator is unavailable in slot 2, making Accessibility the runnable test for that slot. The simulator becomes available in slot 3, allowing Checkout to run and thereby enabling Refund for slot 4.

Raw priority cannot override a dependency or unavailable resource, but it determines the order when multiple tests are executable.

• Scheduling Accessibility first uses a valid resource window but ignores the higher-priority runnable Login baseline.
• Scheduling Checkout second violates the payment simulator’s availability window and pushes Accessibility beyond its specialist window.
• Scheduling Refund before Checkout reverses the explicit prerequisite relationship.

Question 17

Topic: Test Analysis and Design

A product owner, developer, and tester review this story:

As a shopper, I want useful search results so that I can find products quickly.

They initially disagree about typo handling and the meaning of “quickly.” Together they add these acceptance criteria:

• Results appear within 2 seconds under the stated load.
• A misspelled product name produces a suggested correction.

They intentionally leave the technical solution open. Which interpretation best explains how INVEST improved the story?

Options:

• A. Independent preserves solution freedom, while Small makes concise criteria separately executable.

• B. Valuable supports benefit-focused clarification, while Estimable makes numerical criteria verifiable.

• C. Negotiable supports collaborative clarification, while Testable requires observable acceptance criteria.

• D. Estimable resolves differing interpretations, while Valuable confirms behaviors through examples.

Best answer: C

Explanation: INVEST describes user stories as Independent, Negotiable, Valuable, Estimable, Small, and Testable. A Negotiable story invites conversation rather than prescribing a fixed solution. Here, the product owner, developer, and tester resolve their different interpretations while leaving implementation details open. A Testable story has acceptance criteria with observable pass-or-fail outcomes, such as a specified response time and expected typo behavior.

The collaboration creates shared understanding, and the resulting acceptance criteria provide a basis for testing the story.

• Value versus verification: User benefit supports Valuable, but Estimable concerns effort assessment rather than making numerical criteria verifiable.
• Independence versus freedom: Leaving implementation open reflects Negotiable; Independent concerns dependencies between stories.
• Estimation versus agreement: Estimable supports effort estimation, while examples confirm behavior through Testable acceptance criteria rather than Valuable.

Question 18

Topic: Testing in the Lifecycle

A confirmed defect fix changes locale-selection logic in a shared DateParser component. Change-impact analysis finds:

• Booking and Billing call DateParser directly.
• Monthly Reporting consumes dates produced by Billing.
• Loyalty has no dependency on these components.
• The modified logic executes in both the en-US test environment and the en-GB production-like environment.

The team needs the smallest regression scope justified by this analysis. Which scope should it select?

Options:

• A. Run all DateParser, Booking, Billing, Monthly Reporting, and Loyalty tests in both environments.

• B. Run relevant DateParser, Booking, Billing, and Monthly Reporting tests in both environments.

• C. Run relevant DateParser, Booking, Billing, and Monthly Reporting tests only in the production-like environment.

• D. Run relevant DateParser, Booking, and Billing tests in both environments.

Best answer: B

Explanation: Change-impact analysis traces where a modification can cause adverse effects. It considers the changed component, direct dependencies, indirect downstream dependencies, and relevant environment or configuration differences. Here, regression testing should cover DateParser, Booking and Billing, plus Monthly Reporting because Billing-produced dates flow into it. Both environments are included because each executes the modified logic under a different locale configuration.

Confirmation has already established that the specific defect was fixed. Regression testing now checks for unintended effects, using the impact analysis to focus coverage rather than testing only the modified component or indiscriminately running every test.

• Limiting coverage to direct callers overlooks the identified indirect effect on Monthly Reporting.
• Testing only the production-like environment omits an affected locale configuration that also executes the changed logic.
• Including Loyalty and every workflow exceeds the smallest justified scope because Loyalty has no identified dependency.

Question 19

Topic: Fundamentals

A requirement states:

Apply a discount only when the order total is greater than $100.

A developer interprets this as “at least $100” and implements total >= 100. Testing produces no discount for $80, but produces a discount for $100 when none was expected.

Which causal account is supported?

Options:

• A. The interpretation is a human error; >= is a defect; the unexpected discount is a failure.

• B. The interpretation is a failure; >= is a defect; the unexpected discount is a human error.

• C. The interpretation is a human error; >= is a failure; the unexpected discount is a defect.

• D. The interpretation is a defect; >= is a human error; the unexpected discount is a failure.

Best answer: A

Explanation: A human error is an incorrect human action or decision. Here, the developer misinterpreted “greater than” as “at least.” That error introduced a defect into the code: the >= operator does not implement the stated requirement. When the defective condition executes for an order total of $100, the system produces an incorrect observable result, which is a failure.

The successful $80 test does not mean the code lacks a defect. A defect may cause failures only for particular inputs or conditions. Failures can also result from environmental conditions, although the evidence here directly connects the observed failure to the code defect.

• Treating the interpretation as a defect confuses the human action with the resulting imperfection in the code.
• Treating >= as a failure confuses a defect in a work product with its observable runtime effect.
• Treating the unexpected discount as a human error misclassifies system behavior as a human action.

Question 20

Topic: Test Analysis and Design

A component’s control-flow graph contains the five labeled transfers shown. The labels indicate which transfers a test suite exercised.

Which interpretation of branch coverage is supported by the graph?

Options:

• A. 80%, because four of the five control-flow nodes were visited.

• B. 100%, because every transfer along the executed route was exercised.

• C. 50%, because one of the two conditional transfers was exercised.

• D. 60%, because three of the five labeled transfers were exercised.

Best answer: D

Explanation: Branch coverage uses control-flow transfers as coverage items. A transfer can be conditional, such as t2 and t3, or unconditional, such as t1, t4, and t5. The graph therefore contains five branches. The suite exercised t1, t2, and t4, so its branch coverage is \(3/5 \times 100\% = 60\%\).

Visiting four nodes does not change this calculation because node or statement coverage is distinct from branch coverage. The denominator also includes every branch in the graph, not merely those on the executed route.

• The 50% result incorrectly excludes the three unconditional transfers from branch coverage.
• The 80% result measures visited nodes rather than exercised control-flow transfers.
• The 100% result incorrectly restricts the denominator to the route that was executed.

Question 21

Topic: Managing Testing

A system test cycle reaches its budget limit on the planned release date. Two tests covering high product risks remain unexecuted, so the agreed exit criteria are not met. Release governance assigns acceptance of residual business risk to the business sponsors; the test manager reports results and recommends actions.

Which decision correctly supports stopping testing?

Options:

• A. Stop only after additional resources allow every original exit criterion to be satisfied.

• B. Stop after the business sponsors approve scheduling the remaining high-risk tests for a later test cycle.

• C. Stop after the test manager reviews the unmet criteria and accepts the identified residual product risk.

• D. Stop after the business sponsors review the unmet criteria and accept the identified residual product risk.

Best answer: D

Explanation: Exit criteria support an informed completion decision, but exhausting time or budget does not prove that the quality objectives were achieved. The test team should report the unmet criteria, unexecuted high-risk tests, coverage gaps, unresolved defects, and resulting residual product risk. The stakeholders responsible for accepting that risk then decide whether it is acceptable or plans must change.

In this scenario, the business sponsors hold that authority, while the test manager reports evidence and recommends actions. Deferring tests does not itself establish acceptance of the current risk. Testing may stop with unmet exit criteria when the responsible stakeholders understand and accept the residual risk.

• Test manager acceptance exceeds the authority assigned to the test manager in this scenario; the business sponsors must accept the remaining product risk.
• Deferred testing changes the schedule but does not establish that the business sponsors understand and accept the current residual risk.
• Mandatory continuation treats exit criteria as inflexible, although the responsible stakeholders may accept residual risk when constraints prevent further testing.

Question 22

Topic: Fundamentals

A team uses this traceability extract to assess requirement test coverage and residual product risk.

Which interpretation is supported by the extract?

Options:

• A. R1 and R2 have executed-test evidence, R3 has a coverage gap, and failed T2 indicates that P1 may remain as residual risk.

• B. R2 has executed-test evidence, R1 lacks it because T2 failed, R3 has a coverage gap, and P1 may remain as residual risk.

• C. R1 and R2 have executed-test evidence, R3 is covered by its product-risk link, and failed T2 indicates that P1 may remain as residual risk.

• D. R1 and R2 have executed-test evidence, R3 has a coverage gap, and passed T1 indicates that P1 no longer remains as residual risk.

Best answer: A

Explanation: Traceability supports two related views. Requirement-to-test links show whether requirements have test and execution evidence; a failed result does not remove that evidence. Risk-to-requirement, test, and result links show which product risks were exercised and whether the results support their mitigation.

R1 and R2 have linked, executed tests. R3 has no linked test, so its requirement coverage is not demonstrated. T2’s failure is connected through R1 to P1, so P1 remains relevant when evaluating residual risk, even though T1 passed. A passing test contributes evidence but does not prove that a product risk has been eliminated. Coverage and residual-risk status therefore use the same traceability chain but answer different questions.

• Treating R1 as uncovered confuses test execution evidence with test outcomes; T2 was executed even though it failed.
• Removing P1 after T1 passes ignores the failed test linked to the same requirement and risk.
• A requirement-to-risk link identifies exposure but does not replace the missing requirement-to-test link for R3.

Question 23

Topic: Testing in the Lifecycle

Three teams describe their test-first practices:

• Alpha: Writes a low-level test before production code, makes it pass, then refactors.
• Beta: Agrees on acceptance criteria and derives acceptance tests before implementation.
• Gamma: Describes expected behavior in stakeholder-readable Given/When/Then scenarios.

Which mapping of practices to approaches is supported?

Options:

• A. Alpha: BDD; Beta: ATDD; Gamma: TDD

• B. Alpha: TDD; Beta: BDD; Gamma: ATDD

• C. Alpha: ATDD; Beta: TDD; Gamma: BDD

• D. Alpha: TDD; Beta: ATDD; Gamma: BDD

Best answer: D

Explanation: Test-driven development (TDD) begins with a low-level test, adds enough production code to pass it, and then refactors. Acceptance test-driven development (ATDD) begins with agreed acceptance criteria and derives acceptance tests before implementation. Behavior-driven development (BDD) describes expected behavior in language understandable to stakeholders, commonly using Given/When/Then scenarios.

ATDD and BDD can both involve collaboration and readable examples, but their defining emphasis differs: ATDD starts from acceptance criteria, while BDD emphasizes behavior descriptions.

• Swapping ATDD and BDD overlooks that Beta starts from acceptance criteria, while Gamma explicitly uses behavior scenarios.
• Assigning ATDD to Alpha confuses acceptance-level criteria with TDD’s low-level test-code-refactor cycle.
• Assigning BDD to Alpha and TDD to Gamma reverses the defining roles of low-level tests and stakeholder-readable behavior.

Question 24

Topic: Test Analysis and Design

A control accepts only whole-number settings from 0 through 100. Its ordered equivalence partitions are:

• Low: 0-9
• Standard: 10-89
• High: 90-100

Apply three-value boundary value analysis to every partition boundary, including the domain endpoints. Exclude values outside the supported domain and remove duplicates. Which test-value set is required?

Options:

• A. {0, 1, 9, 10, 11, 89, 90, 91, 99, 100}

• B. {0, 1, 8, 9, 10, 11, 88, 89, 90, 91, 99, 100}

• C. {0, 1, 8, 9, 10, 88, 89, 90, 99, 100}

• D. {-1, 0, 1, 8, 9, 10, 11, 88, 89, 90, 91, 99, 100, 101}

Best answer: B

Explanation: Three-value boundary value analysis uses each boundary value and its two nearest neighbors. The partition boundaries are 0, 9, 10, 89, 90, and 100. Values below 0 or above 100 are excluded because the supported input domain is limited to 0 through 100.

The boundary neighborhoods are combined and duplicates removed. For example, analyzing both 9 and 10 produces 8, 9, 10, and 11 after deduplication. Similarly, analyzing 89 and 90 produces 88, 89, 90, and 91. At the domain endpoints, only 0, 1, 99, and 100 remain valid test inputs.

Each endpoint of adjacent partitions must be analyzed as a separate boundary value.

• Testing only around 10 and 90 omits 8 and 88, which are required neighbors of boundaries 9 and 89.
• Including -1 and 101 ignores the stated restriction that inputs must remain within the supported domain.
• Omitting 11 and 91 fails to test both nearest neighbors of boundaries 10 and 90.

Question 25

Topic: Managing Testing

A test team has identified four product risks. Priority follows the matrix risk level only: High precedes Medium, which precedes Low. Risks at the same level remain tied because no secondary criterion is defined.

Risk-level matrix:

Risk assessment:

Which prioritization is supported by this assessment?

Options:

• A. R2 and R4 tie first; R1 and R3 tie next.

• B. R1 and R3 tie first; R2 and R4 tie next.

• C. R2 and R3 tie first; R1 and R4 tie next.

• D. R2 and R3 tie first; R4 ranks above R1.

Best answer: C

Explanation: Product risk assessment evaluates each identified risk’s likelihood and impact, then uses the defined method to determine its risk level. The matrix maps R1 and R4 to Medium, while R2 and R3 map to High. Because prioritization uses only the matrix level and no tie-breaker is defined, the High risks precede the Medium risks, and risks within each level remain tied.

Prioritizing by likelihood or impact alone ignores one dimension of the assessment. Similarly, ranking risks within the same level would require an additional criterion not provided here.

• Grouping R1 and R3 first uses likelihood alone and ignores their different impact ratings.
• Grouping R2 and R4 first uses impact alone and ignores their different likelihood ratings.
• Ranking R4 above R1 invents a tie-breaker even though both receive a Medium risk level.

Questions 26-40

Question 26

Topic: Static Testing

A team must investigate four concerns:

• The specification gives session timeouts of both 15 and 30 minutes.
• An acceptance criterion says pages must “load quickly.”
• The running build must respond within 2 seconds under the stated load.
• The running service must recover within 60 seconds after a process failure.

Which allocation uses static and dynamic testing where each is better suited?

Options:

• A. Static: response time and recovery; dynamic: conflicting timeouts and vague wording.

• B. Static: conflicting timeouts and recovery; dynamic: vague wording and response time.

• C. Static: vague wording and response time; dynamic: conflicting timeouts and recovery.

• D. Static: conflicting timeouts and vague wording; dynamic: response time and recovery.

Best answer: D

Explanation: Static testing examines work products without executing software, so it is well suited to finding defects such as ambiguous wording, contradictions, omissions, and inconsistencies in requirements. The conflicting timeout values and the unmeasurable phrase “load quickly” are therefore best exposed through review.

Dynamic testing executes the software and observes its behavior. Meeting a response-time target under load concerns performance efficiency, while recovering after a process failure concerns reliability. Both require evidence from a running system.

Reviewing a runtime target can assess whether it is clearly specified, but execution is needed to determine whether the product actually meets it.

• Assigning response time to static testing confuses reviewing a performance requirement with measuring the running product’s performance.
• Assigning recovery to static testing cannot demonstrate the service’s behavior after an actual or simulated failure.
• Assigning requirement conflicts to dynamic testing may reveal uncertain results, but execution cannot resolve contradictions in the source specification.

Question 27

Topic: Test Analysis and Design

A rating field accepts values with one decimal place from 1.0 through 5.0, inclusive. Values outside this range must be rejected.

The implementation incorrectly accepts a value only when rating > 1.0 and rating < 5.0.

Available test values are 0.9, 1.0, 1.1, 4.9, 5.0, and 5.1. Which pair of tests, with expected outcomes, will expose both boundary faults?

Options:

• A. 1.1 accepted; 4.9 accepted

• B. 0.9 rejected; 5.1 rejected

• C. 1.0 accepted; 5.0 accepted

• D. 0.9 rejected; 5.0 accepted

Best answer: C

Explanation: The specification includes both endpoints, but the implementation uses strict greater-than and less-than comparisons. Therefore, the implementation disagrees with the specification exactly at 1.0 and 5.0: both should be accepted but will be rejected.

Values immediately outside the range are rejected by both the specification and implementation. Values immediately inside the range are accepted by both. Although such adjacent values are useful in three-value boundary value analysis, they do not expose these particular faults. Testing both exact endpoints is necessary to reveal both incorrect comparisons.

• Testing 0.9 and 5.1 reveals nothing because both the specification and implementation reject them.
• Testing 1.1 and 4.9 reveals nothing because both the specification and implementation accept them.
• Testing 0.9 and 5.0 exposes only the faulty upper-bound comparison, leaving the lower fault undetected.

Question 28

Topic: Fundamentals

An online store team reviews defect locations from three releases. Checkout contained 45%, 52%, and 48% of recorded defects. Other components also contained defects. The current release has comparable change scope across components, with no evidence that invalidates the pattern.

How should the team use this information when planning testing?

Options:

• A. Allocate more effort to checkout initially, maintain coverage elsewhere, and recalibrate using current results.

• B. Allocate roughly half the effort to checkout throughout, treating the historical percentages as the expected distribution.

• C. Allocate less effort to checkout initially, assuming prior testing has already exposed most of its weak areas.

• D. Allocate equal effort to each component initially, disregarding historical concentrations until current defects are found.

Best answer: A

Explanation: Defect clustering is the observation that a relatively small number of components often contain a large proportion of discovered defects. The repeated concentration in checkout is useful evidence of higher defect proneness, so it should guide additional testing attention there. However, clustering is not a fixed numerical rule and does not predict the exact distribution of future defects. Other components still require suitable coverage, and priorities should be updated as current-release results provide new evidence.

The key is to use clustering as a risk indicator rather than as a guaranteed allocation formula.

• A fixed half-effort allocation incorrectly converts historical observations into a stable numerical distribution.
• Equal allocation discards relevant evidence that checkout has repeatedly contained more defects.
• Reducing checkout effort assumes earlier testing exhausted its defects, which is unsupported by the observed pattern.

Question 29

Topic: Managing Testing

Six weeks ago, checkout test T-17 failed. Controlled baseline B42 identifies:

• Application build 8.4.2
• Browser/container image E19
• Test suite 5.6
• Data snapshot D11

Today, a tester retrieves T-17 from suite 5.6 but runs it against build 8.5, image E22, and refreshed data. The test passes. Which interpretation is supported?

Options:

• A. The rerun does not reproduce B42 because three controlled elements were not restored.

• B. The rerun would reproduce B42 by restoring build 8.4.2 while retaining current supporting elements.

• C. The rerun reproduces B42 because the same test script preserves the test conditions.

• D. The rerun supersedes B42 because current versions provide evidence about the latest configuration.

Best answer: A

Explanation: A controlled baseline identifies the versions of all configuration items needed to recreate tested conditions. Here, B42 includes the test object, test environment, testware, and test data. The tester restored only the test script, while the application build, environment image, and data changed. Therefore, the passing result cannot be directly compared with the earlier failure as a reproduction of B42.

Restoring one file is insufficient when other baseline elements can affect behavior. Reproducibility depends on being able to identify and restore the complete relevant configuration, although rerunning the latest configuration may still provide useful current-product evidence.

• Script alone fails because unchanged test logic does not recreate the application, environment, or data conditions.
• Build alone fails because environment and data differences can also change the observed result.
• Latest configuration provides current evidence but does not recreate the conditions associated with the earlier result.

Question 30

Topic: Testing in the Lifecycle

A team performs two testing activities:

• During component integration, testers derive equivalence partitions from a published interface contract without inspecting the implementation.
• During acceptance testing, testers inspect the implementation’s control-flow graph and select tests to execute every branch while checking business outcomes.

Based on how the tests are derived, which interpretation is supported?

Options:

• A. The integration activity is white-box; the acceptance activity is black-box.

• B. The integration activity is black-box; the acceptance activity is white-box.

• C. Both activities are black-box because both verify externally observable results.

• D. Both activities are white-box because both use a model to derive tests.

Best answer: B

Explanation: Black-box testing is based on specifications, while white-box testing is based on internal structure. These classifications depend on how test conditions are derived, not on the test level. Equivalence partitions derived from an interface contract use specified behavior, so component integration testing can be black-box. Tests selected from implementation control flow to exercise branches use internal structure, so acceptance testing can be white-box.

Equivalence partitioning and branch testing are the specific test-design techniques that provide evidence for these broader classifications.

• Reversing the classifications incorrectly relies on common test-level associations rather than the stated test basis.
• Checking observable results does not make the acceptance activity black-box because test selection uses internal branches.
• Using a model does not make the integration activity white-box because the interface contract specifies behavior rather than implementation structure.

Question 31

Topic: Test Tools

A test team is considering a significant license purchase for a proprietary automation platform. Its proof of concept passes on the current browser using an open-source adapter.

Production must use the next browser release. The adapter’s repository is archived, and its last release does not support that browser. The vendor maintains the platform, but not the adapter.

Which assessment is best supported?

Options:

• A. The successful proof establishes suitability, leaving only routine script maintenance risk.

• B. The platform’s vendor support controls compatibility risk across the complete automation toolchain.

• C. The unmaintained dependency could break compatibility and strand the platform investment.

• D. The adapter’s available source preserves maintainability, leaving mainly internal training risk.

Best answer: C

Explanation: Automation investment depends on the entire toolchain remaining maintained and compatible. The proof demonstrates only that the current platform, adapter, and browser combination works. Because the required browser is unsupported by an archived adapter, this dependency could prevent future execution and reduce the value of the licenses and existing scripts.

Vendor maintenance of the proprietary platform does not automatically maintain its open-source dependencies. Similarly, access to source code permits a team to fork an abandoned project but does not guarantee the skills, time, or effort needed to keep it compatible. Tool suitability therefore requires continuing human evaluation of lifecycle and dependency risks.

• Current proof results cover the existing configuration, not compatibility with the required future browser.
• Platform vendor support does not extend to the community adapter that the vendor does not maintain.
• Available source code permits internal maintenance but does not ensure that resources or compatible updates will exist.

Question 32

Topic: Test Analysis and Design

A tester conducts a 60-minute session under the charter: “Explore CSV import handling of valid and invalid delimiters.” After observing different behavior for quoted and unquoted delimiters, the tester designs and executes additional variants, records observations, and discusses the results during the debrief.

Which interpretation best explains this session?

Options:

• A. Execution produces learning that immediately guides further design, while the charter and time box keep the evolving work focused.

• B. Designing systematic variants turns the activity into scripted testing, even when selection of those variants responds to observations.

• C. The charter determines the tests before execution, while observations are recorded for reporting rather than used to redirect design.

• D. Execution produces learning for the debrief, while further design should wait for a new session with a revised charter.

Best answer: A

Explanation: Exploratory testing treats learning, test design, and test execution as mutually supporting activities rather than separate sequential phases. Executing the initial CSV tests reveals a meaningful distinction between quoted and unquoted delimiters. The tester uses this learning to design and run additional variants immediately, allowing each result to influence what is tested next.

The session remains controlled because the charter defines its mission, the time box limits effort, observations provide a record, and the debrief consolidates findings and follow-up work. Exploratory testing may also incorporate systematic test techniques; using such techniques does not make the session scripted. The charter guides exploration rather than prescribing every test in advance.

• Deferring new design until another session unnecessarily breaks the feedback loop between learning, design, and execution.
• Using systematic variants does not make testing scripted when observations continue to guide test selection.
• Treating the charter as a fixed test procedure confuses a session mission with predefined test cases.

Question 33

Topic: Fundamentals

A tester suspects a payment service caused an intermittent checkout failure because that service had defects previously. A developer believes a recent refactoring makes this unlikely. The available evidence shows only a timeout at the service boundary; the root cause is unknown.

Which approach best supports a constructive, bias-aware discussion?

Options:

• A. Present the timeout to another tester, obtain an independent conclusion, and communicate the resulting consensus to the developer.

• B. Present the timeout as observed evidence, identify the suspected cause as a hypothesis, and invite evidence that could confirm or refute it.

• C. Present the timeout and defect history, recommend the payment service as the probable cause, and request evidence supporting another explanation.

• D. Present the timeout, ask the developer to interpret the refactoring, and adopt the technical owner’s conclusion to prevent further disagreement.

Best answer: B

Explanation: Constructive communication focuses on objective observations rather than blaming people or presenting assumptions as facts. Here, the timeout is evidence, but the payment service is only one possible cause. Labeling it as a hypothesis keeps the discussion factual and invites collaboration. Actively seeking evidence that could both support and challenge the hypothesis counters confirmation bias, which can cause people to favor information consistent with their existing beliefs.

Prior defect history may guide investigation, but it does not establish the current root cause. Likewise, technical authority or agreement among testers does not replace balanced analysis and open discussion with relevant team members.

• Calling the payment service the probable cause on this evidence and requesting only alternative explanations gives the initial hypothesis preferential treatment. The stronger approach also seeks evidence that could refute it.
• Deferring to the technical owner substitutes authority for evaluation of the available evidence.
• Building tester consensus may reinforce shared assumptions and excludes the developer from the initial investigation.

Question 34

Topic: Managing Testing

A test manager has these effort estimates for a test activity:

• Optimistic, a: 20 person-days
• Most likely, m: 32 person-days
• Pessimistic, b: 50 person-days

The specified method uses E = (a + 4m + b) / 6 and SD = (b - a) / 6. Which result and interpretation are supported?

Options:

• A. E = 33 and SD = 30; 3-63 person-days is an estimate, not a guaranteed bound.

• B. E = 33 and SD = 5; 28-38 person-days is a guaranteed bound for actual effort.

• C. E = 34 and SD = 5; 29-39 person-days is an estimate, not a guaranteed bound.

• D. E = 33 and SD = 5; 28-38 person-days is an estimate, not a guaranteed bound.

Best answer: D

Explanation: The weighted three-point method gives the most likely estimate four times the weight of each extreme. Substitution gives \(E=(20+4\times32+50)/6=33\) person-days. The stated uncertainty measure is \(SD=(50-20)/6=5\) person-days. Therefore, \(E\pm SD\) corresponds to 28-38 person-days. This range expresses the estimate together with its uncertainty; it does not guarantee that actual effort will fall within those limits, nor does it establish an unstated confidence interval. Equal weighting would use a different estimation method, while using the full pessimistic-to-optimistic range would overstate the specified standard deviation.

• Equal weighting produces 34 person-days but ignores the required fourfold weighting of the most likely estimate.
• Full range as SD uses 30 person-days instead of dividing that range by six.
• Guaranteed limits overstate what the calculated standard deviation says about uncertain actual effort.

Question 35

Topic: Test Analysis and Design

An order API has two input sets. Use X as a representative of each invalid partition.

All valid combinations except (G,E) are supported. An invalid-input test must contain exactly one invalid value and must expect rejection.

Which test suite satisfies Each Choice coverage and these constraints?

Options:

• A. (G,S), (M,E), (X,X), (M,S)

• B. (G,S), (M,S), (X,S), (M,X)

• C. (G,S), (M,E), (X,S), (M,X)

• D. (G,E), (M,S), (X,S), (M,X)

Best answer: C

Explanation: Each Choice coverage requires at least one representative from every partition in every input set, but it does not require every combination. The customer partitions G, M, and X are covered by (G,S), (M,E), and (X,S). The service partitions S, E, and X are covered by (G,S), (M,E), and (M,X). The two invalid tests each contain only one invalid value, so they also satisfy the isolation constraint. The valid tests avoid the unsupported (G,E) combination.

• Pairing (X,X) covers both invalid partitions but violates the requirement to isolate one invalid input per test.
• Using only S for valid services leaves the Express partition uncovered.
• Pairing Guest with Express covers the partitions but uses the explicitly unsupported combination.

Question 36

Topic: Static Testing

A test manager compares two document reviews:

• Review A: A moderator leads technically qualified reviewers. Review metrics are not collected.
• Review B: The complete review process is followed and metrics are collected. The author attends but is neither the review leader nor the scribe.

Which interpretation is best supported?

Options:

• A. Review A is technical; Review B is an inspection.

• B. Review A is technical; Review B is a walkthrough.

• C. Review A is an inspection; Review B is technical.

• D. Review A is a walkthrough; Review B is an inspection.

Best answer: A

Explanation: A technical review is moderated and performed by technically qualified reviewers, which matches Review A. An inspection follows the complete review process and collects review metrics. It also imposes role restrictions: the author cannot serve as review leader or scribe. Review B satisfies these characteristics even though the author attends. A walkthrough differs because it is typically led by the author, so author attendance alone does not make a review a walkthrough.

The review leader, degree of process formality, collected evidence, and participant roles distinguish these review types.

• Classifying Review A as a walkthrough ignores that a moderator, rather than the author, leads the qualified reviewers.
• Reversing the classifications ignores Review B’s complete process, collected metrics, and inspection role restrictions.
• Classifying Review B as a walkthrough confuses author attendance with author leadership.

Question 37

Topic: Testing in the Lifecycle

A retailer is preparing a new order-management system for release. After system testing, a team uses a production-like environment to verify deployment, backup and restore, monitoring alerts, and disaster-recovery procedures. Which interpretation of this testing is best supported?

Options:

• A. Contractual acceptance testing focused on agreed delivery obligations

• B. Regulatory acceptance testing focused on compliance requirements

• C. User acceptance testing focused on business-process fitness

• D. Operational acceptance testing focused on production readiness

Best answer: D

Explanation: Operational acceptance testing evaluates whether a system is ready to be operated in its intended environment. Typical concerns include deployment, backup and restoration, monitoring, recovery, security operations, and other operational procedures. The production-like environment supports realistic readiness checks, but the responsible team and exact environment can vary by context.

User acceptance testing instead evaluates whether users can accomplish business goals. Contractual acceptance testing evaluates compliance with contractually agreed acceptance criteria, while regulatory acceptance testing evaluates applicable laws or regulations. The decisive evidence here is the focus on operating and recovering the released system.

• Business-process fitness would require evidence that representative users are validating business needs or workflows.
• Delivery obligations would require testing against acceptance criteria established by a contract.
• Compliance requirements would require testing against applicable legal or regulatory rules.

Question 38

Topic: Fundamentals

A payroll system passes every test derived from its stated requirements. During an acceptance trial in a production-like setting, payroll staff cannot reverse an erroneous payment before the processing cutoff. This important stakeholder need was not documented.

Which interpretation is supported?

Options:

• A. The system failed both verification and validation.

• B. The system failed verification but passed validation.

• C. The system passed both verification and validation.

• D. The system passed verification but failed validation.

Best answer: D

Explanation: Verification checks whether a work product satisfies its specified requirements. All requirement-derived tests passed, so the available evidence supports successful verification. Validation checks whether the system fulfills stakeholder needs in its intended operational context. The acceptance trial exposed an important operational need that the system could not satisfy, so validation failed even though that need was missing from the requirements.

Meeting every documented requirement does not prove that the resulting system is fit for its intended use.

• Claiming failed verification conflicts with the successful tests against every stated requirement.
• Claiming passed validation ignores the unmet stakeholder need found in the operational trial.
• Claiming both failed incorrectly treats an omitted requirement as evidence of verification failure.

Question 39

Topic: Managing Testing

During system testing of an unreleased billing application, testers find that invoices for one supported tax region show an incorrect tax amount. A documented manual correction is a practical workaround, and testing can continue. Release policy requires incorrect customer invoices to be corrected before release.

Classification scales:

Which severity and fix priority should be assigned?

Options:

• A. Severity S2 (Major); priority P1 (Immediate).

• B. Severity S2 (Major); priority P2 (High).

• C. Severity S3 (Moderate); priority P2 (High).

• D. Severity S3 (Moderate); priority P1 (Immediate).

Best answer: C

Explanation: Severity measures the defect’s impact, while fix priority measures how urgently it must be corrected. The invoice defect produces an incorrect functional result, but the documented manual correction is a practical workaround. Under the supplied severity scale, that makes it S3 Moderate rather than S2 Major. Testing can continue, so the defect does not meet the P1 Immediate criterion. However, release policy requires incorrect customer invoices to be corrected before release, which makes the priority P2 High.

A defect can therefore have moderate severity while still receiving high priority because impact and scheduling urgency are classified separately.

• Major and high overstates severity because S2 requires the absence of a practical workaround.
• Moderate and immediate overstates urgency because the defect does not block testing or require emergency production correction.
• Major and immediate ignores both the available workaround and the fact that current testing can continue.

Question 40

Topic: Test Analysis and Design

A tester executes tests against this state table. Each sequence starts in Idle. An invalid event is rejected without changing the state. All listed events were observed during execution.

Executed sequences:

• select, select, pay, cancel
• pay, cancel
• select, cancel

What all-transitions coverage was achieved?

Options:

• A. 88.9% (8 of 9 combinations)

• B. 55.6% (5 of 9 combinations)

• C. 100% (9 of 9 combinations)

• D. 77.8% (7 of 9 combinations)

Best answer: D

Explanation: All-transitions coverage includes every state-event combination in the table: five valid transitions and four invalid transitions, giving nine coverage items. The first sequence covers four distinct combinations. The second adds the invalid Idle-pay and Idle-cancel combinations. The third adds Selected-cancel, while Idle-select is a repeat. Therefore, seven distinct combinations were exercised, so coverage is \(7/9 \times 100\% = 77.8\%\).

All five valid transitions were covered, but the invalid Paid-select and Paid-pay combinations were not attempted.

• Valid transitions only: Five of nine counts the valid transitions but omits the two invalid combinations that were attempted.
• Repeated attempt: Eight of nine treats the repeated Idle-select transition as an additional coverage item.
• Complete coverage: Nine of nine ignores the two unattempted invalid combinations from the Paid state.

Review your attempt

The questions are mixed across domains. Use each question’s topic label to record your result.

Use your raw total to identify gaps. It does not predict a pass on the official exam. An immediate repeat may measure answer memory more than understanding.

Use the blueprint to locate a gap, the study plan to choose focused practice, and official resources to check an unfamiliar rule or behavior. Return to a mixed attempt after you can explain a fresh example.

If a question seems incorrect or unclear, email support@masteryexamprep.com with this page’s URL, the question number, and the detail you want us to review.

Continue in the web app

Use IT Mastery for interactive ISTQB CTFL v4.0 practice with mixed sets, timed mocks, topic drills, explanations, and progress tracking.

Try ISTQB CTFL v4.0 on Web