ISTQB Advanced (CTAL-TA v4.0) Mock Exam #1 — Questions & Answers

The Test Analyst focuses on white-box structural coverage of the source code, because measuring statement and branch coverage is the most objective way to show that the business requirements have been exercised.

The Test Analyst owns scalability and performance characteristics, while the Technical Test Analyst covers functional suitability, since performance is what business stakeholders notice first.

The Test Analyst's activities are limited to writing automated unit tests during the coding phase, because defects are cheapest to remove at the point where the code is written.

In a sequential lifecycle the Test Analyst takes no part in test design, because detailed design is owned by the developers who wrote the component specifications, and the Test Analyst merely executes the scripts those developers produce once the completed build is handed over for system testing at the end of the development phase.

In an iterative lifecycle the Test Analyst performs each test activity once, at project completion, because the features delivered in earlier iterations are not considered stable enough to analyse or design tests against until the final increment has been integrated and the release candidate assembled.

The difference is one of tooling rather than timing: sequential lifecycles rely on manual testing because their documentation is detailed enough to follow by hand, while iterative lifecycles rely on automation to keep pace with the delivery rhythm.

Writing concrete input values for each test case.

Assembling individual test procedures into an executable test suite with a defined execution order.

Is written to be executed by an automation tool, whereas a low-level test case is written for a human tester, since the level of abstraction in a test case is determined by how it will be run rather than by how much detail it records.

States the test objective and leaves the expected result out, because the expected result can be derived from the requirement at execution time by whoever happens to run the test.

Is produced after execution to document what was actually covered, because coverage can be described at a business level once the detailed steps taken are known.

Automatability by a tool.

Portability.

The test environment needed to run a test is unavailable for long periods, so the team has to predict what the result would have been instead of observing it, which makes the expected outcome a matter of judgement rather than measurement.

A defect report is rejected by development without a stated reason, leaving the tester unable to establish whether the behaviour that was observed is in fact a failure or the intended design of the feature under test.

Automated tests fail intermittently because the test data has aged since it was created, so the expected results recorded in the scripts no longer match what the application now produces for that data set, and the suite has to be re-baselined before it can be trusted.

Copy the production database unchanged and restrict environment access to the test team, since limiting who is able to read the data satisfies the regulation.

Encrypt the production database in place and give testers the decryption key, since data that is held encrypted at rest is no longer treated as personal data.

Publish an anonymized export on a public crowd-testing platform so that more testers can exercise realistic data.

'EnterApplicantAge' is a verification keyword and 'VerifyPremiumDisplayed' is an action keyword, because a keyword that supplies a value to the application is classified by the check it enables, while a keyword that reads a calculated figure is classified by the comparison it drives.

Both keywords are composite keywords, because classification depends on how widely a keyword is reused across a suite: a keyword invoked by dozens of test cases is treated as composite, whereas an atomic keyword is one written for a single test case and retired with it.

Both keywords are implemented directly in the test interface layer, because keywords naming business concepts such as applicant age and premium are resolved to application controls at that layer, while the domain layer gathers the results of those keywords for reporting.

Risk transfer to a third-party insurer.

Cost of quality analysis — calculating the total cost of prevention, appraisal and failure.

Select tests at random from the full suite each cycle, since randomisation removes selection bias and, over several releases, gives every test in the regression suite an equal chance of being executed within the four-hour window, independently of any assumption about where the code changed.

Run the entire 80,000-test suite each cycle and extend the execution window as needed, since any subset chosen by impact analysis leaves unexercised code paths that could regress.

Rely on the requirement traceability matrix alone, since a matrix linking every test to a feature already shows which features are covered and makes history-based input redundant.

Risk (2), the confusing settings screen, is a project risk, because usability findings are gathered from stakeholder opinion during a workshop rather than measured against a specification, and risks that cannot be measured objectively are grouped with schedule and resource risks.

Risk (3), the failure to sync when storage is nearly full, is a project risk, because the triggering condition arises from the end user's own device configuration, and conditions outside the delivered software are treated as environmental project risks.

Risks (1) and (3) are both project risks, because each depends on a hardware or connectivity factor — Bluetooth and on-device storage — that the development team does not itself build or control.

'OFF' describes a point exactly on the boundary; 'ON' describes a point inside the domain away from boundaries.

'ON' and 'OFF' both describe points inside the domain, while 'IN' and 'OUT' both describe points outside it.

'IN' describes a point exactly on the boundary and 'OUT' describes a point just inside the domain.

