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?
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.
Selecting concrete test techniques and deriving test cases with specific input and expected result values.
This describes test design, the activity that follows test analysis, not test analysis itself.
Writing detailed step-by-step test procedures ready for a tester to execute manually.
This describes test implementation, a later activity in the process.
Logging anomalies found during test execution and tracking them through the defect workflow.
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 implementation
Correct — assembling test cases into procedures with pre/postconditions is test implementation.
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 identification
That belongs to risk-based testing, a separate activity from assembling test procedures.
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.
Necessity
Necessity concerns whether the test case is needed at all, not whether its origin can be traced.
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 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 work moves to developers only, with no test analyst design activity remaining.
The Test Analyst still designs tests in iterative models; the activity does not transfer away from the role.
Test design becomes the sole responsibility of developers instead of the Test Analyst.
Developers contribute unit-level tests, but system and acceptance-level test design remains a Test Analyst task.
Test design is performed only once, at project kickoff, and is never revisited.
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 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.
The framework no longer requires any execution engine to run the tests.
An execution engine is still required to interpret and run keywords regardless of layering.
Every keyword must be manually re-written for each new test case, since composition is not supported.
Keyword-driven frameworks are designed so keywords can be composed and reused across test cases, not rewritten each time.
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.
Asking a developer to manually approve every test case before it is designed.
This does not address the oracle problem for execution-time verification; it is a review step before design, not a solution to missing expected results.
Replacing all test data with production data to eliminate uncertainty.
Using production data changes test data sourcing, but does not provide an oracle for verifying outputs.
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?
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.
Leaving the data unchanged, since test environments are not covered by data protection law.
Test environments handling personal data are generally within scope of data protection regulation.
Increasing the volume of copied records to improve statistical realism.
Volume does not address the compliance issue of exposing personal data.
Sharing the copied records with third-party crowdtesting vendors before anonymizing them.
Sharing unanonymized personal data with external parties increases, rather than resolves, the compliance risk.
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?
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.
History-based selection, running whichever 60 tests failed most often in the last five years regardless of what changed.
History-based selection uses past failure data, not the relationship between this specific change and what it affects.
Random sampling of 60 cases from the full suite to keep the selection 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 more tests fit in the 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?
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.
A single senior developer reviewing the code alone and listing risks from memory.
A single reviewer misses the breadth of perspectives that stakeholder-based identification techniques are designed to capture.
Running the existing regression suite and treating every failure as a newly identified risk.
Regression failures are defects found by existing tests, not a technique for identifying previously unrecognized risk items.
Waiting until user acceptance testing to see which defects appear in production.
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?
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.
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.
Purchasing insurance to cover financial losses from a checkout outage, since the risk cannot be reduced within two weeks.
This is risk transfer, shifting the financial consequence elsewhere, not a testing-based mitigation of the risk itself.
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.
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?
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.
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.
Skip authentication and refund processing entirely and report only on the batches that were already scheduled, without adjusting for the residual risk.
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 (breadth-first), giving authentication and refund processing the same share of time as the lowest-risk batch.
An even, breadth-first split does not give the highest-risk areas the extra depth of testing that their risk level warrants.
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 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 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 is always invalid and an IN point is always the boundary value itself.
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 only applies to closed boundaries, never to open boundaries.
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.
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 coverage requires testing all possible combinations of every parameter simultaneously.
That describes exhaustive combinatorial testing, not base choice coverage, which varies parameters one at a time from a baseline.
Pairwise coverage can only be applied when every parameter has exactly the same number of possible values.
Pairwise coverage techniques and algorithms work with parameters that have differing numbers of possible values.
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 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 user interface uses consistent colors across all screens.
Visual consistency is a usability concern unrelated to CRUD operations on entities.
Whether the source code follows a specific coding style guide.
Coding style is a static code quality concern, not what a CRUD matrix is designed to check.
Whether the system's response time stays under a fixed threshold.
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 condition's value was left unanalyzed at the time the table was built.
A don't care entry is a deliberate modeling decision, not a sign that analysis was skipped.
The rule is infeasible and should be removed from the table.
Infeasible rules are marked separately; a don't care entry represents a valid, reachable rule with an irrelevant condition.
The condition is required to be true specifically for that rule to apply, unlike a don't-care entry.
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 18 (OFF, invalid)
Correct — 17 is the boundary value (ON) and 18 is just across it on the other side (OFF).
17 (ON, valid) and 16 (OFF, invalid)
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.
18 (ON, valid) and 19 (OFF, invalid)
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+)?
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.
Another ON point at exactly 17 tested twice, and no OUT point at all.
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, reversing which side each value belongs to.
This swaps the sides: 18 belongs to the adult (OUT) side and 17 belongs to the pediatric (IN) side, not the reverse.
Two additional OFF points on the same side of the boundary, e.g., 18 and 19.
Reliable domain coverage calls for IN and OUT points, not additional OFF points on the same side.
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 also catch every three-way interaction defect, in addition to two-way ones.
Pairwise coverage specifically targets two-way interactions; three-way interaction defects may be missed.
Pairwise coverage requires exactly the same number of test cases as exhaustive combinatorial testing.
The entire benefit of pairwise coverage is requiring far fewer test cases than exhaustive testing of all 27 combinations.
Pairwise coverage only works when all parameters have exactly two possible values.
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?
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.
No issue exists, because CRUD matrices are limited to describing user interface operations, not database-level or scheduled-job behavior.
CRUD testing covers all pathways that create, read, update or delete an entity's data, including background jobs, not only UI-triggered ones.
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, since a CRUD matrix implies delete operations should only occur through the UI.
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?
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.
Exactly one test case total, since 0-switch coverage only requires visiting every state once regardless of transitions.
Visiting every state once is state coverage, a weaker criterion than 0-switch coverage, which targets transitions.
One test case per state, not 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.
0-switch coverage requires testing every possible sequence of two consecutive transitions (1-switch pairs), not single transitions.
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, which only requires each individual transition to be exercised once.
0-switch coverage does not specifically target loops that return to their starting state; it covers single transitions.
Statement coverage, which is a white-box code-level criterion unrelated to state diagrams.
Statement coverage measures code execution, not paths through a state model.
Simplified domain coverage, which applies to boundary values, not to states.
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?
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.
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 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 source code, which a Test Analyst does not have.
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 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.
Test only with exactly 5 declines, since that is the only case that reaches the fallback.
Testing only the maximum misses the 0, 1 and typical iteration cases required by simple loop coverage.
Test with 0 declines only, since the loop behavior is identical regardless of how many times it repeats.
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.
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 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 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 actions listed for each rule are formatted consistently.
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 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 requires an independent oracle to already exist before it can be applied at all.
Metamorphic testing is specifically used when no independent oracle exists, not as a prerequisite for it.
It only works for 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?
'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.
'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.
'Fix the discount calculation bug found in the previous release.'
This is a development task, not a test charter guiding an exploratory testing session.
'Review the requirements document for spelling errors.'
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?
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 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 eliminates the need for any test environment setup, since testers use only production systems.
Crowd testers generally test against a dedicated build or environment provided for the campaign, not directly against production.
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.
Only random testing, since safety-critical systems should avoid any structured technique.
Safety-critical development favors structured, traceable techniques over unstructured random testing alone.
Only crowd testing, since external testers provide more objective safety assessments.
Crowd testing is not the technique ISO 26262 specifies for safety-critical boundary conditions; it is generally unsuited to regulated safety contexts.
Only state transition testing, since safety-critical systems have no other relevant characteristics to test.
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?
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.
Apply only equivalence partitioning to the device count, ignoring the state machine entirely.
Ignoring the state machine misses the LimitReached behavior that the boundary triggers.
Apply only state transition testing, 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 CRUD testing only, since adding a device is a create operation unrelated to any state.
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 onboarding has no independent oracle.
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's source code.
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.
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?
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.
State transition testing, since duration changes over time.
Duration here is a numeric input value, not a modeled state with transitions and events.
CRUD testing, since a parking permit record is created once.
CRUD testing targets entity lifecycle operations, not the combination of numeric and categorical fee-determining variables.
Metamorphic testing, since there is no independent oracle for parking fees.
A parking fee has a clear expected value computable from the inputs, so an independent oracle does exist here.
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 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.
It automatically computes the expected output value for every combination.
The combination table shows which combinations are selected for testing; it does not calculate expected results.
It is meant to substitute for a decision table when the same feature also has one.
A classification tree and a decision table serve related but distinct purposes; one does not substitute for the other when both are relevant.
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?
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 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.
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 — but only because 8 test cases is too small a number; sufficiency is determined by test case count, not by which conditions and combinations are covered.
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 appropriateness
Correct — functional appropriateness is defined as functions facilitating the accomplishment of specified tasks and objectives.
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.
Interoperability
Interoperability is a compatibility characteristic about exchanging information with other systems, unrelated to functional suitability.
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 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 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 is meant to substitute for defining personas or operational profiles before the session.
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?
Interoperability, part of compatibility.
Correct — exchanging data correctly between systems built by different vendors is the definition of interoperability.
Installability, part of flexibility (formerly portability).
Installability concerns installing or uninstalling software in a given environment, not exchanging data with another system.
Coexistence, which is the responsibility of the Technical Test Analyst.
Coexistence concerns systems sharing resources without interfering with each other, a different concern from data exchange, and is a Technical Test Analyst topic.
Replaceability, which concerns swapping one component for another, not data exchange.
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?
Adaptability and installability.
Correct — these are the two flexibility sub-characteristics the syllabus assigns to the Test Analyst.
Scalability and replaceability.
These flexibility sub-characteristics are typically the Technical Test Analyst's responsibility, not the Test Analyst's.
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 reviewing
Checklist-based reviewing uses a shared checklist of items to check, not individually assigned stakeholder perspectives.
Scenario-based reviewing (single generic walkthrough with no assigned viewpoints)
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 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 total number of defects found across the entire project regardless of when they were introduced.
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 number of test cases executed during a single test level.
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 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.
Finding defects in the source code, since building a state model requires access to the finished implementation's source code.
The model is built before any code exists, so it cannot be finding source code defects at this stage.
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 total number of test levels required for the project.
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 itself is miscounting defects, since a 70/30 split is statistically impossible.
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 regardless of the historical defect distribution.
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?
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.
Suppressing the second email at the notification service so users never see the duplicate, while leaving the short timeout unchanged.
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 entirely, without addressing why the original call was timing out.
Disabling retries removes a symptom-level workaround but leaves the actual mismatched timeout threshold unresolved, risking other failures.
Increasing the number of servers running the notification service, without changing the timeout value.
Adding servers does not address the mismatched timeout threshold identified as the root cause.
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 — but only because six defects is too small a sample for Ishikawa diagrams to be considered valid.
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?
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.
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.
Increasing the overall test team headcount without changing what is reviewed or tested.
More headcount without changing review or test focus does not specifically target either identified root cause category.
Redesigning the defect-tracking tool's dashboard to display these two categories in a different color scheme, without changing requirements or concurrency practices.
A visual dashboard change does not alter requirements review practices or concurrency test design, so it does not address either root cause.
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?
Orthogonal Defect Classification (ODC)
Correct — ODC is specifically built around structured attributes such as trigger, type, and impact.
Severity-based classification only (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.
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.