ISTQB Advanced (CTAL-TA v4.0) Mock Exam #1 — 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 statement correctly describes the primary focus of the Test Analyst role, as distinct from the Technical Test Analyst?
The Test Analyst focuses on business-facing testing — functional suitability and user-facing non-functional characteristics such as usability — applying black-box and experience-based techniques.
This matches the syllabus definition of the Test Analyst's scope exactly.
The Test Analyst focuses on white-box structural coverage of the source code, leaving functional testing entirely to the Technical Test Analyst.
This describes the Technical Test Analyst's structural, white-box focus, not the Test Analyst's business-facing, black-box focus.
The Test Analyst is responsible for scalability and performance characteristics, while the Technical Test Analyst covers functional suitability.
This reverses the actual split: scalability is a Technical Test Analyst concern, and functional suitability belongs to the Test Analyst.
The Test Analyst's activities are limited to writing automated unit tests during the coding phase of the lifecycle.
Unit-level automated testing sits with development/Technical Test Analyst work; the Test Analyst's scope is system, acceptance and system integration testing.
The syllabus defines the Test Analyst's scope as business-facing, functional and user-facing quality characteristics, using black-box and experience-based rather than structural techniques.
How does the Test Analyst's involvement in test activities typically differ between a sequential (e.g. V-model) and an iterative/incremental (e.g. Scrum) lifecycle?
In a sequential lifecycle, test analysis and design are largely concentrated in dedicated phases ahead of test execution; in an iterative lifecycle, the Test Analyst repeats analysis, design, implementation and execution within each short iteration alongside development.
This is the distinction the syllabus draws between the two lifecycle families.
In a sequential lifecycle the Test Analyst has no role in test design, since design is owned entirely by developers.
The Test Analyst performs test design in both lifecycle models; sequential models simply schedule it in a dedicated phase.
In an iterative lifecycle the Test Analyst performs every test activity exactly once, at project completion, regardless of how many iterations occurred.
This describes a sequential, one-pass approach, not the repeated per-iteration involvement typical of iterative lifecycles.
The difference is only that sequential lifecycles use manual testing exclusively and iterative lifecycles use only test automation.
Tooling choice is independent of lifecycle model; both models can combine manual and automated testing.
Sequential lifecycles concentrate analysis and design in dedicated phases; iterative lifecycles repeat the full set of activities each iteration.
Which two of the following are typically part of the test analysis activity, as opposed to test design, test implementation or test execution? (Choose two.)
Evaluating the test basis for completeness and testability.
A core test analysis task.
Prioritizing test conditions based on impact analysis.
Another core test analysis task.
Writing detailed low-level test cases with concrete input values and expected results.
This belongs to test design, not test analysis.
Assembling individual test procedures into an executable test suite with a defined execution order.
This belongs to test implementation, not test analysis.
Test analysis covers evaluating the test basis and prioritizing test conditions; writing concrete test cases is design, and assembling suites is implementation.
A high-level test case differs from a low-level test case primarily in that it:
Describes test conditions and expected results in abstract, business-level terms without concrete data values, whereas a low-level test case specifies concrete inputs, preconditions and step-by-step actions.
This is exactly the distinction the syllabus draws between the two.
Is always automated, while a low-level test case is always executed manually.
Automation status is independent of whether a test case is high- or low-level.
Never includes an expected result, only a statement of the test objective.
High-level test cases still include expected results, just at an abstract level.
Is written only after test execution, to document what was actually covered.
Test cases, high- or low-level, are designed before execution, not written retrospectively.
High-level test cases stay abstract; low-level test cases specify concrete data and steps.
Which two of the following are among the nine quality criteria for a well-written test case described in the CTAL-TA syllabus? (Choose two.)
Understandability.
One of the nine syllabus criteria for test case quality.
Traceability.
Another of the nine syllabus criteria for test case quality.
Automatability.
Not one of the nine named criteria in the syllabus.
Portability.
Portability is a product quality characteristic, not one of the nine test-case criteria.
Understandability and traceability are two of the nine named criteria; automatability and portability are not on that list.
The 'test oracle problem' refers to the situation where:
There is no reliable, feasible mechanism to determine the correct expected result for a given test input, so approaches such as pseudo-oracles, model-based testing or metamorphic testing are used instead.
This is the syllabus definition of the test oracle problem.
The test environment required to run a test is temporarily unavailable.
This describes an environment availability issue, not the oracle problem.
A defect report has been rejected by development without a stated reason.
This is a defect management issue, unrelated to the oracle problem.
Automated tests fail intermittently because test data has aged since it was created.
This describes test data ageing, a different concept from the oracle problem.
The oracle problem is the lack of a reliable way to determine the correct expected result.
When production data cannot be copied into the test environment because of privacy regulation such as GDPR, which practice allows realistic test data to be used while protecting personal information?
Pseudonymizing or anonymizing production-derived data, or generating synthetic data that resembles production characteristics.
These are the syllabus's named test data privacy solutions.
Copying the production database unchanged and restricting environment access to the test team only.
Access restriction alone does not satisfy data protection regulations that limit use of personal data.
Encrypting the production database in place without creating any separate test data set.
This does not create usable test data and does not address the underlying privacy concern for testers who need readable data.
Publishing an anonymized export of the production data set on a public crowd-testing platform.
Publishing data publicly, even anonymized, is not the syllabus's recommended test data practice.
Pseudonymization, anonymization and synthetic data generation are the syllabus's named solutions.
A team implementing keyword-driven testing for an insurance quoting system…
A team implementing keyword-driven testing for an insurance quoting system defines the keyword 'EnterApplicantAge' to input a value into a form field, and the keyword 'VerifyPremiumDisplayed' to check that the calculated premium matches an expected value. Both keywords are implemented once in a domain-specific keyword library and reused across dozens of test cases that combine them in different orders. Which statement correctly classifies these two keywords and the layer at which they are implemented?
'EnterApplicantAge' is an action keyword and 'VerifyPremiumDisplayed' is a verification keyword; both are implemented in the domain layer, which maps business-level keywords onto the lower-level test interface layer that interacts with the actual application.
This matches the syllabus's action/verification and domain-layer/interface-layer distinctions exactly.
'EnterApplicantAge' is a verification keyword and 'VerifyPremiumDisplayed' is an action keyword, because verification always occurs before an action in keyword-driven testing.
The two keywords are swapped, and there is no rule requiring verification before action.
Both keywords are composite keywords, because they are reused across multiple test cases; atomic keywords can only ever be used once.
Reuse frequency does not determine atomic versus composite classification; both keywords here are atomic, single-step keywords.
Both keywords are implemented directly in the test interface layer, and the domain layer is only used for reporting results.
The domain layer maps business keywords to the interface layer; it is not merely a reporting mechanism.
Action keywords perform steps, verification keywords check results; both live in the domain layer, which maps onto the lower-level test interface layer.
Chapter 2 · The Tasks of the Test Analyst in Risk-Based Testing — 3 questions
Risk-based testing, as described for the Test Analyst, consists of which two core activities? (Choose two.)
Risk analysis — identifying and assessing risks.
One of the two core risk-based testing activities.
Risk control — mitigating and monitoring identified risks.
The other core risk-based testing activity.
Risk transfer — shifting responsibility for a risk to a third party such as an insurer.
Risk transfer is one possible risk response, not one of the two named risk-based testing activities.
Cost of quality analysis — calculating the total cost of prevention, appraisal and failure.
Cost of quality is a Chapter 5 defect prevention concept, not a risk-based testing activity.
Risk analysis (identification and assessment) and risk control (mitigation and monitoring) are the two core activities, recorded in a risk register.
A Test Analyst supporting a mature e-commerce platform must decide how to select…
A Test Analyst supporting a mature e-commerce platform must decide how to select the subset of an 80,000-test regression suite to run before each biweekly release, given a fixed four-hour execution window. The team has: (a) a requirement traceability matrix linking tests to features, (b) two years of test execution history showing which tests have historically caught defects, (c) code coverage data from the last release, and (d) a change log showing which modules were modified this sprint. Based on the syllabus guidance that no single regression selection technique is universally 'best', which approach is most appropriate?
Combine impact analysis of the changed modules with history-based selection of tests that previously found defects in those areas, and evaluate the effectiveness of the resulting selection after each cycle so the approach can be adjusted.
This reflects the syllabus's guidance to combine techniques and continuously evaluate selection effectiveness.
Select tests purely at random from the full suite each cycle, since randomization removes any selection bias.
Pure random selection ignores the available impact and history data and is not the syllabus's recommended approach for regression selection under a time constraint.
Run the entire 80,000-test suite every cycle regardless of the time constraint, because impact analysis is unreliable.
The syllabus describes impact analysis as one of the most reliable regression selection techniques, and running the full suite is not feasible within the four-hour window.
Rely solely on the requirement traceability matrix, since it alone is sufficient to guarantee regression coverage without needing history-based or impact analysis input.
The syllabus states no single technique alone is sufficient; combining techniques and evaluating their effectiveness is the recommended approach.
The syllabus recommends combining impact analysis with other selection techniques and evaluating effectiveness after each cycle, since no single technique is sufficient alone.
During a risk workshop for a new patient-monitoring device's companion mobile…
During a risk workshop for a new patient-monitoring device's companion mobile app, stakeholders identify the following candidate risks: (1) the app might display an incorrect heart-rate reading due to a Bluetooth sync bug, (2) the settings screen might be confusing for elderly users, (3) the app might fail to sync data when the phone's storage is nearly full, and (4) the release might slip because a third-party SDK update is delayed. Categorizing these against the quality-model-based risk categorization referenced in the syllabus, which pair correctly separates a product risk from a project risk?
Risk (1), the incorrect heart-rate reading, is a product risk (a functional correctness/reliability issue with the product itself); risk (4), the SDK-related release slippage, is a project risk unrelated to the product's own quality characteristics.
This correctly separates a quality-characteristic issue (product risk) from a schedule/vendor dependency issue (project risk).
Risk (2), the confusing settings screen, is a project risk because usability is a subjective, non-technical concern rather than a quality characteristic.
Usability is a defined quality characteristic in the risk categorization model, making this a product risk, not a project risk.
Risk (3), the failure to sync when storage is full, is a project risk because it depends on the user's device configuration rather than the app itself.
This is still about the app's own reliability behaviour under a real operating condition, making it a product risk.
All four risks are project risks, since they were all raised during the same risk workshop.
Where a risk was raised has no bearing on whether it is a product or project risk; the classification depends on what the risk concerns.
Product risks concern the software's own quality characteristics (functional correctness, reliability, usability); project risks concern external factors like schedule and vendor dependencies.
Chapter 3 · Test Analysis and Test Design — 22 questions
In domain testing, which term describes a test point that lies exactly on the boundary between two domains, and which term describes a test point that lies inside a domain but away from any boundary?
'ON' describes a point exactly on the boundary; 'IN' describes a point inside the domain away from boundaries.
This is the correct definition of ON and IN in domain testing terminology.
'OFF' describes a point exactly on the boundary; 'ON' describes a point inside the domain away from boundaries.
ON and OFF are swapped here relative to their correct definitions.
'ON' and 'OFF' both describe points inside the domain, while 'IN' and 'OUT' both describe points outside it.
This groups the four terms incorrectly; each term has a distinct, specific meaning.
'IN' describes a point exactly on the boundary and 'OUT' describes a point just inside the domain.
IN and OUT are swapped here relative to their correct definitions.
ON is exactly on the boundary; IN is inside the domain away from boundaries; OFF and OUT are the corresponding outside-domain points.
In combinatorial testing, what distinguishes base choice coverage from pairwise coverage?
Base choice coverage varies one parameter at a time from a chosen 'base' combination, while pairwise coverage ensures every pair of values from any two parameters appears together in at least one test case.
This is the correct distinction between the two combinatorial coverage criteria.
Base choice coverage requires testing all possible combinations of every parameter, while pairwise coverage tests only a single parameter at a time.
This reverses the actual relationship; neither criterion requires full exhaustive combination.
Pairwise coverage is only applicable to Boolean parameters, while base choice coverage applies to any data type.
Pairwise coverage applies to parameters with any number of discrete values, not only Booleans.
Base choice coverage and pairwise coverage both require exhaustive testing of every combination; they differ only in the tool used to generate them.
Both criteria are specifically designed to reduce the number of test cases below the exhaustive combination count.
Base choice varies one parameter at a time from a base combination; pairwise ensures every value pair across any two parameters appears together.
In decision table testing, what does the 'don't care' symbol ('–') in a minimized decision table indicate?
The outcome of that rule does not depend on the value of that particular condition, so the condition can take any value without changing the result, allowing rules to be merged.
This is the correct meaning of the don't-care symbol in a minimized decision table.
The condition was not documented by the business and must be treated as a defect in the requirements.
The don't-care symbol is a deliberate simplification technique, not a sign of a documentation defect.
The rule is infeasible and can never occur in practice, so no test case should be derived from it.
A don't-care condition does not make a rule infeasible; the rule is still feasible and testable, just independent of that condition.
The tester has not yet decided which value to assign, and the cell must be filled in before the table is used.
The don't-care symbol is a deliberate, final notation, not a placeholder for an undecided value.
The don't-care symbol means the outcome does not depend on that condition's value, allowing rules to be merged.
Which two of the following are structural elements of a test charter, as used in experience-based / exploratory testing? (Choose two.)
Purpose — the information the session is intended to discover.
Part of the test charter's mission statement.
Setup — the resources and preconditions needed before the session starts.
One of the elements captured on a test charter / session sheet.
Budget — the monetary cost allocated to the testing project as a whole.
A test charter concerns a single exploratory session, not the project's overall budget.
Deadline — the calendar date by which the entire project must ship.
A test charter defines a session's mission, not the project's overall delivery date.
A test charter's mission format is 'Explore [target] With [resources] To discover [information]', with Purpose and Setup among its elements; it is not a project-level budget or deadline document.
A hotel booking form accepts a 'number of nights' value that must be a whole…
A hotel booking form accepts a 'number of nights' value that must be a whole number from 1 to 30 inclusive; any value outside this range is rejected. Applying domain testing with closed borders on both sides of the valid domain, which set of values gives an ON point, an OFF-below point, an OFF-above point and an IN point in a single, minimal test set?
0, 1, 30, 31, and 15 — where 1 and 30 are ON the boundaries (still valid), 0 and 31 are OFF (just outside, invalid), and 15 is IN the domain away from the boundaries.
This correctly assigns ON, OFF and IN points for a closed-border domain of 1–30.
1, 15, 30, and 45 — because domain testing requires four evenly spaced values regardless of where the boundaries fall.
Domain testing points are chosen relative to the boundaries, not by even spacing across an arbitrary range.
0 and 31 only, since the OFF points alone are sufficient to fully test a closed-border domain.
OFF points alone omit the ON and IN points needed to fully exercise the boundary and the domain interior.
1 and 30 only, treating them as OFF points, with no separate ON points required for a closed-border domain.
For a closed border, 1 and 30 are ON points (valid, on the boundary), not OFF points.
With closed borders, 1 and 30 are ON (the valid boundary values themselves); 0 and 31 are OFF (just outside); 15 is IN, away from the boundaries.
A currency conversion service takes two independent numeric inputs — 'amount'…
A currency conversion service takes two independent numeric inputs — 'amount' (domain: 0.01 to 100,000) and 'target currency count' (domain: 1 to 5) — each with its own boundaries. Comparing simplified domain coverage (Jeng) with reliable domain coverage (Forgács) for testing these two variables, which statement is correct?
Simplified domain coverage tests boundaries one variable at a time while holding others at a typical in-domain value, requiring fewer test cases; reliable domain coverage adds explicit IN and OUT points for every variable, requiring more test cases to also catch certain multi-variable defects that simplified coverage can miss.
This is the correct comparison between the two named domain coverage criteria.
Simplified and reliable domain coverage always require exactly the same number of test cases, because both are based on the same boundary values.
Reliable domain coverage adds IN and OUT points beyond what simplified coverage requires, so the counts differ.
Reliable domain coverage requires fewer test cases than simplified domain coverage, since it tests each variable independently without needing IN or OUT points.
This reverses the relationship; reliable coverage requires more test cases because it adds IN and OUT points.
Simplified domain coverage requires testing every possible combination of both variables' boundary values, making it more exhaustive than reliable domain coverage.
Simplified domain coverage is specifically designed to avoid full combinatorial exhaustion, not to require it.
Simplified coverage tests boundaries per-variable with fewer cases; reliable coverage adds IN and OUT points to catch additional multi-variable defects.
A shipping cost calculator has three parameters: 'package weight' (light…
A shipping cost calculator has three parameters: 'package weight' (light, medium, heavy), 'destination zone' (domestic, regional, international) and 'delivery speed' (standard, express). Using base choice coverage with 'light / domestic / standard' selected as the base combination, how many test cases are needed in total to achieve base choice coverage?
6 test cases — one base test case, plus one additional test case for each non-base value of each parameter (2 for weight, 2 for destination zone, 1 for delivery speed).
1 (base) + 2 + 2 + 1 = 6, matching the base choice coverage formula.
18 test cases, since base choice coverage requires testing every combination of all three parameters' values.
18 is the exhaustive combination count (3×3×2); base choice coverage is specifically designed to avoid this.
3 test cases, one for each parameter, regardless of how many values each parameter can take.
This ignores how many non-base values each parameter has, undercounting the required test cases.
8 test cases — the total count of all values across the three parameters (3 + 3 + 2).
This sums the parameter value counts directly instead of applying the base-plus-non-base-values formula, which gives 6, not 8.
Base choice coverage needs one base test case plus one test case per non-base value of each parameter: 1 + 2 + 2 + 1 = 6.
The same shipping cost calculator (weight: 3 values, zone: 3 values, speed: 2…
The same shipping cost calculator (weight: 3 values, zone: 3 values, speed: 2 values) needs pairwise coverage of every value combination between any two parameters. Exhaustive testing of all combinations would require 3×3×2 = 18 test cases. Which statement correctly describes what pairwise coverage achieves instead?
Pairwise coverage typically needs substantially fewer test cases than exhaustive testing (often around 9 for this parameter set) while still ensuring every pair of values from any two parameters is exercised together at least once, exploiting the fact that most real-world failures are triggered by interactions of only one or two parameters.
This correctly describes the reduction and rationale behind pairwise coverage.
Pairwise coverage requires exactly the same 18 test cases as exhaustive testing, because every parameter pair must still appear in a fully combined table.
Pairwise coverage is specifically designed to require fewer cases than the full 18-case exhaustive combination.
Pairwise coverage only tests parameters in pairs of two, so the third parameter (delivery speed) is left completely untested.
All three parameters are included; pairwise coverage ensures every pair of parameter values is covered, not that only two parameters are tested at all.
Pairwise coverage is designed to detect every defect in the system, including those that only occur from three-way or higher-order parameter interactions.
Pairwise coverage targets one- and two-way interactions specifically; higher-order interaction defects may be missed.
Pairwise coverage exploits the fact that most real-world failures come from one- or two-parameter interactions, needing far fewer cases than exhaustive combination.
A team is testing a JSON parser that must accept syntactically valid input and…
A team is testing a JSON parser that must accept syntactically valid input and reject invalid input without crashing. Because there is no practical way to generate all conceivable malformed inputs by hand, and no simple oracle exists to predict the parser's exact internal state for arbitrary garbled input, which approach best fits the situation, and what must the team additionally provide for it to be effective?
Random or fuzz testing generating large volumes of both well-formed and malformed inputs automatically, combined with an automated oracle — for example, a rule that the parser must never crash or hang, only accept or cleanly reject input — since random testing needs some automatable check rather than manual verification of each result.
This correctly identifies random/fuzz testing and the need for an automatable oracle rule.
Manual boundary value analysis of every character position in the input string, since random testing cannot be applied to text-based formats such as JSON.
Random and fuzz testing are commonly applied to text-based formats like JSON; this is not a restriction the syllabus describes.
A single scripted test case reproducing one known malformed input, since random testing is unnecessary once one example of an invalid case has been documented.
One scripted case does not address the huge variety of malformed inputs that random/fuzz testing is meant to explore.
Random testing without any oracle at all, since the syllabus states that random testing does not require any means of checking the result.
Random testing still needs some form of automated oracle to determine whether a result is acceptable; it is not oracle-free.
Random/fuzz testing needs an automatable oracle, such as a rule about crashing versus clean rejection, since manual verification of huge volumes of generated input is impractical.
A contact management feature exposes these operations on a 'Contact' entity…
A contact management feature exposes these operations on a 'Contact' entity: Create, Read, Update (edit phone number), and Delete. A CRUD matrix built from the requirements shows that Update and Delete are both documented, but no test case exists that creates a contact and then attempts to delete it twice in a row (deleting an already-deleted contact). Which two aspects of CRUD testing does this scenario primarily illustrate? (Choose two.)
Completeness — checking statically whether all four CRUD operations are documented for the entity.
The matrix shows the operations are all documented, which is the completeness check.
Consistency — checking dynamically, including negative test cases such as operating on data that no longer exists.
The missing double-delete test case is exactly the kind of dynamic, negative consistency check the syllabus describes.
CRUD coverage computed purely from the number of entities in the data model, independent of which operations are tested.
CRUD coverage is based on which operations are exercised for an entity, not merely the count of entities in the model.
The test oracle problem, since there is no way to know whether a contact was actually deleted.
Whether a contact was deleted can be verified directly (e.g., a subsequent read fails), so this is not an oracle problem scenario.
Completeness checks statically that all operations are documented; consistency checks dynamically, including negative cases on stale or missing data.
A subscription's state machine has states New → Trial → Active → Suspended →…
A subscription's state machine has states New → Trial → Active → Suspended → Active → Cancelled, with transitions: New–[start trial]→Trial, Trial–[convert]→Active, Active–[missed payment]→Suspended, Suspended–[payment received]→Active, Active–[cancel]→Cancelled. Achieving 0-switch coverage (Chow) means testing every individual transition once; 1-switch coverage additionally requires testing every valid pair of consecutive transitions. Which statement correctly compares the two coverage levels for this state machine?
0-switch coverage requires one test path exercising each of the five transitions individually at least once, while 1-switch coverage additionally requires paths that cover every valid two-transition sequence, such as Active→Suspended immediately followed by Suspended→Active, which is a stronger and more expensive criterion.
This correctly compares 0-switch and 1-switch (N-switch) coverage as defined by Chow.
0-switch and 1-switch coverage require exactly the same test paths, since both only test each transition exactly once regardless of sequence.
1-switch coverage requires additional two-transition sequences beyond what 0-switch coverage requires.
1-switch coverage requires testing every transition in isolation without regard to what preceded or followed it, while 0-switch coverage requires testing full end-to-end paths through all states.
This reverses the actual definitions: 0-switch tests transitions individually, and 1-switch adds transition-pair sequences.
0-switch coverage means visiting every state without exercising any transition, while 1-switch coverage means exercising transitions but not states.
N-switch coverage is defined in terms of transitions and transition sequences, not a state-only versus transition-only distinction.
0-switch covers single transitions; 1-switch additionally covers every valid two-transition sequence, a stronger and more expensive criterion.
In the same subscription state machine, a path that starts at Active, moves to…
In the same subscription state machine, a path that starts at Active, moves to Suspended, and returns to Active (Active→Suspended→Active) forms a loop that begins and ends in the same state. Round-trip coverage (Ammann/Offutt) requires such loops to be exercised. Which statement correctly describes what round-trip coverage adds beyond simple transition coverage?
Round-trip coverage specifically requires every loop in the state graph — a path that returns to its starting state — to be tested at least once, catching defects where a sequence of transitions fails to correctly restore the object to its original state (for example, a suspended subscription that reactivates with the wrong billing date).
This is the correct definition and rationale for round-trip coverage.
Round-trip coverage only applies to state machines with a single state and no transitions, so it is irrelevant to this subscription model.
Round-trip coverage applies to any state machine containing loops, and this subscription model has such a loop.
Round-trip coverage requires that every transition be executed in the reverse of its documented direction, regardless of whether that reverse transition actually exists.
Round-trip coverage tests existing loops in the state graph, not reversed transitions that may not exist.
Round-trip coverage is another name for 0-switch coverage; the two terms describe an identical set of test paths.
Round-trip coverage specifically targets loops returning to the starting state, which is a distinct criterion from 0-switch coverage of individual transitions.
Round-trip coverage requires every loop that returns to its starting state to be tested, catching defects in how the object is restored after the loop.
A 'submit expense report' use case has a main flow (employee fills form…
A 'submit expense report' use case has a main flow (employee fills form, submits, manager approves) and an exception flow triggered when the requested amount exceeds the employee's approval limit, causing the system to route the report to a senior approver instead. A test suite currently covers only the main flow. Which test case would specifically exercise the exception flow, and why is it necessary in scenario-based testing?
Submit a report with an amount above the employee's approval limit and verify the system routes it to a senior approver instead of the regular manager — exception flows represent deviations from the main success scenario and are just as necessary to test as the main flow, since they often contain the more error-prone logic.
This directly exercises the described exception flow and reflects its testing importance.
Submit a report with a typical, in-limit amount a second time, since repeating the main flow twice is equivalent to testing an exception flow.
Repeating the main flow does not exercise the alternate routing logic that defines the exception flow.
Submit a report with no amount entered at all, since any incomplete form submission automatically counts as testing every exception flow of the use case.
An incomplete submission is a different kind of validation error and does not specifically exercise the approval-limit exception flow.
Only review the use case documentation for exception flows without executing any test case, since exception flows are informational and not meant to be tested directly.
Exception flows are executable parts of the use case and must be tested like the main flow, not merely documented.
Exception flows are deviations from the main success scenario and are just as necessary to test as the main flow, since they often contain more error-prone logic.
An online quiz feature allows a student to retake a failed quiz up to 3 times before the account is locked, with 0 retakes also possible (pass on first attempt). Applying simple loop coverage (0, 1, typical, maximum iterations), which set of test scenarios achieves this coverage?
Pass on the first attempt (0 retakes), fail once then pass (1 retake), fail twice then pass (2 retakes, a typical middle value), and fail three times reaching the retake limit (3 retakes, the maximum).
This covers 0, 1, a typical, and the maximum iteration count, matching simple loop coverage.
Only test the maximum of 3 retakes, since testing fewer retakes cannot reveal any defect related to the loop.
Simple loop coverage requires 0, 1, typical and maximum values, not the maximum alone.
Test 0 and 3 retakes only, skipping any value in between, since simple loop coverage is only concerned with the two extremes.
Simple loop coverage also requires testing 1 iteration and a typical middle value, not only the two extremes.
Test exactly 100 retakes to stress-test the loop, since simple loop coverage always includes a large multiple of the maximum as one of its values.
Simple loop coverage is defined relative to the loop's own actual maximum, not an arbitrary large multiple of it.
Simple loop coverage requires the 0, 1, a typical middle value, and the maximum iteration count to be tested.
A discount decision table has two binary conditions — 'is loyalty member' (Y/N)…
A discount decision table has two binary conditions — 'is loyalty member' (Y/N) and 'order total over $100' (Y/N) — giving four theoretically possible rules. The table as built lists only three rules: (member=Y, over100=Y)→15% discount; (member=Y, over100=N)→5% discount; (member=N, over100=Y)→5% discount. Applying the checksum procedure to verify completeness, what does it reveal, and what should be done?
The checksum procedure reveals that the combination (member=N, over100=N) is missing from the table — with two binary conditions there should be four rules (2²), and only three are present — so a fourth rule must be added specifying the outcome (likely 0% discount) for a non-member ordering $100 or less.
This correctly applies the checksum procedure and identifies the missing rule.
The checksum procedure confirms the table is complete, because three rules are always sufficient regardless of how many conditions the table has.
With two binary conditions the checksum requires four rules (2²), so three rules is incomplete.
The checksum procedure reveals that rule (member=Y, over100=N) overlaps with rule (member=N, over100=Y), so one of the two must be deleted as a duplicate.
These two rules have different condition combinations and are not duplicates; the actual defect is a missing rule, not an overlap.
The checksum procedure is used only to verify decision tables with three or more conditions, so it cannot be applied to a table with just two binary conditions.
The checksum procedure applies to decision tables with any number of conditions, including two.
The checksum procedure checks that the number of rules matches 2 to the power of the number of binary conditions; here 2²=4 rules are expected but only 3 exist.
A shipping fee decision table has three conditions: 'order weight over 20kg'…
A shipping fee decision table has three conditions: 'order weight over 20kg' (Y/N), 'destination is international' (Y/N), and 'express delivery selected' (Y/N) — giving 8 possible rule combinations in a full table. The business confirms that whenever 'international' is Y, the fee is always the same flat rate regardless of weight or express selection, so those four rules can be merged into one rule using '–' for the other two conditions. How many distinct test cases does the minimized table now require, compared with the full table?
The minimized table requires 5 test cases instead of 8 — the four rules with 'international = Y' collapse into a single rule using don't-care symbols for the other two conditions, while the four rules with 'international = N' remain distinct because weight and express selection still affect the outcome there.
4 rules collapse to 1, plus the 4 unchanged international=N rules, gives 5 total test cases.
The minimized table still requires all 8 test cases, since minimizing a decision table only changes its appearance and never reduces the number of test cases needed.
Minimizing with don't-care symbols does reduce the number of distinct test cases required, from 8 to 5 here.
The minimized table requires only 1 test case in total, since merging any rules with don't-care symbols eliminates the need to test the remaining rules separately.
Only the four international=Y rules merge; the four international=N rules remain distinct and still need separate test cases.
The minimized table requires 4 test cases, one for each of the original conditions, regardless of how many rules exist in the table.
The required test case count is based on the number of distinct rules after minimization, not the number of conditions.
The four rules sharing international=Y collapse into one via don't-care symbols, while the four rules with international=N remain distinct, giving 5 total.
A route-planning feature powered by a machine-learning model recommends the…
A route-planning feature powered by a machine-learning model recommends the fastest driving route between two addresses, but there is no independent way to compute the single objectively 'correct' route to compare against, since real traffic conditions vary. To test this feature using metamorphic testing, which pair of source and follow-up test cases, with which metamorphic relation, would be most appropriate?
Source test case: request a route between address A and address B. Follow-up test case: request a route between the same A and B but with the start and end swapped (B to A) over the same road network with no directional restrictions. Metamorphic relation: the total distance of the two routes should be equal, even though the exact turn-by-turn path may differ — a large unexplained discrepancy indicates a defect, without needing to know the single 'correct' route.
This defines a valid metamorphic relation that sidesteps the need for a single known-correct output.
Source test case: request a route between address A and address B. Follow-up test case: request the same route again with identical inputs. Metamorphic relation: the two results must be character-for-character identical text strings, which detects only formatting bugs and nothing about the routing logic itself.
This checks determinism of output formatting rather than a genuine property of the routing logic, missing the point of a metamorphic relation.
Source and follow-up test cases are unnecessary for AI-based features, since metamorphic testing only applies to systems that already have a reliable oracle available.
Metamorphic testing is specifically recommended for systems with a test oracle problem, such as AI-based features, not for systems that already have a reliable oracle.
Source test case: request a route with a valid address. Follow-up test case: request a route with a deliberately malformed address. Metamorphic relation: the system must return the exact same route for both inputs, since metamorphic testing requires identical outputs for any pair of inputs.
Metamorphic relations describe a meaningful expected relationship between source and follow-up outputs, not that all metamorphic test pairs must produce identical outputs.
A metamorphic relation exploits a known property (route distance symmetry) rather than requiring a single known-correct output, which suits AI-based features with an oracle problem.
A tester uses a pre-release checklist item that says 'Verify the checkout page…
A tester uses a pre-release checklist item that says 'Verify the checkout page displays the correct currency symbol for the user's selected region' — requiring the tester to actively perform an action and check its result — versus another item that says 'Confirm that the security review sign-off document has been completed', which only requires checking that something already done elsewhere was recorded. Which statement correctly classifies these two checklist item types?
The currency symbol item is a 'read-do' checklist item, requiring the tester to perform an action and observe the result directly; the sign-off item is a 'do-confirm' item, requiring only confirmation that a task performed elsewhere was completed.
This correctly matches each item to its checklist category.
Both items are 'do-confirm' items, because checklists by definition never require the tester to perform any new action.
Read-do items do require the tester to perform a new action, as the currency symbol item does here.
The currency symbol item is 'do-confirm' because it confirms the page loaded, and the sign-off item is 'read-do' because it involves reading a document.
The classifications here are swapped relative to their correct definitions.
Checklist items cannot be classified as 'read-do' or 'do-confirm'; that distinction only applies to formally scripted test cases.
Read-do and do-confirm are specifically checklist item categories described in the syllabus, not scripted test case categories.
Read-do items require performing an action and observing the result; do-confirm items only require confirming a prior task was completed.
A retailer is deciding whether to use crowd testing to validate a new mobile…
A retailer is deciding whether to use crowd testing to validate a new mobile checkout flow across a wide variety of real devices, operating system versions and network conditions shortly before a major sale event, on a tight one-week deadline. Weighing the syllabus's stated advantages and disadvantages of crowd testing, which combination best reflects an appropriate use of it here?
Crowd testing is well suited here because it can quickly cover a wide diversity of real devices and network conditions that an in-house lab cannot easily replicate; however, the team should still plan for variable tester skill levels, potential confidentiality exposure of the unreleased feature, and less predictable turnaround and reporting consistency than an in-house team.
This reflects both the advantages and the disadvantages the syllabus attributes to crowd testing.
Crowd testing should be avoided entirely for any commercial application, because the syllabus lists no advantages to using it under any circumstance.
The syllabus lists genuine advantages of crowd testing, such as broad device and condition coverage.
Crowd testing removes any need for in-house testing once it is commissioned, since it fully covers device and condition diversity on its own.
The syllabus notes disadvantages such as variable skill levels and confidentiality risk, so in-house testing and oversight are still needed.
Crowd testing is only appropriate for testing back-end APIs and cannot be used to evaluate any user-facing mobile interface.
Crowd testing is commonly used precisely for user-facing, device-diverse scenarios like this mobile checkout flow.
Crowd testing offers real-device diversity but comes with tradeoffs in skill consistency, confidentiality and predictability that must be planned for.
A team is choosing which black-box technique class to prioritise for a new…
A team is choosing which black-box technique class to prioritise for a new insurance-claims workflow. They expect the most likely defects to come from users navigating the claim status through several distinct stages (submitted, under review, approved, paid) in unexpected orders, rather than from bad input values or business-rule interactions. Which technique class is the primary match for this expected defect type, and which specific technique from that class fits best?
Behavior-based techniques are the primary match, since they focus on sequences of user or system behavior; state transition testing specifically fits, since it models the claim's distinct stages and validates both valid and invalid transitions between them.
This correctly maps the described defect type (unexpected stage ordering) to the behavior-based class and state transition testing.
Data-based techniques are the primary match, since any workflow with multiple stages is, by definition, a data-based testing problem; boundary value analysis fits best.
Data-based techniques target input value domains, not sequences of stage transitions, so this is not the primary match here.
Rule-based techniques are the primary match, since claim stages are business rules; decision table testing fits best regardless of the sequential nature of the stages.
Decision tables model condition combinations, not ordered sequences of stages, so this does not fit the described defect type as well as state transition testing.
Experience-based techniques are the primary match, since any workflow issue can only be found through unscripted exploratory testing, not through any formal technique.
Formal behavior-based techniques such as state transition testing are well suited to this scenario; experience-based testing is not the only applicable option.
Behavior-based techniques target sequences of behavior; state transition testing specifically models distinct stages and their valid/invalid transitions.
An account balance state machine has states 'Normal' and 'Overdrawn', with a…
An account balance state machine has states 'Normal' and 'Overdrawn', with a transition to 'Overdrawn' triggered whenever a withdrawal causes the balance to drop below $0, and a transition back to 'Normal' triggered when a deposit brings the balance back to $0 or above. The team wants to combine state transition testing with boundary value analysis on the balance amount, as recommended in the syllabus for techniques that can be nested within one another. Which set of test cases best combines both techniques for this scenario?
From a starting balance just above zero (e.g., $0.01), perform a withdrawal that leaves the balance at exactly $0 (stays Normal — boundary ON), a withdrawal that leaves it at -$0.01 (transitions to Overdrawn — boundary OFF), and from Overdrawn, a deposit that brings the balance to exactly $0 (transitions back to Normal — boundary ON) versus one that leaves it at -$0.01 (remains Overdrawn — boundary OFF); this exercises both the state transitions and the exact boundary values that trigger them.
This nests boundary value analysis inside the state transition tests, targeting the precise values at which each transition fires.
Test the state transitions only with arbitrary balance values such as $500 and -$500, since combining boundary value analysis with state transition testing is not something the syllabus describes as useful.
The syllabus explicitly describes nesting boundary value analysis within state transition testing as a valuable technique combination; arbitrary far-from-boundary values would miss the exact trigger point defects.
Test only the boundary values of the balance ($0 and just below it) without ever triggering the Overdrawn or Normal state transitions, since boundary value analysis and state transition testing cannot be combined.
The two techniques are specifically meant to be combined, using boundary values as the trigger points for the transitions, not tested in isolation from the transitions.
Test every possible balance value from -$1,000,000 to $1,000,000 in increments of $1, since combining techniques means exhaustively testing the full numeric range rather than selecting specific boundary and transition points.
Combining techniques means selecting specific, meaningful boundary and transition points, not exhaustively testing every value in a large range.
Combining BVA within state transition testing means choosing the exact balance values that both trigger and sit at the boundary of each transition.
A loan approval process is modeled as an activity diagram: an application…
A loan approval process is modeled as an activity diagram: an application enters, an automated credit check runs, and then a decision point routes the application to 'auto-approve', 'auto-reject', or 'manual underwriting review' depending on the credit score and requested amount. The team wants to apply 'process cycle testing', which the syllabus describes as combining scenario-based testing of the process flow with decision coverage of the decision point's outcomes. Which test set best reflects this combined approach?
Test cases that each follow a complete, realistic path through the activity diagram from application entry to a final outcome (satisfying scenario-based/path coverage), designed collectively so that every one of the three possible outcomes at the credit-score-and-amount decision point (auto-approve, auto-reject, manual review) is exercised by at least one path (satisfying decision coverage), rather than testing the decision point's logic in isolation from the surrounding process flow.
This is the syllabus's description of process cycle testing as the combination of scenario-based path coverage and decision coverage.
Test only the decision point's three outcomes in isolation, using stubbed inputs, without ever executing a complete path through the surrounding activity diagram, since process cycle testing is only concerned with decision coverage.
Process cycle testing specifically combines decision coverage with full scenario-based path coverage, not decision coverage in isolation.
Test only one complete path through the activity diagram ending in 'auto-approve', since scenario-based testing by itself is sufficient and decision coverage of the other two outcomes is unnecessary.
Process cycle testing requires decision coverage of all outcomes at the decision point, not just one path ending in a single outcome.
Test the activity diagram using state transition N-switch coverage instead of decision coverage, since process cycle testing is simply another name for N-switch coverage applied to activity diagrams.
Process cycle testing is defined as scenario-based testing combined with decision coverage, not as N-switch coverage applied to activity diagrams.
Process cycle testing combines full-path scenario coverage with decision coverage of the process's decision points, rather than treating either technique in isolation.
Chapter 4 · Testing Quality Characteristics — 4 questions
ISO/IEC 25010 splits functional suitability into three sub-characteristics. Which option correctly distinguishes them?
Functional completeness (whether all specified functions are present), functional correctness (whether functions produce the correct results with the needed precision), and functional appropriateness (whether the functions facilitate the intended tasks and objectives).
These are the three ISO/IEC 25010 sub-characteristics of functional suitability.
Functional completeness, functional performance, and functional security — three sub-characteristics all concerned with non-functional aspects of the system.
Performance and security are separate top-level quality characteristics, not sub-characteristics of functional suitability.
Functional correctness, functional usability, and functional compatibility, which are actually three separate top-level quality characteristics, not sub-characteristics of functional suitability.
Usability and compatibility are their own top-level characteristics, not sub-characteristics of functional suitability.
Functional completeness and functional correctness only; ISO/IEC 25010 does not define a third sub-characteristic for functional suitability.
ISO/IEC 25010 defines a third sub-characteristic, functional appropriateness, in addition to completeness and correctness.
Functional completeness, correctness and appropriateness are the three sub-characteristics of functional suitability.
Which two techniques are described for evaluating usability, combining ISO/IEC 25010 interaction capability with ISO/IEC 25019 beneficialness? (Choose two.)
Usability test sessions using personas and operational profiles.
A named technique for evaluating usability.
Standardized questionnaires such as SUMI and WAMMI.
Another named technique for evaluating usability.
Automated code-coverage analysis of the user interface layer.
Code coverage measures structural test coverage, not usability quality-in-use.
Penetration testing of the authentication endpoints.
Penetration testing addresses security, not usability.
Usability test sessions with personas/operational profiles, and standardized questionnaires like SUMI and WAMMI, are the syllabus's named usability evaluation techniques.
Within the flexibility (portability) quality characteristic, which sub-characteristics fall under the Test Analyst's responsibility, as opposed to the Technical Test Analyst's?
Adaptability and installability are Test Analyst responsibilities, while scalability is covered under performance testing (CT-PT) and replaceability falls to the Technical Test Analyst (CTAL-TTA).
This matches the syllabus's stated division of flexibility sub-characteristics across roles and certifications.
Scalability and replaceability are Test Analyst responsibilities, while adaptability and installability belong entirely to the Technical Test Analyst.
This is the reverse of the actual division described in the syllabus.
All four sub-characteristics of flexibility — adaptability, installability, scalability and replaceability — are equally the Test Analyst's sole responsibility.
Scalability and replaceability are explicitly assigned elsewhere (CT-PT and CTAL-TTA respectively), not to the Test Analyst.
None of the flexibility sub-characteristics are covered at the CTAL-TA level; they are exclusively addressed in the CT-PT syllabus.
Adaptability and installability are explicitly covered as Test Analyst responsibilities in the CTAL-TA syllabus.
Adaptability and installability are Test Analyst concerns; scalability belongs to performance testing (CT-PT) and replaceability to the Technical Test Analyst.
Within the compatibility quality characteristic, which sub-characteristic is the Test Analyst's responsibility, and which is the Technical Test Analyst's?
Interoperability — the system's ability to exchange and use data with other systems — is the Test Analyst's responsibility; coexistence — the ability to perform required functions while sharing a common environment with other software — falls to the Technical Test Analyst.
This matches the syllabus's stated division of compatibility sub-characteristics.
Coexistence is the Test Analyst's responsibility and interoperability is the Technical Test Analyst's, exactly the reverse split.
This reverses the actual division described in the syllabus.
Both interoperability and coexistence are exclusively Technical Test Analyst responsibilities, with no involvement from the Test Analyst.
Interoperability is explicitly a Test Analyst responsibility, not solely a Technical Test Analyst one.
Compatibility as a whole is not addressed at the Advanced Level; it is only introduced at the Foundation Level.
Compatibility, including interoperability and coexistence, is explicitly addressed at the Advanced Level in this chapter.
Interoperability is a Test Analyst concern; coexistence is a Technical Test Analyst concern.
Chapter 5 · Software Defect Prevention — 8 questions
Which set of terms correctly matches the metrics used to evaluate defect prevention effectiveness: the percentage of defects removed before release, the percentage of defects found in the same phase they were introduced, and the total cost associated with achieving and failing to achieve quality?
Defect removal efficiency (DRE), phase containment effectiveness (PCE), and cost of quality, respectively.
These are the correctly matched definitions in the order given.
Defect detection percentage (DDP), root cause analysis (RCA), and cost of quality, respectively — DDP and RCA describe the wrong two metrics for these definitions.
DDP measures a different comparison (defects found vs. total known) and RCA is a technique, not a percentage metric; neither matches the first two definitions given.
Phase containment effectiveness (PCE), defect removal efficiency (DRE), and test gap analysis, respectively — the first two are swapped and the third metric does not measure cost.
The first two terms are swapped relative to their actual definitions, and test gap analysis does not measure total cost of quality.
Cost of quality, defect removal efficiency (DRE), and phase containment effectiveness (PCE), respectively — all three definitions are shifted by one position.
All three terms are shifted out of their correct order relative to the given definitions.
Defect removal efficiency, phase containment effectiveness, and cost of quality are the three named metrics/concepts, in that order.
Which two of the following are among the five review techniques described for defect prevention? (Choose two.)
Perspective-based reading — reviewers adopt distinct stakeholder viewpoints.
One of the five named review techniques.
Role-based reading — reviewers are assigned specific roles to guide their focus.
Another of the five named review techniques.
Automated static analysis — a tool scans the code without any human reviewer.
This is a static analysis technique, not one of the five human review techniques described.
Pair programming — two developers write code together in real time.
Pair programming is a development practice, not one of the five named review techniques.
Perspective-based and role-based reading are two of the five named review techniques; automated static analysis and pair programming are not among them.
After a release, defect cluster analysis shows that 40% of all post-release…
After a release, defect cluster analysis shows that 40% of all post-release defects trace back to a single 'payment reconciliation' module, even though that module makes up only 8% of the codebase. During the corresponding test phase, only 55% of the total defects eventually found in that module were actually detected before release (the defect detection percentage for that module). What do these two figures together suggest about the test effort for this release?
The payment reconciliation module is a defect cluster — a disproportionate concentration of defects — and its low defect detection percentage (55%) indicates that testing for that specific module was comparatively weak, so future test effort and review focus should be increased there rather than spread evenly across the whole codebase.
This correctly interprets both metrics together to point to a specific, targeted improvement.
The figures indicate that the payment reconciliation module is actually one of the most reliable parts of the system, since a high defect count simply reflects how much functionality it contains.
The module holds a disproportionate share of defects relative to its small size, which indicates a defect cluster rather than reliability.
The 55% defect detection percentage means the module is fully tested, since any percentage above 50% is considered complete coverage under the syllabus's defect prevention guidance.
The syllabus does not treat 50% as a completeness threshold; 55% still means nearly half the module's defects escaped to production.
The two figures are unrelated; defect cluster analysis and defect detection percentage measure entirely independent aspects of the system with no bearing on where to focus future test effort.
Together, the two figures point directly to where test effort was insufficient, so they are not unrelated for this purpose.
A defect cluster combined with a low defect detection percentage indicates the module received disproportionately weak test effort relative to its defect concentration.
A recurring defect keeps causing incorrect tax calculations on invoices. Root…
A recurring defect keeps causing incorrect tax calculations on invoices. Root cause analysis using the 'five whys' technique proceeds: the tax is wrong → because the tax rate table wasn't updated → because the update process is manual → because there is no automated trigger from the regulator's rate-change notifications → because no one owns monitoring for those notifications. Which statement best describes how this result should be used, consistent with root cause analysis guidance?
The final 'why' identifies a process gap — the lack of ownership for monitoring regulatory rate changes — as the true root cause, so the corrective action should address that ownership and monitoring gap rather than simply patching the tax rate table for this one incident, which would only fix the symptom.
This reflects the purpose of root cause analysis: addressing the underlying cause rather than the surface symptom.
Root cause analysis stops at the first 'why' by definition, so the correct root cause here is simply 'the tax is wrong', and no further investigation is needed.
Root cause analysis is meant to dig past the immediate symptom through successive 'whys' to reach an underlying cause.
Because five whys produced five separate causes, all five should be treated as equally likely candidates and no single root cause should be selected.
The five whys technique is a causal chain, not five independent candidate causes; the final why represents the identified root cause.
The five whys technique is only applicable to hardware defects, so this software tax-calculation issue should instead be analyzed using only a Pareto chart.
Five whys is a general-purpose root cause analysis technique applicable to software defects, not limited to hardware.
The last 'why' identifies the true root cause (an ownership/process gap); corrective action should target that, not just the symptom.
A defect is logged as: 'the confirmation email is sent, but it lists the wrong shipping address because the address-formatting function was never called after a recent refactor.' Using Orthogonal Defect Classification (ODC), which defect type best classifies the root cause of this defect, and why?
A 'missing function/algorithm' or equivalent 'missing' defect type — the correct address-formatting logic exists but is simply not invoked, so the defect is best classified by what is absent from the flow rather than by an incorrect value or interface mismatch.
This matches ODC's classification approach based on what kind of code change fixes the defect — here, adding a missing call.
'Checking' defect type, since the description mentions the confirmation email being sent, which ODC always classifies as a checking-related defect regardless of the underlying cause.
ODC classification depends on the actual root cause of the defect, not on which feature happens to be mentioned in the description.
'Timing/serialization' defect type, since any defect involving an email being sent is, by ODC convention, always timing-related.
There is no such blanket rule in ODC; the root cause here is a missing function call, not a timing issue.
ODC does not classify defects by root cause at all, only by which tester reported them.
ODC is specifically a root-cause- and fix-type-oriented classification scheme, not a scheme based on who reported the defect.
ODC classifies defects by what kind of fix is needed; a function that exists but is never invoked is best classified as a 'missing' type defect.
A team builds a formal state model of a subscription lifecycle purely to help…
A team builds a formal state model of a subscription lifecycle purely to help design test cases via model-based testing, and during that modeling exercise, two business analysts realize the specification itself is ambiguous about what happens when a payment fails during a trial period — a gap neither had noticed before. Which two benefits does the syllabus describe for modeling activities like this? (Choose two.)
They can uncover defects in the specification itself.
Exactly what happened here — the ambiguity found during modeling.
The resulting model can feed automated model-based test case generation.
A named benefit of building formal models for testing purposes.
They eliminate the need for any further test design once the model exists.
A model supports test design; it does not eliminate the need for further test design activity.
They ensure that the resulting code will contain no residual defects.
Modeling activities help find and prevent certain defects but cannot ensure the absence of all residual defects in the code.
Modeling activities can uncover specification defects and feed model-based test generation; they do not eliminate further test design or guarantee defect-free code.
Over the last three releases, defect detection percentage (DDP) for the…
Over the last three releases, defect detection percentage (DDP) for the 'reporting' module has been declining (78% → 65% → 52%), while root cause analysis of escaped defects in that module repeatedly points to the same underlying cause: requirements for reporting features are written by a different team than the one that reviews and tests them, and that team is not included in requirement reviews. Test gap analysis confirms the test basis for 'reporting' has not been updated to reflect two recent requirement changes. Which corrective action set best addresses the actual root cause rather than only the symptom?
Include the reporting requirements team in requirement reviews going forward (addressing the structural root cause identified by RCA), update the outdated test basis to reflect the two missed requirement changes (closing the specific gap found by test gap analysis), and track DDP for the module over subsequent releases to confirm the trend reverses — treating the declining DDP as a symptom that data-driven, targeted process change should fix, not just adding more test execution time to the current basis.
This combines the RCA finding, the test gap analysis finding and the DDP trend into a coherent, targeted corrective action.
Simply add more testers to execute more test cases against the current, unchanged test basis for the reporting module, since declining DDP always means more test execution effort is needed rather than fixing the test basis itself.
Adding execution effort against an outdated, incomplete test basis does not address the identified root cause — the process gap and stale requirements coverage.
Stop measuring DDP for the reporting module going forward, since a declining trend across three releases indicates the metric itself is unreliable and should be discontinued.
A consistent declining trend is meaningful data pointing to a real process problem, not evidence that the metric itself is unreliable.
Move the entire reporting module to a different team without changing the requirement review process, treating the metric decline as a staffing problem unrelated to requirement review practices or the outdated test basis.
The root cause analysis specifically points to a requirement review process gap and an outdated test basis, not to which team owns the module.
Combining RCA, DDP trend and test gap analysis points to a structural process gap (exclusion from requirement reviews plus a stale test basis), which should be corrected directly rather than papering over with more execution effort.
A project's defect arrival pattern over the test phase is plotted and compared…
A project's defect arrival pattern over the test phase is plotted and compared against the classic Rayleigh model, which predicts defects should be found at a rising rate, peak partway through the phase, and then taper off as the codebase stabilizes. In this release, however, the defect arrival rate is still rising sharply in the final week before the planned release date, with no sign of a peak or taper. Combined with a test gap analysis showing that 30% of medium-risk requirements still have no executed test case, what is the most defensible interpretation and recommendation for the release decision?
A still-rising defect arrival rate this late in the test phase deviates from the expected Rayleigh pattern and, together with the untested 30% of medium-risk requirements, suggests testing is far from complete rather than that the product has stabilized; recommend delaying the release (or reducing scope) until the arrival rate shows a genuine peak and taper and the coverage gap on medium-risk requirements is closed, rather than treating a rising defect count as an unrelated coincidence.
This correctly combines both analyses into a single, defensible release-readiness judgment.
A rising defect arrival rate late in the test phase is a positive sign under the Rayleigh model, since it always means the team is finding defects faster and is therefore ready to release sooner than planned.
The Rayleigh model expects the arrival rate to peak and then taper by this point; a still-rising rate late in the phase is a deviation suggesting instability, not readiness.
The untested 30% of medium-risk requirements can be safely ignored for the release decision, since test gap analysis and defect arrival pattern analysis measure unrelated aspects of release readiness with no combined bearing on the decision.
Both analyses point toward incomplete testing and should be combined, not treated as unrelated, when assessing release readiness.
The Rayleigh model is only a historical curiosity with no practical use in release decisions, so the defect arrival trend should be disregarded entirely in favor of relying solely on the fixed calendar release date.
The syllabus presents defect arrival pattern analysis, including the Rayleigh model, as a practical input to release decisions, not something to disregard in favor of the calendar alone.
A still-rising defect arrival rate combined with an untested requirement gap both point away from readiness; the two analyses should be combined, not treated in isolation, when making the release decision.