Base choice coverage requires every possible combination of every parameter to be tested, while pairwise coverage reduces the effort by varying a single parameter at a time from a chosen starting combination of parameter values.

Pairwise coverage applies to Boolean parameters, since a pair can be formed from two values, while base choice coverage handles parameters of any data type.

Both criteria cover every combination of every parameter, and differ in nothing more than the tool normally used to generate the resulting test suite.

The condition was not documented by the business, so the cell marks a gap in the requirements and the rule should be referred back for clarification before any test case is derived from it.

The rule is infeasible and cannot occur in practice, so the dash marks it as unreachable and the tester may drop it from the set of rules for which test cases are derived, because no combination of inputs can satisfy it.

The tester has not yet chosen a value for that condition, so the cell is a placeholder that must be filled in before the table is used.

Budget — the monetary cost allocated to the testing project as a whole for the financial year.

Deadline — the project's contractual ship date.

1, 15, 30 and 45 — domain testing uses four evenly spaced values across the input range so that the interior of the domain is sampled just as thoroughly as its edges are, which keeps the test set balanced.

0 and 31 — the two OFF points sit immediately outside the valid range, and a defect in a closed border shows itself as soon as those two values are correctly rejected by the booking form.

1 and 30, treated as OFF points — with a closed border the extreme valid values are the ones lying off the domain, so no separate ON or IN point is required for this range of nights.

Simplified and reliable domain coverage require the same number of test cases here, because both criteria are derived from the same four boundary values — 0.01, 100,000, 1 and 5 — and differ in nothing more than the order in which those boundary tests are documented and executed, which makes the choice between them a matter of reporting style.

Reliable domain coverage needs fewer test cases than simplified domain coverage, because it treats each variable independently and therefore has no need for the IN and OUT points that simplified coverage adds to every variable's boundary set, which is what makes it the cheaper of the two to apply here. The same boundary values serve both criteria.

Simplified domain coverage requires every combination of both variables' boundary values to be tested, which makes it the more exhaustive of the two criteria, while reliable domain coverage samples a single boundary per variable and accepts the gaps that leaves between the two input ranges. Those gaps are accepted as the price of the smaller suite.

18 test cases — base choice coverage fixes a base combination and then requires every remaining combination of the three parameters to be exercised against it, which comes to 3 x 3 x 2 in total.

3 test cases — one per parameter, since the base combination already supplies a value for each of the other two parameters.

8 test cases — the number of values available across the three parameters, counted as 3 + 3 + 2.

Pairwise coverage needs the same 18 test cases as exhaustive testing for this parameter set, because every pair of values drawn from any two parameters appears together in a suite exactly when the full three-parameter combination table has been built out in its entirety, so pairwise saves documentation effort rather than execution effort for the same coverage.

Pairwise coverage considers the parameters two at a time, so the third parameter — delivery speed — is held at a fixed default value and contributes no test cases of its own, which is the trade-off accepted in return for the smaller suite, and the default chosen is normally the value most common in production. Changing that default would require the suite to be regenerated.

Pairwise coverage detects the full set of defects in the system, including those arising from three-way interactions, because covering every value pair necessarily exercises every higher-order combination as well.

Manual boundary value analysis of every character position in the input string, because a parser's failures cluster at the first and last characters of each token, and a text-based format such as JSON offers a finite set of positions that can be enumerated by hand, so the effort stays bounded and the results are repeatable from one run to the next.

A single scripted test case reproducing one known malformed input, because once one invalid document has been shown to be rejected cleanly the parser's error path has been exercised, and the remaining malformed inputs follow that same path through the code, so repeating the case with other documents adds volume for the team to review rather than coverage.

Random testing with no oracle at all, because the value of fuzzing lies in the volume of input it generates rather than in checking each result, and a genuine problem announces itself as a crash that the harness records by itself, without any expected result having to be written down in advance. The volume of generated documents is what gives the technique its reach.

CRUD coverage computed purely from the number of entities in the data model, independent of which operations are tested.

The test oracle problem, since there is no way to know whether a contact was actually deleted.

0-switch and 1-switch coverage require the same set of test paths for this state machine, because each of the five transitions is exercised once under both criteria and the subscription returns to the same state afterwards, so no additional sequences are produced and the two criteria collapse onto the same paths for this five-transition model.

1-switch coverage requires each transition to be exercised in isolation with no regard for what preceded or followed it, while 0-switch coverage requires complete end-to-end paths running from New through to Cancelled, which makes 0-switch the more demanding of the two criteria for a state machine of this size and shape, and for this set of five transitions.

