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

Static analysis and code review sessions, where the Test Analyst measures cyclomatic complexity, checks compliance with the team's secure coding guideline and signs off each merge request before it enters the main branch.

Performance and load testing, where the Test Analyst configures virtual users and analyses response-time percentiles under peak permit-renewal traffic.

Component testing and component integration testing, where individual code units and their interfaces are verified against the detailed design, the coding standards and the unit-level acceptance criteria agreed with developers.

Test execution, which runs the suites against the build, compares actual with expected results and logs each anomaly found during the run.

Test design, which turns prioritised test conditions into high-level and low-level test cases, identifies the test data each case will need and decides which cases are candidates for automation.

Test analysis, which examines the test basis for completeness and testability, derives prioritised test conditions from the pharmacy requirements and records the traceability from each condition back to its requirement.

Recalculating the project's earned value and updating the release budget forecast based on the number of test cases that passed in the current cycle and the defects still open against the release.

Profiling database query plans to identify the slowest SQL statements executed by the baggage-scan service under the regression workload.

Rewriting the build pipeline scripts so that the nightly regression suite is triggered automatically after every successful merge to the main branch and its results are posted to the team channel.

When service virtualization is not available and the payroll interfaces must be exercised end to end with real downstream banks, synthetic data is preferable.

When the test environment is shared with the operations team and must stay identical to production in structure and content, synthetic data is preferable because it can be loaded faster and refreshed without coordination.

When the team wants the test data to age realistically over time, reflect the exact volume and statistical distribution of real employee records and reproduce historical anomalies, synthetic data is preferable to a production copy.

A driver to stand in for the unavailable drug-interaction service that the module calls, and a stub to invoke the module in place of the missing scheduler.

A stub for both sides, one returning canned drug-interaction results and another one periodically invoking the module in place of the scheduler.

A mock object for the drug-interaction service and a service-virtualization layer that replaces the entire module so that the scheduler can be tested alone.

It is a domain-layer keyword that must be re-implemented for every supported browser; its benefit is that failures are reported at the level of individual clicks and field entries, which simplifies debugging for the automation engineer.

It is an atomic keyword because it maps to a single business outcome; its benefit is that it can be executed without any test interface layer.

It is a verification keyword because it ends by confirming submission; its benefit is that each check it performs is reported separately, so a failed assertion can be traced to a single step without re-running the sequence.

Completeness, because a test case with repeated assertions is likely to have left out other expected results that should have been listed.

Consistency, because the expected result is phrased in three different ways and therefore contradicts itself, leaving the executor unsure which formulation to compare against.

Feasibility, because eleven steps with repeated checks cannot be executed in the time normally allotted to a single low-level test case.

Use metamorphic testing: double every meter reading and check that the new engine's invoice amount doubles, treating any other ratio as a failure.

Use property-based testing: assert that every generated invoice amount is a positive number with two decimal places and no reading is billed twice.

Use a human oracle: ask a billing specialist to calculate a stratified sample of 40 invoices by hand and accept the engine if all 40 match.

Likelihood: severity assigned by the product owner. Impact: priority assigned by the developers, adjusted by the test manager during risk monitoring.

Likelihood: frequency of use, financial and reputational damage, legal and safety consequences. Impact: complexity of the feature, quality of the test basis, use of new technology and the experience level of the development team.

Likelihood: number of stakeholders interviewed, size of the risk workshop and the number of checklists consulted. Impact: number of items already in the risk register, the retrospective findings and the age of the oldest open risk.

History-based selection alone, running every test that has failed at least once in the past year plus every test attached to the fare-calculation and refund modules, because the defect history is the most objective data set the team has and the failing modules are known.

Coverage-based selection, running the smallest set of tests whose combined code coverage reaches the suite's total coverage figure, because it minimises execution time while preserving the coverage level that stakeholders have come to expect from the full suite.

Random selection of the tests that fit in five hours, re-drawn for each release, because it removes tester bias and eventually covers the whole suite over successive releases.

Treat R2 with the same depth as R1, designing a full decision table for every combination of logo size, paper format and printer driver and executing it in the first test cycle, because its likelihood is also rated high and cosmetic defects are visible to every pharmacist.

Defer all testing of R1 to the final acceptance week, when the dosage conversion library will be most stable and the clinical reviewers are available, so that the tests do not have to be re-run after each fix and the acceptance sign-off can rely on a single execution.

