ISTQB Advanced (CTAL-TA v4.0) Mock Exam #2 — Questions & Answers
Every question in this mock exam, with the correct answer marked and a written rationale behind each option below — for reading and review, not a timed run.
Chapter 1 · The Tasks of the Test Analyst in the Test Process — 8 questions
Which activity is most directly associated with the Test Analyst's involvement in test analysis, as distinct from test design?
Selecting concrete test techniques and deriving test cases with specific input values and expected results for each condition.
This describes test design, the activity that follows test analysis, not test analysis itself.
Assessing the test basis for completeness, consistency, and testability, and prioritizing test conditions.
Correct — this is the definition of test analysis in the ISTQB process model.
Writing detailed step-by-step test procedures that sequence existing test cases into a run-ready order for a manual tester.
This describes test implementation, a later activity in the process.
Logging anomalies found during test execution and tracking each one through the defect management workflow to closure.
This describes test execution and defect management, not test analysis.
Test analysis is the activity of reviewing the test basis for completeness, consistency and testability, and prioritizing test conditions — before concrete test cases are designed.
A Test Analyst is building test procedures that combine several individual test cases into an executable sequence, including pre-conditions and post-conditions. Which test activity is being performed?
Test analysis
Test analysis reviews the basis and derives test conditions, before procedures are assembled.
Test monitoring and control
That activity tracks progress against a plan, not the assembly of test procedures.
Risk analysis
That belongs to risk-based testing, a separate activity from assembling test procedures.
Test implementation
Correct — assembling test cases into procedures with pre/postconditions is test implementation.
Combining test cases into ordered, executable procedures with pre/postconditions is the definition of test implementation.
A reviewer rejects a test case because, although it is technically correct and feasible, another tester cannot tell from its description which requirement or risk it was designed to verify. Which test case quality criterion has been violated?
Traceability
Correct — traceability is the criterion that a test case can be linked back to what it was designed to verify.
Conciseness
Conciseness concerns avoiding unnecessary content, not the ability to trace the test case's origin.
Precision
Precision concerns exact, unambiguous expected results, not traceability to the basis.
Economic efficiency
Economic efficiency concerns the cost of designing and running the test case, not whether its origin can be traced back to a requirement or risk.
Traceability requires that a test case can be linked back to the test basis item (requirement, risk, or condition) it was designed to cover.
In an iterative development model, compared to a sequential (V-model) approach, how does the Test Analyst's involvement in test design typically change?
Test design is handed to developers as part of test-driven development, leaving the Test Analyst to contribute conditions but not cases.
The Test Analyst still designs tests in iterative models; the activity does not transfer away from the role.
Test design is compressed into one detailed specification written at release planning and then executed unchanged in every iteration.
Iterative development spreads test design across iterations; a single specification written at release planning cannot cover requirements that emerge in later iterations.
Test design work is spread across many short iterations rather than concentrated in a single phase before test execution begins.
Correct — iterative models distribute test analysis and design work across iterations instead of a single upfront phase.
Test design is completed at project initiation and reused unchanged thereafter, because every iteration works from the same test basis.
This describes a rigid sequential approach, the opposite of how iterative models handle test design.
Under iterative models, test design is distributed across many short iterations rather than concentrated in one phase, changing the rhythm of the Test Analyst's work but not removing the activity.
Which TWO of the following are benefits of separating the domain layer (business-level keywords) from the test interface layer (technical interaction details) in a keyword-driven test automation framework?
Business-facing keywords remain stable even when the underlying interaction details (e.g., a UI locator) change.
Correct — this decoupling is the main reliability benefit of a keyword-driven framework.
Test execution runs faster, because fewer abstraction layers are involved.
Separating the layers adds an abstraction boundary rather than removing one; its benefit is maintainability and readability, not raw execution speed.
Test cases become easier for non-technical stakeholders to read, because they are expressed in domain terms rather than low-level interaction steps.
Correct — domain-level keywords improve readability for business stakeholders.
Technical interaction details can be edited directly inside each business keyword, so a change to a UI locator only has to be corrected in the test case that uses it.
Putting interaction details inside business keywords defeats the separation: the same locator is reused by many test cases, so a changed locator would have to be corrected in every test case that uses it, not only in one.
Separating layers lets business-facing keywords remain stable when interaction details change, and keeps test cases readable for non-technical stakeholders.
Which of the following is an example of addressing the 'test oracle problem' rather than avoiding it?
Using a metamorphic relation to check that a modified input produces a predictable change in output, when no independent expected result is available.
Correct — this is a textbook solution to the test oracle problem.
Skipping verification for the test case, since no independent oracle exists.
Skipping verification avoids the problem instead of solving it, and leaves the behavior unchecked.
Deferring the comparison to a developer who inspects the actual output after each run and confirms whether the result looks reasonable for the given input values.
Judging whether an output 'looks reasonable' substitutes an informal human opinion for a defined expected result, which avoids the oracle problem rather than addressing it.
Copying a recent production data set into the test environment and treating whatever outputs the live system produced for that data as the expected results.
This does supply an oracle, but a circular one: production outputs encode the system's current behaviour, defects included, so it is not an independent expected result and would confirm existing faults rather than reveal them.
Metamorphic testing directly addresses the oracle problem by checking a relationship between related test cases when no independent expected result is available.
A team copies production customer records into the test environment for realistic test data. Which practice should the Test Analyst insist on to remain compliant with data protection regulation such as GDPR?
Leaving the records unchanged, since data protection applies to the production system, not to test environments.
Test environments handling personal data are generally within scope of data protection regulation.
Copying more records so that the test data set is statistically representative of real customer behaviour.
Volume does not address the compliance issue of exposing personal data.
Sharing the unmasked records with a third-party crowdtesting vendor under a signed non-disclosure agreement.
Sharing unanonymized personal data with external parties increases, rather than resolves, the compliance risk.
Pseudonymizing or anonymizing personally identifiable fields before the data is used for testing.
Correct — this is the recommended practice for using production-derived data safely.
Pseudonymizing or anonymizing personally identifiable data before it is used for testing is the standard practice for compliant use of production-derived test data.
A retail platform's checkout module is modified to support a new payment…
A retail platform's checkout module is modified to support a new payment provider. The regression test suite has 340 cases across the whole system, but the team has only enough time to execute 60 before release. The Test Analyst is asked to select which 60 to run. Which selection approach directly uses the relationship between the change and previously covered code and requirements to justify the choice?
History-based selection, running the 60 tests that have failed most often over the last five years, on the assumption that fault-prone areas stay fault-prone.
History-based selection uses past failure data, not the relationship between this specific change and what it affects.
Impact analysis, tracing which requirements and code areas are affected by the payment provider change and prioritizing tests that cover them.
Correct — impact analysis is the technique that directly links the change to affected requirements and code.
Random sampling of 60 cases from the full suite to keep the selection statistically unbiased.
Random sampling ignores the actual scope of the change and may miss the affected areas entirely.
Selecting the 60 tests with the shortest execution time, so that the largest possible number of test cases fits inside the available execution time budget.
Execution time is unrelated to whether a test actually covers the area affected by the payment provider change.
Impact analysis explicitly traces which requirements and code areas are affected by a specific change and prioritizes tests around them, which is what a checkout-provider change calls for.
Chapter 2 · The Tasks of the Test Analyst in Risk-Based Testing — 3 questions
Which technique is commonly used to identify product risks by bringing together diverse stakeholders to generate a broad list of potential risk items?
A single senior developer reviewing the code alone and listing the risks they can recall from previous releases of the same component.
A single reviewer misses the breadth of perspectives that stakeholder-based identification techniques are designed to capture.
Running the existing regression suite and treating each failing test as evidence of a newly identified product risk.
Regression failures are defects found by existing tests, not a technique for identifying previously unrecognized risk items.
Risk workshops and brainstorming sessions with representatives from development, testing, business, and operations.
Correct — this collaborative approach is the standard technique for broad risk identification.
Waiting until user acceptance testing and treating the defects that business users report there as the project's product risk list.
This is reactive defect discovery after release readiness decisions, not proactive risk identification.
Risk workshops and brainstorming with representatives from development, testing, business and operations are the standard collaborative technique for broad risk identification.
A payment gateway integration carries high likelihood of failure (the…
A payment gateway integration carries high likelihood of failure (the third-party API has changed twice in the past year) and high business impact (a failure blocks all checkout transactions). The project has a fixed two-week release window and cannot extend testing time. Which TWO risk control measures are consistent with mitigating this specific risk within the given constraint, rather than merely accepting or transferring it?
Purchasing insurance that covers the financial loss from a checkout outage, on the basis that the likelihood of an API change cannot be reduced inside a two-week window.
This is risk transfer, shifting the financial consequence elsewhere, not a testing-based mitigation of the risk itself.
Adding contract tests against the third-party API's published schema so a breaking change is detected before it reaches production.
Correct — this reduces the likelihood that an undetected API change causes a production failure.
Removing the payment gateway integration from the risk register because the release date cannot be moved.
Removing a real risk from the register does not reduce it; the risk remains present but unmanaged.
Negotiating a staged rollout with a feature flag so the new integration can be disabled quickly if a defect surfaces after release.
Correct — this reduces the impact of a defect by limiting exposure and enabling fast rollback.
Contract tests against the published API schema and a staged rollout with a feature flag both reduce the actual likelihood or consequence of the risk within the fixed time window, which is what risk mitigation through testing and process design means.
A test manager has organized the regression suite into five risk-ordered…
A test manager has organized the regression suite into five risk-ordered batches. Two days before a release deadline, only three of the five batches can realistically be executed. The two remaining batches cover the two highest-risk areas of the system: authentication and refund processing. Given the residual risk that would be left uncovered if only the lower-risk batches were run, which resourcing decision applies risk-based testing principles most correctly?
Execute the five batches in their originally planned order, treating the schedule as fixed regardless of the residual risk in the untested areas.
This ignores the newly discovered residual risk and fails to reprioritize execution when circumstances change, contrary to risk-based testing.
Leave authentication and refund processing untested and report coverage against the three batches that were already scheduled.
This leaves the two highest-risk areas completely untested and unreported, the opposite of risk-based prioritization.
Split the remaining time evenly across all five batches so that each receives a breadth-first partial run, giving authentication and refund processing the same share of the remaining schedule as the lowest-risk batch, on the grounds that each batch deserves some coverage.
An even, breadth-first split does not give the highest-risk areas the extra depth of testing that their risk level warrants.
Reorder execution to run the authentication and refund processing batches first (depth-first on the highest-risk items), even if that means the three lower-risk batches are only partially executed before the deadline.
Correct — this directly applies the risk-based principle of covering the highest-risk areas first when time is limited.
Reordering execution to run the highest-risk batches first (a depth-first approach) directly reflects the risk-based testing principle of testing higher-risk items earlier and more thoroughly when time is constrained.
Chapter 3 · Test Analysis and Test Design — 22 questions
In domain testing, what distinguishes an 'OFF' point from an 'IN' point for a boundary defined as age >= 18?
An OFF point and an IN point are the same thing, just named differently by different authors.
ON, OFF, IN and OUT are distinct, precisely defined point types in domain testing, not interchangeable synonyms.
An OFF point lies just across the boundary from the ON point (e.g., 17), while an IN point lies well within the valid domain (e.g., 30).
Correct — this is the standard definition of ON, OFF and IN points in domain testing.
An OFF point is the first value outside the valid domain and an IN point is the boundary value itself, so for age >= 18 they would be 17 and 18 respectively.
The boundary value itself is the ON point, not the IN point; OFF can be valid or invalid depending on which side of the boundary it falls.
An OFF point applies to closed boundaries such as age >= 18, whereas open boundaries are covered by IN points alone because they have no exact boundary value.
OFF points apply to both closed and open boundaries; the direction of the OFF point simply differs based on the boundary type.
An OFF point sits just across the boundary from the ON point, while an IN point sits well within the valid domain, away from any boundary.
Which TWO statements correctly describe the difference between base choice coverage and pairwise coverage in combinatorial testing?
Base choice testing varies one parameter at a time away from an agreed baseline combination of values.
Correct — this is the defining mechanic of base choice coverage.
Base choice coverage is satisfied by executing the full Cartesian product of parameter values.
That describes exhaustive combinatorial testing, not base choice coverage, which varies parameters one at a time from a baseline.
Pairwise coverage requires each parameter to have the same number of possible values, because the generated array has to stay balanced across its columns.
Pairwise coverage techniques and algorithms work with parameters that have differing numbers of possible values.
Pairwise coverage specifically aims to exercise every possible pair of values from two different parameters at least once.
Correct — this is the defining goal of pairwise coverage.
Base choice testing varies one parameter at a time from a baseline, while pairwise coverage specifically targets every pair of values across two parameters.
What does a CRUD matrix primarily help a Test Analyst verify?
Whether the user interface presents the same entity consistently on each screen that displays it, which the matrix captures as a presentation layer concern.
Consistent presentation of an entity is a usability concern; a CRUD matrix tracks which operations exist and are exercised, not how screens render.
Whether the source code follows the project's agreed coding style guide.
Coding style is a static code quality concern, not what a CRUD matrix is designed to check.
Whether every entity in the system has appropriate create, read, update, and delete operations defined and exercised, statically and dynamically.
Correct — this is the purpose of a CRUD matrix in CRUD testing.
Whether the system's response time for each operation stays under the agreed threshold, since the matrix lists one row per operation that can be timed.
Response time is a performance concern, unrelated to the create/read/update/delete operations a CRUD matrix tracks.
A CRUD matrix maps entities against create, read, update and delete operations, helping verify statically that all operations are defined and dynamically that they behave consistently.
In a decision table, what does a 'don't care' entry ('–') in a condition column indicate?
The outcome for that rule does not depend on the value of that particular condition.
Correct — this is the definition of a don't care entry, used to merge rules that share the same outcome.
The value of that condition was not analysed when the table was built and still has to be determined.
A don't care entry is a deliberate modeling decision, not a sign that analysis was skipped.
The rule is infeasible in practice and should be deleted from the table before test cases are derived.
Infeasible rules are marked separately; a don't care entry represents a valid, reachable rule with an irrelevant condition.
The condition must be true for that rule to fire, and the dash is a shorthand notation for the value 'true'.
This describes a fixed True/False entry, the opposite of what a don't-care entry represents.
A don't care entry indicates that the outcome for a rule does not depend on the value of that particular condition, allowing several rule combinations to be merged.
A telemedicine platform accepts a patient's age for booking a pediatric…
A telemedicine platform accepts a patient's age for booking a pediatric appointment, valid for ages 0 to 17 inclusive (booking as an adult applies from 18 up). Using domain testing with the simplified domain coverage criterion (ON and OFF points only), which pair of test values is correct for the upper boundary of the pediatric range?
17 (ON, valid) and 16 (OFF, invalid, one below)
16 is still inside the pediatric domain, not across the boundary, so it cannot serve as the OFF point for this boundary.
0 (ON, valid) and 18 (OFF, invalid)
0 is the ON point of the lower boundary, not the upper one; pairing it with the upper OFF point mixes two different boundaries.
17 (ON, valid) and 18 (OFF, invalid)
Correct — 17 is the boundary value (ON) and 18 is just across it on the other side (OFF).
18 (ON, valid) and 19 (OFF, invalid, adult side)
18 already belongs to the adult range and is not the boundary value of the pediatric/adult split, which is 17/18.
For the boundary between 17 (pediatric) and 18 (adult), the ON point is the boundary value itself (17) and the OFF point is the value just across the boundary (18).
Extending the previous scenario to reliable domain coverage (which adds IN and OUT points to ON and OFF), which additional pair of values should be added for the same upper boundary (pediatric: 0–17, adult: 18+)?
A second ON point at exactly 17, executed twice to confirm the boundary is stable, with no value taken from the adult range.
Repeating the ON point does not add IN/OUT coverage, and reliable domain coverage requires an OUT point on the far side.
An IN point at 18 and an OUT point at 17, since the adult range is the one under test and the pediatric range is already covered.
This swaps the sides: 18 belongs to the adult (OUT) side and 17 belongs to the pediatric (IN) side, not the reverse.
Two further OFF points on the adult side of the boundary, such as 18 and 19, to strengthen the evidence around the transition.
Reliable domain coverage calls for IN and OUT points, not additional OFF points on the same side.
An IN point well inside the pediatric range, e.g., 10, and an OUT point well inside the adult range, e.g., 40.
Correct — IN and OUT points are chosen well away from the boundary, one on each side of the domain split.
Reliable domain coverage adds an IN point well inside one side of the domain and an OUT point well inside the other side, complementing the ON/OFF points already selected.
A configuration screen has three independent parameters: Browser (Chrome, Firefox, Safari), OS (Windows, macOS, Linux), and Language (EN, DE, ES) — 27 possible combinations in total. Applying pairwise coverage instead of exhaustive testing, what is the main practical benefit for the Test Analyst?
A much smaller set of test cases (typically around 9) can still exercise every pair of parameter values at least once, catching most defects caused by two-factor interactions.
Correct — this is the core efficiency argument for pairwise testing.
Pairwise coverage is expected to catch three-way interaction defects as well as two-way ones, because the generated set still touches all three parameters.
Pairwise coverage specifically targets two-way interactions; three-way interaction defects may be missed.
Pairwise coverage requires the same number of test cases as exhaustive combinatorial testing, but arranges them in a different execution order.
The entire benefit of pairwise coverage is requiring far fewer test cases than exhaustive testing of all 27 combinations.
Pairwise coverage applies when every parameter has exactly two possible values; with three values per parameter, as on this configuration screen, the technique degenerates into exhaustive testing of all 27 combinations.
Pairwise algorithms handle parameters with differing numbers of values, as in this three-value-per-parameter example.
Pairwise coverage exploits the empirical finding that most defects come from one- or two-factor interactions, so a much smaller test set covering every pair still catches most such defects.
A warehouse inventory system defines a 'Shipment' entity. The CRUD matrix shows…
A warehouse inventory system defines a 'Shipment' entity. The CRUD matrix shows: Create — via receiving dock scan; Read — via inventory dashboard; Update — via quantity adjustment screen; Delete — no function exists in the UI, but the database allows shipment rows to be removed by a scheduled archival job. What consistency issue should the Test Analyst raise?
No issue exists, because a CRUD matrix documents the operations available to users through the interface, and a scheduled archival job is infrastructure housekeeping that falls to the Technical Test Analyst rather than to entity-level CRUD coverage.
CRUD testing covers all pathways that create, read, update or delete an entity's data, including background jobs, not only UI-triggered ones.
There is a mismatch between the static CRUD matrix (no UI delete) and the dynamic behavior (the archival job can delete rows), so delete behavior needs its own dedicated tests even without a UI trigger.
Correct — this identifies exactly the static/dynamic inconsistency the Test Analyst should flag.
The entity should be redesigned to remove the Read operation, since it is redundant with Create.
Read and Create are distinct operations; removing Read would not address the delete inconsistency being raised.
The archival job should be disabled until a matching UI delete function is built, so that the matrix and the implementation agree.
A CRUD matrix documents where operations occur; it does not itself dictate that delete may only happen through the UI.
The static CRUD matrix and the dynamic system behavior disagree about delete: the UI has none, but a scheduled job can still delete rows, so that path needs dedicated coverage.
A hotel booking state machine has states Requested → Confirmed → CheckedIn → CheckedOut, plus a Cancelled state reachable from Requested and Confirmed. Applying 0-switch (single transition) coverage, how many test cases, at minimum, are needed to cover every valid transition once?
Exactly one test case in total, because 0-switch coverage is satisfied once the machine has visited each state at least once during a single end-to-end run.
Visiting every state once is state coverage, a weaker criterion than 0-switch coverage, which targets transitions.
One test case per state rather than per transition, so the minimum equals the number of states.
0-switch coverage is defined in terms of transitions between states, not the states themselves.
One test case per valid transition arrow in the diagram (each covering exactly one transition), so the minimum equals the number of distinct transitions.
Correct — 0-switch coverage is defined at the level of individual transitions, not states or transition pairs.
0-switch coverage is defined over sequences of two consecutive transitions, so the minimum equals the number of distinct transition pairs present in the diagram.
Testing sequences of two consecutive transitions describes 1-switch coverage, a stronger criterion than 0-switch.
0-switch coverage requires each individual transition arrow to be exercised at least once, so the minimum number of test cases equals the number of distinct transitions (assuming one transition can be covered per test case, or grouped efficiently, but each transition must appear at least once).
In the same hotel booking state machine, a support agent occasionally reopens a CheckedOut booking back to CheckedIn to correct a billing error, then returns it to CheckedOut. Which coverage criterion specifically targets verifying this kind of loop that starts and ends at the same state?
Round-trip coverage, which requires testing every loop that departs from and returns to the same state.
Correct — round-trip coverage is defined exactly for loops that begin and end at the same state.
0-switch coverage, since exercising each individual transition once also exercises the two transitions that form the loop.
0-switch coverage does not specifically target loops that return to their starting state; it covers single transitions.
Statement coverage, which measures how much of the booking service's source code is executed by the state tests.
Statement coverage measures code execution, not paths through a state model.
Simplified domain coverage, which pairs each ON point with an OFF point and so covers both ends of the loop.
Domain coverage criteria apply to input value boundaries, not to loops in a state transition diagram.
Round-trip coverage specifically requires testing loops that depart from and return to the same state, exactly the CheckedOut → CheckedIn → CheckedOut pattern described.
A university course registration use case has a main flow (student selects…
A university course registration use case has a main flow (student selects course, system checks prerequisites, seat is reserved) and an exception flow (course is full, system offers waitlist). A Test Analyst designs one test for the main flow only. What test design gap results from ignoring the exception flow?
No gap results, because exception flows are optional documentation notes that do not need dedicated test cases.
Exception flows are part of the use case specification and represent behavior that must be verified, not optional notes.
The waitlist behavior when the course is full is never verified, even though it is an explicitly documented alternative path through the use case.
Correct — exception flows are documented paths that require their own test cases, just like the main flow.
The main flow test automatically also verifies the exception flow, since both flows share the same first step.
Sharing an initial step does not exercise the branch where the course is full; the exception path still requires its own test.
Testing exception flows requires white-box access to the registration service's source code in order to force the 'course full' condition, which places this flow outside the Test Analyst's scope.
Exception flows are black-box behavior documented in the use case and can be tested without any code access.
Exception flows are explicit alternative paths through a use case and require their own dedicated test cases; skipping them leaves documented behavior unverified.
A ride-hailing dispatch system retries matching a driver up to 5 times if the first offer is declined, then falls back to manual dispatch. Using simple loop coverage (0, 1, typical, and maximum number of iterations), which set of test cases is appropriate?
Test with exactly 5 declines, since that is the case that reaches the manual fallback and every smaller count is covered implicitly by the same loop logic.
Testing only the maximum misses the 0, 1 and typical iteration cases required by simple loop coverage.
Test with 0 declines, since the retry loop repeats identical logic and executing it once establishes that each further iteration behaves the same way.
Loop behavior at 1, typical and maximum iterations can differ from the zero-iteration case, so a single test is insufficient.
Test with 6, 7, and 8 declines to confirm the system keeps retrying beyond its documented limit.
The documented limit is 5 retries with fallback afterward; simple loop coverage targets 0, 1, typical and maximum, not values beyond the documented maximum.
Test with 0 declines (first driver accepts), 1 decline, a typical number such as 3 declines, and the maximum of 5 declines before manual fallback.
Correct — this exercises the 0, 1, typical and maximum iteration counts required by simple loop coverage.
Simple loop coverage requires testing the loop with zero iterations, one iteration, a typical number, and the maximum number, which here maps to 0, 1, a mid-range value, and 5 declines.
A decision table for an expense reimbursement policy has 3 binary conditions (Receipt attached? Over $500? Manager approved?), giving 8 possible rules. The Test Analyst's table only lists 6 distinct rule columns. Using the checksum procedure, what should the Test Analyst check for?
Whether the reimbursement amounts in the existing 6 rules are mathematically correct.
Verifying calculated amounts is a separate check from the checksum procedure, which focuses on completeness of rule coverage.
Whether the table has too many conditions and should be reduced to 2.
The checksum procedure checks completeness of the existing conditions, not whether the number of conditions itself should change.
Whether the missing 2 rule combinations were deliberately merged into existing rules via don't-care entries, or whether they were simply omitted by mistake.
Correct — the checksum procedure is precisely for catching this kind of gap between the theoretical rule count and the actual table.
Whether the actions listed against each rule are formatted consistently, since the checksum procedure compares the action rows of the table rather than its condition combinations.
Formatting consistency is a presentation concern, not what the checksum procedure is designed to verify.
The checksum procedure verifies whether all combinations are accounted for, either explicitly or via don't-care entries that merge rules — a shortfall in rule count signals a possible omission.
A route-planning algorithm has no independent oracle for 'the truly optimal…
A route-planning algorithm has no independent oracle for 'the truly optimal route' between two points. A Test Analyst instead checks that scaling all distances in the map data by the same factor also scales the total planned route distance by that same factor. Which TWO characteristics make this an example of metamorphic testing?
It requires an independent oracle stating the optimal route, which the follow-up test case is then compared against to confirm that the scaling relationship holds.
Metamorphic testing is specifically used when no independent oracle exists, not as a prerequisite for it.
It relies on a defined relationship (metamorphic relation) between a source test case and a derived follow-up test case, rather than a fixed expected result.
Correct — this relationship is the defining mechanism of metamorphic testing.
It can reveal inconsistencies even when the exact 'correct' output is unknown, by checking whether the relationship between inputs and outputs holds.
Correct — this is exactly why metamorphic testing addresses the test oracle problem.
It is restricted to systems with a finite, enumerable set of valid states.
Metamorphic testing applies broadly, including to continuous or numerical domains like distances and routes, not only finite-state systems.
Metamorphic testing defines a relationship between a source test case and a derived follow-up case, and it can detect inconsistencies even without knowing the single correct output.
Which of the following is correctly structured as a session-based exploratory test charter, following the 'Explore [target] With [resources] To discover [information]' format?
'Run test case TC-042 and record pass or fail.'
This is a scripted test case instruction, not an exploratory charter, which deliberately avoids prescribing exact steps.
'Explore the checkout discount stacking logic with a mix of expired and valid promo codes to discover incorrect combined discount calculations.'
Correct — this follows the target/resources/information charter format exactly.
'Fix the discount calculation bug reported in the previous release and confirm with the product owner that the stacking rules now behave as documented.'
This is a development task, not a test charter guiding an exploratory testing session.
'Review the requirements document for the checkout discount feature and record each spelling, numbering and cross-reference error that it contains.'
This targets document proofreading, not exploration of software behavior to discover information about it.
A test charter names a target to explore, resources to use, and the kind of information the session aims to discover, unlike a scripted test case or a task unrelated to testing.
A mobile banking app wants broader device and network coverage than the in-house lab can provide before a regional launch. Which factor is a genuine limitation of crowd testing that the Test Analyst should plan around, rather than an unqualified benefit?
Crowd testing typically finds the same defects in-house testing would, so no further testing is needed afterward.
Crowd testing is a complement to in-house testing, targeting different device and network diversity; it is not a full substitute.
Crowd testers require the exact same formal training as in-house testers before they can participate.
Crowd testing typically relies on lighter-weight onboarding than full in-house training, which is part of its appeal for device diversity.
Crowd testing removes the test environment setup effort, because participating testers exercise the app on their own devices against whichever backend the vendor points them at.
Only the devices come from the crowd; the backend, the test build, the test data and the tester access still have to be provisioned, kept stable and supported, so crowd testing shifts the environment effort rather than removing it.
Confidentiality and data protection are harder to guarantee when unscreened external testers interact with data resembling production banking information.
Correct — this is a well-documented, genuine drawback of crowd testing that requires specific planning, such as using synthetic data.
Crowd testing raises real confidentiality and data protection concerns when unscreened external testers interact with data resembling production banking information, which the Test Analyst must plan for.
A safety-related automotive component is developed under ISO 26262 at a high Automotive Safety Integrity Level (ASIL). Which combination of test techniques does the standard specifically recommend applying to this component's boundary conditions?
Equivalence partitioning, boundary value analysis, and error guessing, applied according to the required ASIL.
Correct — these are the technique categories ISO 26262 specifically references for boundary and input testing at the appropriate ASIL.
Random testing and input fuzzing, on the grounds that unanticipated inputs are the main hazard in safety-related code.
Safety-critical development favors structured, traceable techniques over unstructured random testing alone.
Crowd testing with a large external tester pool, since independent testers assess safety behaviour more objectively.
Crowd testing is not the technique ISO 26262 specifies for safety-critical boundary conditions; it is generally unsuited to regulated safety contexts.
State transition testing on its own, since the component's safety behaviour is fully described by its state machine.
Safety-critical components have many testable characteristics beyond state behavior, including input boundaries and error conditions.
ISO 26262 prescribes equivalence partitioning, boundary value analysis and error guessing as recommended techniques, scaled according to the required ASIL.
A subscription plan enforces a maximum of 5 active devices per account; attempting to register a 6th device triggers a 'device limit reached' state and blocks further registration until a device is removed. Which combined technique approach tests both the numeric limit and the state change together?
Equivalence partitioning on the device count alone, treating 1-5 and 6+ as the two partitions and leaving the state machine out of scope.
Ignoring the state machine misses the LimitReached behavior that the boundary triggers.
State transition testing alone, using 1 and 100 devices as the two state-defining values.
1 and 100 are far from the actual boundary of 5/6 devices and would not test the real limit.
Apply boundary value analysis to the device count (4, 5, 6 devices) within a state transition test that walks the account through Normal → LimitReached → Normal after a removal.
Correct — this combines BVA on the numeric boundary with state transition testing of the resulting state change.
CRUD testing of the device registration entity, since registering a device is a create operation and removing one is a delete operation, which together describe the whole behaviour without needing a state model or boundary values.
Adding a device does trigger a state change (LimitReached) that CRUD testing alone would not verify.
Combining BVA on the device count with a state transition test that walks through Normal, LimitReached and back to Normal covers both the numeric boundary and the state behavior together, which is the kind of technique combination the syllabus describes.
An employee onboarding scenario involves multiple decision points (background check required? equipment ordered? training scheduled?) chained across a multi-step activity diagram. Which technique combination is specifically known as 'process cycle testing'?
Combining scenario-based testing of the activity diagram's flow with decision coverage of each decision point along that flow.
Correct — this is the specific combination the syllabus names as process cycle testing.
Combining random testing with metamorphic relations, since an onboarding workflow has no independent oracle for its correct end state.
Onboarding steps have clear expected outcomes at each decision point; this is not the oracle-problem scenario that motivates metamorphic testing.
Combining CRUD testing of the HR database with statement coverage of the onboarding script, so that both the data and the code are exercised.
Process cycle testing is a black-box combination of scenario and decision techniques, not a mix with white-box statement coverage.
Combining boundary value analysis of employee start dates with pairwise coverage of office locations and equipment categories at each step.
This describes a different, unrelated technique pairing; it is not what process cycle testing refers to.
Process cycle testing specifically combines scenario-based testing of the flow through an activity diagram with decision coverage of the decision points along that flow.
A parking permit fee depends on two independent variables: parking duration (1–24 hours) and vehicle type (compact, standard, oversized). Which technique generalizes single-variable boundary value analysis to handle this multi-dimensional input space?
State transition testing, since the permit moves between states as the parking duration elapses and the fee changes with it.
Duration here is a numeric input value, not a modeled state with transitions and events.
CRUD testing, since the permit record is created once and then read and updated as the duration and vehicle type are entered.
CRUD testing targets entity lifecycle operations, not the combination of numeric and categorical fee-determining variables.
Metamorphic testing, since no independent oracle exists for the fee and the relation between duration and price can be checked instead.
A parking fee has a clear expected value computable from the inputs, so an independent oracle does exist here.
Domain testing, which extends equivalence partitioning and boundary value analysis to combinations of multiple variables.
Correct — domain testing is defined as this multi-variable generalization.
Domain testing generalizes equivalence partitioning and BVA to multiple variables at once, exactly the situation of duration combined with vehicle type.
A Test Analyst builds a classification tree for a shipping cost calculator with…
A Test Analyst builds a classification tree for a shipping cost calculator with classifications 'Package Weight' (light, medium, heavy) and 'Destination' (domestic, international), then draws a combination table beneath it marking which weight/destination pairs will actually be tested. Which TWO purposes does this combination table serve?
It computes the expected output value for each marked combination automatically.
The combination table shows which combinations are selected for testing; it does not calculate expected results.
It replaces the decision table for the same feature, since the marked combinations already express the same condition-action rules in graphical form.
A classification tree and a decision table serve related but distinct purposes; one does not substitute for the other when both are relevant.
It makes explicit which combinations of classes from different classifications will actually be tested.
Correct — this visibility is the main purpose of the combination table beneath a classification tree.
It allows infeasible or excluded combinations to be marked and left out of the test set deliberately, rather than by oversight.
Correct — marking excluded combinations is a standard use of the combination table.
The combination table makes the selected test combinations explicit and lets infeasible or deliberately excluded combinations be marked, rather than omitted by oversight.
A Test Analyst has designed a test set for a loan approval feature using…
A Test Analyst has designed a test set for a loan approval feature using equivalence partitioning on credit score (poor, fair, good, excellent) and boundary value analysis on requested loan amount ($1,000–$50,000). The set has 8 test cases covering every partition and every boundary value for these two inputs individually, but no test combines a boundary loan amount with the 'poor' credit score partition, and the feature also has a decision table with 3 additional binary conditions (existing customer? co-signer provided? income verified?) that the test set does not reference at all. Is this test set sufficient to release the feature with confidence, and why?
Yes — because every individual partition and every individual boundary value has been covered at least once, sufficiency does not depend on combinations or on other, separately documented tables.
Covering partitions and boundaries individually does not guarantee that combinations of them, or other decision-governing conditions, behave correctly.
No — the test set is insufficient because it neither exercises the interaction between the credit score partition and loan amount boundaries, nor covers the decision table's rules for the additional conditions that also govern the approval decision.
Correct — sufficiency requires covering both cross-input interactions and all conditions that determine the outcome, neither of which this set does.
Yes — because equivalence partitioning combined with boundary value analysis is designed to also catch defects arising from interactions with unrelated conditions such as separate decision tables.
EP and BVA target the inputs they are applied to; they are not designed to automatically cover conditions modeled in a separate decision table.
No — the test set is insufficient because eight test cases is far too small a number for a loan approval feature of this importance; a feature that touches credit scoring and monetary limits should carry a test set numbering in the low hundreds before it is considered releasable.
Sufficiency depends on what conditions and combinations are covered, not on raw test case count.
Sufficiency depends on covering interactions between conditions and all conditions that govern the decision, not just individual partitions and boundaries in isolation; the described set misses both.
Chapter 4 · Testing Quality Characteristics — 4 questions
Which ISO/IEC 25010 sub-characteristic of functional suitability is concerned with whether a system's functions enable users to achieve their specified tasks and objectives, beyond simply being present and producing the right outputs?
Functional completeness
Functional completeness concerns whether the full set of required functions is present, not whether they help achieve objectives.
Functional correctness
Functional correctness concerns whether functions produce results with the needed degree of precision, not whether they support the user's objectives.
Appropriateness recognizability
Appropriateness recognizability is an interaction-capability characteristic about users recognising whether software suits their needs, not a functional suitability sub-characteristic.
Functional appropriateness
Correct — functional appropriateness is defined as functions facilitating the accomplishment of specified tasks and objectives.
Functional appropriateness specifically concerns whether functions actually help users accomplish their goals, distinct from completeness (functions exist) and correctness (functions produce the right results).
A usability test session for a new mobile app uses personas and realistic operational profiles, and afterward participants complete a SUMI questionnaire. Which TWO purposes does using a standardized questionnaire such as SUMI serve in this context?
It provides a structured, comparable measure of users' subjective satisfaction with usability.
Correct — this is the core purpose of a standardized usability questionnaire like SUMI.
It measures the software's server response time under peak concurrent load.
Response time under load is a performance efficiency measure, unrelated to a usability satisfaction questionnaire.
It complements observational usability reviews and test sessions with a quantifiable participant-reported dimension.
Correct — questionnaires add a measurable, comparable data point alongside observational techniques.
It supplies the participant profile and task context for the session, so that personas and operational profiles can be derived from the questionnaire results afterwards.
Personas and operational profiles are prepared before the session to guide realistic tasks; the questionnaire is completed afterward and does not replace them.
A standardized usability questionnaire provides a structured, comparable measure of subjective satisfaction that complements observational usability test sessions.
A hospital's patient records system needs to exchange data correctly with a separate billing system built by a different vendor, using a shared data format. Which ISO/IEC 25010 characteristic is the Test Analyst primarily responsible for testing here?
Installability, part of the flexibility characteristic.
Installability concerns installing or uninstalling software in a given environment, not exchanging data with another system.
Coexistence, since both systems run in the same hospital data centre.
Coexistence concerns systems sharing resources without interfering with each other, a different concern from data exchange, and is a Technical Test Analyst topic.
Interoperability, part of compatibility.
Correct — exchanging data correctly between systems built by different vendors is the definition of interoperability.
Replaceability, since the billing system could later be swapped for another vendor's product.
Replaceability is about substituting one software product for another for the same purpose, not about exchanging data between two coexisting systems.
Interoperability, a compatibility sub-characteristic, concerns exchanging and using information correctly between different systems, and is a Test Analyst responsibility.
Within the 'Flexibility' quality characteristic, which two sub-characteristics does the Test Analyst (rather than the Technical Test Analyst) typically focus on?
Scalability and replaceability.
These flexibility sub-characteristics are typically the Technical Test Analyst's responsibility, not the Test Analyst's.
Adaptability and installability.
Correct — these are the two flexibility sub-characteristics the syllabus assigns to the Test Analyst.
Coexistence and interoperability.
These are compatibility sub-characteristics, not part of the flexibility characteristic being asked about.
Time behavior and resource utilization.
These are performance efficiency sub-characteristics, unrelated to flexibility.
The Test Analyst focuses on adaptability and installability within flexibility, while scalability and replaceability are more technical concerns typically owned by the Technical Test Analyst.
Chapter 5 · Software Defect Prevention — 8 questions
A review of a set of requirements assigns each reviewer a different viewpoint (end user, security officer, maintenance engineer) to examine the same document from that specific angle. Which review technique is being used?
Perspective-based reading
Correct — assigning distinct stakeholder viewpoints to reviewers is the definition of perspective-based reading.
Ad hoc reviewing
Ad hoc reviewing has little to no structure or assigned viewpoints, unlike the structured, role-based approach described.
Checklist-based review
Checklist-based reviewing uses a shared checklist of items to check, not individually assigned stakeholder perspectives.
Scenario-based reviewing, in which each reviewer works through the same set of predefined use-case scenarios rather than an assigned role.
Scenario-based reviewing uses scenarios or use cases to structure the review, not distinct assigned stakeholder viewpoints per reviewer.
Perspective-based reading assigns reviewers distinct stakeholder viewpoints to examine the same document, which is exactly what is described.
What does 'phase containment effectiveness' measure in the context of defect prevention?
The total number of defects found across the whole project, expressed as a proportion of the defect count predicted during test planning for that project.
A raw total defect count does not capture whether defects were caught in the same phase they were introduced.
The average time taken to fix a single defect after it is reported.
Average fix time is a different metric, unrelated to whether a defect was contained within its originating phase.
The proportion of defects introduced in a given development phase that are also found and fixed within that same phase, before leaking to later phases.
Correct — this is the definition of phase containment effectiveness.
The number of test cases executed during a single test level, divided by the number designed for that level, which shows how far that level was contained.
Test case execution counts measure test progress, not whether defects were caught in the phase they originated.
Phase containment effectiveness measures how many defects introduced in a phase are also found and fixed in that same phase, before they leak forward.
A Test Analyst builds a state model of a smart lock's authentication flow before…
A Test Analyst builds a state model of a smart lock's authentication flow before any code exists, purely to check the model for missing transitions and contradictory rules. Later, the same model is used to automatically generate test cases. Which benefit of modeling does the first part of this activity — checking the model itself — primarily represent?
Finding defects in the source code, since building a state model of the authentication flow requires reading the finished implementation to know which transitions exist.
The model is built before any code exists, so it cannot be finding source code defects at this stage.
Finding defects in the model itself, independent of finding defects in the specification or the eventual test cases it generates.
Correct — checking a model for internal consistency finds defects in the model, distinct from spec defects or test case generation.
Increasing test execution speed, since models run faster than manual testing.
Execution speed relates to how tests are run, not to the benefit of reviewing a model for internal defects.
Reducing the number of test levels the project needs, because a model that has been checked for contradictions makes component and integration testing redundant.
Building and reviewing a model does not change how many test levels a project requires.
Reviewing a model for internal defects, such as missing transitions or contradictions, is a distinct benefit of modeling from generating test cases or finding specification defects.
Over the last three releases, defect reports show that 70% of all post-release defects trace back to just two modules: the payment gateway integration and the notification service, out of twelve modules total. What does this pattern most directly support doing?
Applying Pareto analysis to focus additional review, testing, and root cause analysis effort on the payment gateway integration and notification service, since a small number of modules account for most of the defects.
Correct — this is exactly the Pareto-style defect cluster pattern and the response it supports.
Deciding to stop tracking defects in the other ten modules, since they fall outside the top two contributors.
The other modules still contribute 30% of defects and should continue to be tracked, just with lower relative priority.
Concluding that the defect tracking tool is attributing defects to the wrong modules, since no two modules out of twelve could realistically account for 70% of the total.
A 70/30 concentration of defects in two modules out of twelve is a plausible and commonly observed Pareto pattern, not evidence of a tool error.
Redistributing testers evenly across all twelve modules so that each module receives the same test effort, on the grounds that the historical defect distribution reflects where testing was concentrated in the past rather than where defects actually are.
An even distribution ignores the historical concentration of defects and does not target effort where it is most needed.
This is a Pareto pattern: a small number of modules accounting for most defects, which supports focusing additional review and testing effort on those modules.
A defect is reported: 'Order confirmation emails are sometimes sent twice.' Root…
A defect is reported: 'Order confirmation emails are sometimes sent twice.' Root cause analysis using the five whys technique traces this through: emails sent twice → the notification service is called twice → a retry mechanism resends after a slow response → the timeout threshold is too short for peak load → the threshold was copied from a low-traffic environment without adjustment. Which single fix addresses the identified root cause, rather than merely a symptom along the way?
Suppressing the second email at the notification service so the duplicate is filtered before delivery, while leaving the short timeout in place.
This masks the symptom (duplicate email visible to the user) without fixing the underlying timeout mismatch that causes the double call.
Disabling the retry mechanism so that a slow response produces a single call, which removes the duplicate without touching the timeout.
Disabling retries removes a symptom-level workaround but leaves the actual mismatched timeout threshold unresolved, risking other failures.
Adding more servers to the notification service so that responses come back faster and the configured timeout is no longer exceeded.
Adding servers does not address the mismatched timeout threshold identified as the root cause.
Adjusting the timeout threshold to match expected response times under peak load in the actual production environment.
Correct — this addresses the root cause identified at the end of the five whys chain.
The root cause traced by the five whys is the mismatched timeout threshold; adjusting it to match production peak-load response times fixes the cause rather than a downstream symptom.
A team investigates recurring defects in an e-commerce checkout flow using…
A team investigates recurring defects in an e-commerce checkout flow using Ishikawa (cause-effect) diagrams. Across the last six defects, the diagrams repeatedly point to two contributing branches: 'inconsistent validation rules between the front-end and back-end' and 'test data that never included international address formats.' The team proposes a single action: adding more test cases for international addresses using the existing validation rules. Does this action address the recurring pattern sufficiently, and why?
No — it addresses the missing test data branch but leaves the inconsistent validation rules between front-end and back-end unresolved, so similar defects will likely recur from that second contributing cause.
Correct — the Ishikawa diagram names two contributing causes, and the proposed action only addresses one of them.
Yes — because adding more test cases is the appropriate response whenever a defect cluster analysis identifies a pattern, independent of which contributing causes were diagrammed.
The appropriate response depends on which specific causes the diagram identifies; here one of the two named causes is left untouched.
Yes — because international address formats were the cause identified most often across all six defects.
The scenario states both branches recur across the six defects; frequency of one branch does not make the other branch irrelevant.
No — Ishikawa diagrams drawn over six defects cannot support an action at all, so the team should collect at least thirty defect reports before deciding which contributing branch to act on, regardless of how consistently the two branches appear.
Ishikawa diagrams are a qualitative root cause tool and do not require a minimum defect sample size to be valid; the real issue is the unaddressed validation-rule branch.
The proposed fix only targets the missing test data branch and leaves the inconsistent front-end/back-end validation rules unresolved, so similar defects are likely to recur from that second contributing cause.
A defect classification exercise using IEEE 1044 categorizes the last quarter's…
A defect classification exercise using IEEE 1044 categorizes the last quarter's defects by root cause. The two largest categories are 'requirements ambiguity' (32% of defects) and 'incorrect handling of concurrent updates' (24% of defects). Which TWO process improvement actions would directly target these two specific root cause categories, rather than being a generic quality initiative?
Increasing the overall test team headcount so that more test cases can be executed in each sprint.
More headcount without changing review or test focus does not specifically target either identified root cause category.
Introducing structured requirements reviews with an explicit checklist for ambiguity and testability before development starts.
Correct — this directly targets the requirements ambiguity root cause category.
Redesigning the defect-tracking tool's dashboard so that these two root cause categories are highlighted in their own colour scheme and surfaced at the top of the weekly quality report.
A visual dashboard change does not alter requirements review practices or concurrency test design, so it does not address either root cause.
Adding concurrency-focused test design (e.g., overlapping update scenarios) and code review checkpoints specifically for shared-state modifications.
Correct — this directly targets the concurrent-update handling root cause category.
Structured requirements reviews target ambiguity directly, and concurrency-focused test design and review checkpoints target the concurrent-update root cause directly, unlike generic headcount or tooling changes.
A defect report includes fields for 'trigger' (the condition that caused the…
A defect report includes fields for 'trigger' (the condition that caused the defect to surface), 'type' (the nature of the defect, e.g., interface, logic, data), and 'impact' (which quality characteristic was affected). Which defect classification model is most associated with this specific structure of trigger/type/impact attributes?
Severity-based classification (critical, major, minor, trivial)
A pure severity scale has only one dimension and does not include trigger or type attributes.
FURPS
FURPS is a quality characteristic classification model (Functionality, Usability, Reliability, Performance, Supportability), not a defect attribute classification scheme.
Orthogonal Defect Classification (ODC)
Correct — ODC is specifically built around structured attributes such as trigger, type, and impact.
A generic defect workflow status model (New → In Progress → Closed)
A workflow status model tracks the defect's lifecycle state, not structured attributes like trigger, type and impact.
Orthogonal Defect Classification (ODC) uses exactly this kind of structured attribute set — trigger, type, and impact among others — to classify defects for root cause and process insight.