0-switch coverage means visiting each of the five states at least once without necessarily exercising a transition, while 1-switch coverage means exercising the transitions while disregarding which states they happen to connect, so the two criteria divide the model between states on one side and transitions on the other, leaving nothing shared between them.

Round-trip coverage applies to state machines containing a single state with no outgoing transitions, so it is irrelevant to this subscription model, whose Active, Suspended and Cancelled states are joined by five distinct transitions that each move the subscription on to a different state rather than back to the one it started from once the transition has fired.

Round-trip coverage requires each documented transition to be executed in the reverse of its stated direction, so Cancelled would have to be driven back to Active and Trial back to New in order to close every path.

Round-trip coverage is another name for 0-switch coverage, since exercising each transition once from its source state already returns the model to its starting configuration by the end of the suite.

Submit a second report with a typical, in-limit amount, because running the main flow twice in succession exercises the routing decision a second time and therefore covers the alternative branch that the exception flow represents, the routing decision being the single branch point in this use case. Any further coverage of the branch is redundant.

Submit a report with no amount entered at all, because an incomplete submission forces the system down its error-handling path, and every deviation from the main success scenario is handled by that same path, so one invalid submission stands in for the whole set of alternate flows in the use case. The approval limit is validated on the same screen.

Review the use case documentation for exception flows and record them in the traceability matrix without executing a test case, because exception flows describe how staff are expected to respond rather than system behaviour.

Test the maximum of 3 retakes, because a loop that behaves correctly at its highest iteration count has already exercised every lower count on the way there, including the case where no retake is used, so the lower counts need no scenario of their own when the loop is tested.

Test 0 and 3 retakes, because simple loop coverage is concerned with the two extremes of the iteration range and any value between them exercises the same code path through the retake counter and produces the same lock outcome.

Test 100 retakes, because simple loop coverage asks for a value well beyond the documented maximum in order to show how the loop behaves once its limit has been passed and the account lock is triggered.

The checksum procedure confirms the table is complete, because the three listed rules already cover both values of each condition at least once, and a decision table counts as complete as soon as every condition value appears somewhere in it, however the values are combined across rules. The number of rules listed is not part of that check.

The checksum procedure reveals that rule (member=Y, over100=N) and rule (member=N, over100=Y) produce the same 5% discount, so the two are redundant and one of them should be removed to keep the table minimal, with a single test case written for the surviving rule covering both. The remaining two rules are left untouched by the merge.

The checksum procedure applies to tables with three or more conditions, where the rule count grows beyond what can be inspected by eye, so a two-condition table such as this one is verified by inspection instead.

The minimized table still requires all 8 test cases, because merging rules with don't-care symbols changes how the table is presented: each of the four international orders still differs in weight and express selection, and each has to be executed to show that the flat rate holds for that particular combination of weight and delivery speed.

The minimized table requires a single test case, because once the four international rules have been merged the remaining rules can be read off the same merged row, and one execution of the flat-rate path demonstrates the whole table at once, so the other rules need no execution of their own once the merge has been agreed with the business.

The minimized table requires 4 test cases — one per condition plus one for the merged rule — because after minimization the test count follows the number of conditions in the table rather than the number of surviving rules, and the merged rule is counted once on top of those three. The four original international rules are no longer counted.

Source test case: request a route between address A and address B. Follow-up test case: request a route between the same two addresses a second time with identical inputs. Metamorphic relation: the two responses must be returned as character-for-character identical strings, since a feature with no reliable oracle can still be checked by confirming that repeated requests produce a stable, reproducible result for that pair of addresses on every call. A route that changes between calls is reported as a defect.

Source and follow-up test cases are not needed for an AI-based feature of this kind, because metamorphic testing is applied where a reliable oracle already exists and serves to cross-check that oracle's output against a second execution of the same function.

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 service must return the same route for both inputs, since a robust router normalises whatever it is given before the routing logic runs.

Both items are 'do-confirm' items, because a checklist records what a tester should confirm has happened rather than prescribing new work, and the currency symbol item confirms that the checkout page rendered as the designer intended rather than asking the tester to drive the page.

The currency symbol item is 'do-confirm' because it confirms the page loaded with the right locale settings, and the sign-off item is 'read-do' because the tester must read the document before deciding whether to accept it as valid evidence before the checklist item can be closed.

Neither item belongs to the 'read-do' or 'do-confirm' categories, because those two labels describe how scripted test cases are sequenced during execution rather than how checklist items are phrased.