Allocate R4 the largest share of exploratory sessions because sorting defects are hard to specify in advance, exploratory testing is the technique the team enjoys most, and a visible sorting problem would be noticed by every pharmacist in the first week.

To replace the random generator with an operational profile so that the most frequently used inputs are tested proportionally more often than rare ones.

To provide a recognised coverage criterion for random testing, so that the percentage of the domain exercised can be reported to stakeholders.

To remove the requirement for an automated oracle by comparing each new random result with the result of the previous random input.

The follow-up test case re-runs the source test case unchanged on a second environment or platform, and the two outputs are compared with each other to detect environment-specific defects, replacing the need for an expected result in either environment.

The follow-up test case uses the output of the source test case as its input, forming a chain of dependent test cases in which just the final output is verified against a golden result, so that intermediate expected values do not have to be specified.

The follow-up test case is the negative counterpart of the source test case, built by invalidating one input value, and the pair is verified by checking that exactly one of the two passes and that the failing one produces a specific error message.

Defects in the requirements are prevented, because the tool rejects any model whose transitions contradict the written specification.

The generated test cases no longer need separately specified expected results, because the generation tool derives pass or fail verdicts directly from the structure and transitions of the model.

Exploratory testing becomes unnecessary once a complete model exists, since every behaviour of interest is already encoded as a generated test and covered by the tool's coverage report.

Because a taxonomy replaces the test charter in session-based testing, so exploratory sessions can be run with the taxonomy as their mission statement and debriefed by counting the categories in which defects were found.

Because a taxonomy defines the exact number of test cases required per requirement and per defect category, giving the checklist a measurable coverage criterion that can be reported alongside requirement coverage.

Because a taxonomy fixes the severity and priority of each defect type in advance, so the checklist can be executed in descending order of severity without further prioritisation and the most severe categories are exercised in every session.

ON point 37.9 °C and OFF point 38.1 °C, the two nearest values either side of the boundary, leaving 38.0 °C untested because it is ambiguous.

ON point 38.0 °C, on the boundary; OFF point 37.9 °C, one step below, because OFF points are taken on the side where the condition is false.

ON point 38.1 °C, the first value that raises the alarm; OFF point 38.0 °C, the last value that does not, because ON points must belong to the domain being tested.

Power 22.0 kW, duration 481 minutes.

Power 3.6 kW, duration 60 minutes.

Power 11.0 kW, duration 15 minutes.

SmartTV, 4K, QR code

Phone, HD, password

Browser, SD, password

48

11

12

A manual review step in which a pharmacist or clinical reviewer inspects a stratified sample of the generated files and records the expected import result for each before the run starts, so that the results can be judged against clinical expectations.

A recognised coverage criterion for random testing, agreed with the stakeholders before the run, so that the percentage of the PDF specification exercised can be reported afterwards and used as the exit criterion for the fuzzing activity.

A list of equivalence partitions for every PDF field and structure element, so that the generator draws exactly one representative from each partition per run and the resulting coverage can be reported per partition.

Static completeness checking of the matrix would have detected both defects if the matrix had been reviewed more carefully together with the data model, because the relationships between Prescriber and Prescription are visible there.

The matrix was in fact incomplete, because Delete should not have been listed for an entity that other entities reference, and the static completeness check should have flagged the missing 'archive' function that would replace it.

The findings show that CRUD testing is unsuitable for entities with relationships to other entities and should be replaced by state transition testing for this entity, with prescriber deletion modelled as a terminal state.

Scan an unpaid ticket at a closed gate; scan a paid ticket at a closed gate; drive a vehicle through the open gate; drive a vehicle through the closed gate.

Scan a paid ticket at a closed gate; drive a vehicle through the open gate; repeat the paid scan and the vehicle passage once more to confirm the cycle is stable.

Scan a paid ticket at a closed gate; drive a vehicle through the open gate; scan a ticket while the gate is open.

12

36

6

A test that stops the run after 'collect timesheets' and confirms that neither calculation has begun, verifying that the parallel gateway is reached solely with complete timesheet data and that the two branches start at the same moment.

A test that chooses the 'deductions' path at the gateway and verifies that gross pay is skipped when there are no timesheet changes for the month.

A test that runs 'calculate gross pay' and 'calculate deductions' one after the other in a single thread and checks that the payslip totals are arithmetically correct for every employee category, including those with no deductions in the month.