Crowd testing should be ruled out for a commercial release of this kind, because an unreleased checkout flow would be exposed to testers outside the organisation, and that confidentiality risk outweighs the coverage benefit in the week before a major sale event that the retailer cannot reschedule. An in-house device lab, however small, keeps the feature inside the organisation until launch day.

Crowd testing can stand in for in-house testing on this release, because the crowd supplies the device, operating system and network diversity the in-house lab lacks, and the volume of reports it returns covers the checkout flow more thoroughly than a small internal team could in the single week that remains. The in-house team can then be redirected to the campaign pages that go live alongside the sale.

Crowd testing suits back-end API work rather than this checkout flow, because external testers are given programmatic access to endpoints rather than production-like accounts, and a user-facing mobile interface needs testers who already know the retailer's business rules and checkout promotions in detail. External testers recruited through a platform are rarely briefed on those rules before they start a session.

Data-based techniques are the primary match, since the claim status is itself an input value the user selects; boundary value analysis fits best, as it exercises the first and last values in the list of permitted statuses as well as a value just outside that list.

Rule-based techniques are the primary match, since each claim stage is governed by a business rule; decision table testing fits best, as it combines the status conditions into rules.

Experience-based techniques are the primary match, since unexpected navigation orders surface while exploring the application; error guessing fits this defect type best.

Test the state transitions with arbitrary balance values such as $500 and -$500, because the state machine's behaviour is determined by which side of zero the balance ends up on rather than by how close it comes to the threshold, so values well inside each state give a clearer and more readable test than values clustered around the boundary, and the transition fires on the sign of the balance rather than on its exact magnitude. Boundary values would add test cases without adding information about the two states themselves.

Test the boundary values of the balance — $0 and the amount immediately below it — as a separate boundary value analysis, and test the Normal and Overdrawn transitions on their own with convenient round figures, because each technique produces its own coverage items and merging them would leave neither criterion fully satisfied, while keeping the two sets apart shows which coverage item each case belongs to. Reporting the two criteria separately also makes it easier to show which of them has been satisfied at the end of the cycle.

Test every balance value from -$1,000,000 to $1,000,000 in $1 increments, because nesting one technique inside another means the combined criterion inherits the coverage obligations of both, and an exhaustive sweep of the numeric range is what satisfies boundary coverage at every transition in the model.

Test the decision point's three outcomes in isolation using stubbed credit-score and amount inputs, without executing a complete path through the surrounding activity diagram, because process cycle testing takes its coverage items from the decision points in the process, the connecting activities add no coverage obligations of their own, and a stubbed harness reaches the same coverage figure in far less execution time. The surrounding activities are covered incidentally whenever the decision point is reached in production.

Test one complete path through the activity diagram ending in 'auto-approve', because scenario-based testing of the most common business path is what process cycle testing calls for, and the auto-reject and manual-review outcomes are variations of the same path that this test case already traverses end to end, the credit check behaving identically on each of the three branches. Running the other two branches would repeat the same sequence of activities with a different outcome recorded at the end of it.

Test the activity diagram with state transition N-switch coverage in place of decision coverage, because the activities in the diagram behave as states and the arrows between them as transitions, so process cycle testing is satisfied once every pair of consecutive activities has been exercised, without enumerating the three outcomes separately in the test design. N-switch coverage of consecutive activity pairs subsumes the outcomes of the decision point, because each outcome is reached by one of those pairs.

Functional completeness, functional performance and functional security — describing, respectively, whether all specified functions are present, how quickly they respond under load, and how well they protect the data they handle from unauthorised access, all grouped under the functional suitability heading.

Functional correctness, functional usability and functional compatibility — describing whether results are right, whether users can operate the functions, and whether they work alongside other systems.

Functional completeness and functional correctness — the standard names just these two, because whether a function suits the user's task is assessed under usability instead of functional suitability.

Automated code-coverage analysis of the user interface layer's event handlers.

Penetration testing of the login endpoints.

Scalability and replaceability are the Test Analyst's responsibilities, since both are judged from the user's point of view, while adaptability and installability are left to the Technical Test Analyst.

All four flexibility sub-characteristics — adaptability, installability, scalability and replaceability — sit with the Test Analyst, because flexibility is a business-facing characteristic that users experience directly.

No flexibility sub-characteristic is covered at CTAL-TA level; they are addressed in the CT-PT syllabus, where environment-related behaviour is covered in depth.

Coexistence is the Test Analyst's responsibility and interoperability the Technical Test Analyst's, because sharing an environment with other software is something the user notices directly, while exchanging data between systems is a technical integration concern checked against interface specifications.