Adding a bag is an exception flow because it costs the passenger money and involves a payment step outside check-in; the failed passport check is an extension flow because it extends the checks performed before the boarding pass would be issued.

Both are exception flows, because each one departs from the main flow at a decision point, and every departure from the main flow is treated as an exception in use case testing so that each receives its own test case.

Both are extension flows, because in each case the passenger's action or document, rather than a system fault, causes the deviation from the main flow, and extension flows are the category used for everything the passenger can trigger during check-in.

4

8

7

A = N, B = Y, C = N (ordinary item, staff borrower, returned late)

A = Y, B = N, C = Y (reference-only item, non-staff borrower, returned in time)

No combination is missing; the checksum shows an overlap between Rule 2 and Rule 3 instead.

Removing one keyword from a query must return a result set that is strictly smaller than the original.

Misspelling one keyword must return at least as many products as the correctly spelled query, because fuzzy matching widens the search.

Doubling the page size of the result list must double the total number of matching products reported in the result-count header.

Retire the checklist for these screens and replace it with unscripted exploratory sessions of 90 minutes per screen, because the defects escaped despite a checklist being in place and experienced testers are better at finding boundary problems than lists are.

Use the taxonomy to re-prioritise the open defect backlog by category so that boundary defects are fixed first and reported to management as a separate trend line, leaving the checklist unchanged until the next annual review of test assets.

Add a single checklist item reading 'check boundaries on all inputs' so that the list stays short and easy to maintain, and rely on each tester's judgement and experience to decide what that means for a given screen and which values to try.

State transition testing, modelling each setting change as an event and covering every transition of the player's state machine with 1-switch coverage.

Decision table testing, listing business rules for when subtitles and audio tracks may be combined with each quality level and covering each rule once.

Use case testing, covering the main flow and each extension flow of the 'watch a video' use case with realistic personas.

The coverage report was misread: the model was covered completely according to the tool, but the generated tests were executed partially in the pipeline because of a time-out, and the missing tests happened to include the temporary-permit path, so the pipeline configuration is the root cause.

Model-based tools cannot represent conditional transitions such as permit types with guard conditions, so eligibility rules of this kind should be tested with hand-written decision tables instead, and the model should be limited to the navigation flow of the application where it adds value.

The tool generated too many tests for the pipeline to run in the available window, so the suite was pruned by a script that removed tests with similar names, and the test for temporary permits was among those removed without anyone reviewing the list.

The set should be replaced by pairwise testing over the three conditions, which covers all value pairs in four tests and is therefore more efficient than eight rule-based tests, leaving time to add a fourth condition for the driver's licence age that the business has been requesting.

The set is excessive: the table should be minimised using don't-care entries first, which would reduce the eight tests to about four while keeping every distinct premium outcome, and the freed effort should be spent on exploratory testing of the quotation screens, where usability defects are more likely.

The set is adequate: every rule of the full table is exercised once with representative values, which is the coverage criterion the syllabus defines for decision table testing, and the passing results demonstrate that the combination logic and the premium amounts are correct, so no further tests are needed.

Exhaustive testing of every combination of tariff plan, meter type, region and calendar date across a full year, so that both defect groups are covered by a single technique and the coverage figure can be reported as 100% to the regulator.

Scenario-based testing of one realistic year of consumption for a typical household, covering all four season changes and the daylight-saving switch in a single end-to-end scenario that is replayed against each release candidate.

State transition testing of the meter lifecycle (installed, active, replaced, decommissioned) with round-trip coverage, because tariff changes are state changes of the meter and each season switch can be modelled as an event that moves the meter to a new billing state.

Functional appropriateness, because rounding to the hour does not facilitate the user's task of paying accurate overtime and a different function should have been chosen.

Functional completeness, because a rounding-to-the-minute function is missing from the set of implemented functions and the requirement is therefore not fully covered.

Interaction capability, because the user cannot see the rounding rule on screen and therefore cannot recognise the wrong amount.

WCAG conformance is a requirement for public-sector websites alone; commercial products need accessibility testing when users with disabilities request it or when a contract names a specific conformance level.

Accessibility testing is complete when an automated scanner reports no violations against the chosen WCAG level, because the success criteria are written to be machine-checkable and manual review adds cost without adding coverage.

Accessibility is a sub-characteristic of compatibility in ISO/IEC 25010, so it is tested by the Technical Test Analyst together with interoperability and coexistence, and the Test Analyst contributes personas for the assistive-technology users involved.

An interoperability review, in which specialists check that the calculator exchanges pension data correctly with the employer's systems.

A usability questionnaire such as SUMI, which measures perceived satisfaction after the users have completed their tasks.

A usability test session, in which representative users perform realistic tasks based on personas while their behaviour is observed.

Both concerns are portability topics handled by the Technical Test Analyst, since they involve infrastructure and configuration rather than business functions that the school staff would recognise.

On-premises installation is installability, a Test Analyst topic; moving between database products is replaceability, a Technical Test Analyst topic, because it concerns swapping one infrastructure component for another.

On-premises installation is coexistence, and moving between databases is interoperability; both belong to compatibility rather than flexibility.

Preventing the introduction of defects, because the changed coding guideline stops developers from writing the defect in the first place, and the syllabus classifies any practice that changes how code is written as introduction prevention.

Preventing defects through modelling, because the analysis produces a cause-effect model that is later reused for model-based testing.

Preventing defects from leaking to later phases, because analysing escaped defects improves phase containment effectiveness by showing which phase should have caught each defect and strengthening that phase's checks.

Structural coverage analysis is a Test Analyst technique for measuring how many requirements have at least one associated test case, and it is reported alongside defect density per requirement.

Defect detection percentage is calculated as the number of defects found by testing divided by the number of test cases executed, so that a higher DDP indicates more effective test cases.

The defect arrival pattern should be flat throughout the test phase in a healthy project, and any peak indicates a defective build.

Scenario-based reviewing, in which reviewers walk through expected usage scenarios written in advance by the author of the requirements.

Checklist-based reviewing, in which each reviewer answers a fixed list of questions about completeness, consistency and testability.

Role-based reviewing, in which reviewers read the document from the standpoint of an end user, an operator or a maintainer without producing any artefact.

90%: 171 of 190 total defects were removed before release, which proves that the 19 production defects were introduced by post-release configuration changes rather than missed in testing.

89%: 171 of 190 total defects were removed before release, and the figure shows testing was adequate because it exceeds the 85% industry threshold.

11%: 19 escaped defects divided by 171 removed defects, which is the proportion of effort that should be moved from testing to production monitoring.

Begin with 'UI layout' defects because they are the easiest to fix and produce quick visible wins, and postpone the requirements category until the tariff team is less busy and can attend the root cause workshops.

Treat 'third-party API changes' as the priority, because external causes are outside the team's control and therefore carry the highest risk of recurrence.

Distribute prevention effort evenly across all five categories so that no cause is neglected, the distribution becomes flat over time and the team avoids the perception that some stakeholders' defects matter less than others.

The 43 failures caused by environment and data should be reclassified as passed, because the product code did not cause them and the tests would have passed otherwise.

All 88 failures should be logged as defects so that the defect density metric stays comparable with previous cycles and the trend chart is not distorted, with the environment and data issues closed later by the developers as 'not a defect'.

The cycle should be reported as 45 product defects plus 43 environment defects, since an expired certificate and changed data are defects in the test environment component and belong in the same tracker with a different component label.

Add an exploratory testing session focused on dates before every release, staffed by the two most experienced testers and using a charter that names month ends and leap days, relying on tester experience to find the next month-end problem before customers do.

Raise the severity of all date-related defects to 'critical' and add a dedicated 'date handling' label in the defect tracker, so that they are fixed within one day of being reported, escalated to the release manager and cannot reach the next release without a sign-off.

Assign each of the three components to a different senior developer who is instructed to review the date code carefully during the next sprint, document the edge cases found and report back at the sprint review.

Reclassify the video-service failures as Supportability defects, because they originate outside the application and are handled by the vendor's support contract, so that the Reliability trend returns to its earlier level and the reporting to management reflects internal quality alone.

Replace FURPS with Orthogonal Defect Classification for the next quarter, because FURPS cannot distinguish external from internal causes of reliability defects and ODC's trigger and type attributes would let the team separate vendor failures from application logic before deciding on measures.

Reduce functional testing effort by a third, since Functionality defects have not increased over three quarters and the functional regression suite is stable, and use the freed time for a general regression pass across all categories and an extra round of usability sessions.