Interoperability and coexistence both fall to the Technical Test Analyst, because each is verified against interface specifications and deployment configurations rather than against the business requirements the Test Analyst works from when designing tests for the business-facing quality characteristics.

Compatibility is not addressed at the Advanced Level for either role; it is covered at Foundation Level, where the exchange of data between systems is introduced alongside the other quality characteristics of the product quality model. The Advanced Level syllabi do not revisit it for either role.

Defect detection percentage (DDP), root cause analysis (RCA), and cost of quality, in that order of increasing scope.

Phase containment effectiveness (PCE), defect removal efficiency (DRE), and test gap analysis, matched in the order given.

Cost of quality, defect removal efficiency (DRE), and phase containment effectiveness (PCE), matched to the definitions as listed.

Automated static analysis — a tool scans the source code with no human reviewer involved.

Pair programming — two developers write code together in real time.

The figures show that the payment reconciliation module is among the more reliable parts of the system, because a module accounting for 40% of reported defects is clearly being exercised heavily, and a 55% detection percentage confirms that more than half of its defects were caught before the product shipped. A module of that size would be expected to carry a share of the defect count.

The 55% defect detection percentage shows the module was adequately tested, because the figure is measured against all defects known at the time of release and a majority finding rate is the normal expectation for a module of this complexity.

The two figures describe unrelated things — one counts where defects landed, the other how many were caught — so they should be reported separately and neither should drive where the next release's test effort goes.

Root cause analysis should stop at the first 'why', so the cause to act on is that the tax rate table was not updated; the later answers describe organisational matters that fall outside a defect investigation and belong to a separate process review rather than to this corrective action. The table itself can be corrected in a single change.

The five whys produced five distinct causes, so all five should be logged as equally likely candidates and investigated in parallel, since the technique is designed to broaden the search for causes rather than narrow it to a single one that might turn out to be the wrong one to act on. Each of the five is then owned by a different part of the organisation.

The five whys technique was developed for manufacturing and hardware defects, so this software tax-calculation issue should be analysed with a Pareto chart of defect categories instead.

A 'checking' defect type, because the confirmation email is produced by a validation step that inspects the order before it is sent, and ODC assigns a defect to the type of code that was executing when the incorrect output was produced, sent to the customer and accepted by the system.

A 'timing/serialization' defect type, because the formatting function and the email dispatch run in sequence, and the fault shows itself as one step completing before the other has supplied its result to the message template that the email is built from, before the address block is rendered.

ODC classifies defects by the activity that found them and the tester who reported them, so this defect would be recorded under the test phase in which the incorrect email was observed, together with the name of the tester who raised it and the release in which it was found.

They make further test design unnecessary, because the model is itself the executable test suite.

They prevent residual defects in the delivered code.

Add testers to execute more test cases against the current test basis for the reporting module, since a declining defect detection percentage reflects how much execution effort the module receives, and restoring the earlier percentage is a matter of covering the existing test basis more thoroughly within each release window rather than changing how requirements are reviewed, the same basis having served the module across all three releases being compared. Execution effort, not the review process, is what the metric is measuring here.

Stop reporting DDP for the reporting module, since a figure falling across three consecutive releases is being distorted by the volume of escaped defects counted after release, and a metric that moves in one direction irrespective of the team's effort gives no usable signal about how well the module is tested.

Move the reporting module to the team that writes its requirements, since putting authoring, review and testing under one manager removes the hand-off that the root cause analysis identified, without needing to revisit the review process or the test basis for the module.

A defect arrival rate still rising in the final week is the expected shape of the Rayleigh curve at this point, since the curve peaks close to the release date; taken with the 30% of medium-risk requirements still untested, it shows the team is finding defects at its most productive rate and the release can proceed as planned, with the outstanding requirements scheduled for a follow-up cycle after the release. A rising rate this late is read as evidence that the test effort is finally reaching the areas that matter most.

The untested 30% of medium-risk requirements can be set aside for this release decision, since test gap analysis reports on coverage of the test basis while defect arrival analysis reports on product stability, the coverage gap is a planning input for the next release rather than evidence about the build now under consideration, and the decision should rest on the stability signal the arrival curve provides. Coverage of the test basis is reviewed separately, in the retrospective that follows the release.

The Rayleigh model describes defect discovery in large sequential projects and has little bearing on a modern release decision, so the arrival trend should be set aside and the decision taken against the planned calendar date, with the coverage gap on medium-risk requirements recorded as a known limitation in the release notes.