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

The entry criteria and exit criteria for system testing, the agreed definition of done for each user story in the release, and the escalation path to follow when the agreed exit criteria are not met on the planned date.

The risk levels assigned to each berth allocation feature, with the depth of testing agreed for each level and the residual risk that the stakeholders have accepted for the release.

The defect report template and the states a defect passes through, so that anomalies found while exercising the berth allocation flows are reported consistently by every tester on the project.

A code coverage tool, which instruments the application so that the proportion of statements and branches exercised by the existing suite can be reported release by release.

A load generation tool, which replays recorded case searches at increasing concurrency so that the response time of the search service under realistic load can be observed.

A static analysis tool, which parses the source of the case management modules and reports coding standard violations and suspicious constructs before the build is handed over for testing.

The organizational test strategy, which states how testing is approached across all projects in the organization and is maintained independently of any single release.

The project test plan, which fixes the schedule, the staffing and the entry and exit criteria for each test level in the release.

The test policy, which records the organization's objectives for testing and the principles that every project is expected to follow when planning its test effort.

Test design techniques must be replaced by techniques the standard names explicitly, because experience-based testing is not accepted as evidence of coverage by a certification authority.

The Test Analyst takes responsibility for signing off the certification package on behalf of the project, confirming to the authority that the maintenance records system is fit for operational use.

Exit criteria for system testing are set by the Test Analyst instead of the test manager, so that the evidence the standard requires is complete before the release is handed over for audit.

A pseudo-oracle, because a second implementation of the cloud-mask algorithm is being run over the same input scene and the two sets of results are compared against each other.

A human oracle, because an analyst with domain knowledge is inspecting each produced mask and deciding from experience whether the result is plausible for the scene that was processed.

A metamorphic relation, because the scene is transformed before a second run and the two outputs are then required to stand in a defined relationship to one another.

Once service virtualization is in place, integration testing against the real partner billing service can be dropped from the release scope, because the simulated responses were derived from the partner's own interface specification.

Generating synthetic subscriber records removes the obligation to pseudonymize the production extract that is still loaded alongside them for the regression suite, because the synthetic records dominate the data set by volume.

Personas replace the subscriber test data set, since a described user profile carries enough detail for provisioning rules on tariff, contract length and device eligibility to be exercised end to end.

Correctness, because the expected result stated for the test case does not follow from the irrigation rules written down in the requirements specification for valve bank C.

Conciseness, because the test case repeats information about moisture level and field size that is already recorded in the irrigation requirements and in the test data specification for the plot.

Traceability, because the test case does not identify which requirement or test condition it was derived from and therefore cannot be linked back to the test basis during impact analysis.

Low-level cases throughout, because a team without recruitment domain knowledge needs the exact input values and expected results written out for every case it executes, including the screen flows that are redesigned each sprint.

High-level cases throughout, because keeping every case abstract minimises the rework caused by the sprint redesigns and lets the contracted team choose whatever concrete values it finds convenient at execution time.

Low-level cases for the screen flows, because the redesigns change concrete controls, and high-level cases for the eligibility rules, because rules can be expressed abstractly and interpreted by the tester during execution.

By the severity scale used in the defect management tool, so that each identified risk can later be matched directly against the defects that are reported during execution of the scheduling tests.

By the IEEE 1044 defect classification, because it offers an agreed vocabulary that keeps the risk register consistent with the way anomalies are classified later in the lifecycle of the scheduling system.

By the organizational unit that owns each affected component, so that every risk in the register has a named team accountable for the mitigation measures agreed with the stakeholders.

Development (1), because two high-risk bidding defects were found and fixed within the iteration and no further defects appeared in the same area afterwards.

Development (4), because the seller profile page was rewritten during the iteration even though the rewrite left the observable behaviour of the page exactly as it was before.

The televised campaign is a project risk rather than a product risk, so it belongs in the test manager's plan and leaves the Test Analyst's allocation of the remaining test effort unchanged.

Coverage-based selection alone is the strongest option, because the proportion of code exercised is the one figure that can be reported objectively to stakeholders when no requirements traceability matrix is available for the portal.

History-based selection alone is the strongest option, because past defect density is the most reliable single predictor of where the next regression failures in the listing portal will be found by the team.

Operational-profile selection alone is the strongest option, because exercising the flows that real users run most often keeps the residual risk to the business lower than any other way of choosing a regression subset.

A coverage criterion stronger than N-switch coverage, because nesting defines a hierarchy of transitions and the chart can therefore be exercised level by level rather than transition by transition.

Guard conditions become available on transitions, so that a transition can be made to fire only when a stated condition over the system variables holds at the moment the event arrives.

Concrete test data for each transition is derived automatically, because the hierarchy records which values of the system variables cause the chart to move between the nested states.

A decision node splits the flow into concurrent paths that all continue in parallel, while a fork node selects exactly one outgoing path according to the guard conditions written on its outgoing edges.

A decision node separates the actions performed by different actors, while a fork node marks the point at which responsibility for the remaining activity passes from one actor to the next one in the process.

A decision node has exactly two outgoing flows representing a true and a false branch, while a fork node may have any number of outgoing flows, which is the only difference between the two notations.

Swim lanes in an activity diagram mark the parts of the process that run concurrently, so each lane corresponds to one thread of execution that a scenario test has to exercise in parallel with the others.

A BPMN gateway can express at most two alternative outgoing paths, so any business process with three or more mutually exclusive outcomes must be modelled as a decision table before scenario tests can be derived from it.

An activity diagram carries the concrete input values for each action, so a path through the diagram can be executed as a test case without any further test data design being needed by the analyst.

It supplies the expected result for each generated input, because the profile records the outcome that production users saw for each kind of transaction over the measured period.

It gives random testing a recognised coverage criterion, since the percentage of the profile exercised can be reported in the same way as a structural coverage figure.

It ensures that rare transactions are exercised as thoroughly as common ones, because the generator compensates for low frequency by extending the run until every profile entry has been covered.

Four points: the ON points 1 and 500 on the two closed borders and the OFF points 0 and 501 just outside them, which is all that either of the two domain coverage criteria requires for a single variable.

Two points: the ON points 1 and 500, because reliable domain coverage concentrates on the borders themselves and treats the interior and the far exterior of the domain as already covered by other techniques.

Eight points: an ON, OFF, IN and OUT point for each of the two borders separately, because reliable domain coverage repeats the full set of four point types at the lower border and again at the upper border.

Eighteen, because a constraint in a classification tree records a business rule that must itself be tested, and therefore keeps all of the combinations in the combination table rather than removing any of them.

Fifteen, because the constraint removes the three combinations in which the source language and the target language are the same, one for each of the three languages in the tree.

Six, because applying pairwise coverage to the tree after the constraint has been evaluated leaves six combinations, and a classification tree is reduced to its pairwise subset before counting.

The setpoint 92, because it lies next to the already-executed 95 and repeating a test in a region where a value has already been run concentrates the effort where failures are known to cluster.

The setpoint 15, because it falls between the two executed values 10 and 20 and filling the gaps between previous inputs in ascending order is how an even spread over the domain is built up.

The setpoint 25, because it sits at the midpoint of the densest cluster of executed values and the technique prioritises the region where most previous test inputs were drawn from.

Approximately 67 transactions of each kind, because an even split gives every user action the same statistical confidence from the randomly generated sample that is executed against the auction site.

20 bids, 40 watch-list additions and 140 seller questions, inverting the measured frequencies so that the least exercised of the three actions receives much the largest share of the randomly generated transaction budget.

140 bids, 40 watch-list additions and 20 seller questions, after which the seller question path needs no further test design because its share of the profile has already been exercised proportionally.

Deleting a Customer who still has an active Booking will be rejected by the system, since the matrix shows that Booking is read by functions outside the module in which Customer records are maintained.

The implementation matches the matrix for the Vehicle entity, because the matrix was derived from the same functional specification that the developers worked from when the fleet module was built.

CRUD coverage for the three entities has been achieved, because every one of them appears in the matrix with at least one create operation and at least one read operation recorded against a function.

Six, counting the cancel transition only once because it is drawn once on the boundary of the composite state Running rather than separately from each of the three substates inside it.

Four, because 0-switch coverage exercises each state of the machine once and the chart has the four distinct top-level states Idle, Running, Done and the initial entry point into Running.

Sixteen, because every valid transition has to be paired with an attempt at the corresponding invalid transition from the same state in order to satisfy the 0-switch criterion for the whole chart.

Open to Under Review to Closed only, because reaching the Closed state from the initial state is the longest path through the workflow and therefore subsumes the shorter loops inside it.

Each transition in the machine executed once in any order, because round-trip coverage is satisfied as soon as every transition has appeared at least once in some executed test case.

Under Review to Awaiting Info back to Under Review only, because it is the sole loop in the workflow and the reopening transition from Closed simply restarts the case rather than closing a cycle.

A test that runs the Inspector approval and the Registrar issuance at the same moment, since actions drawn in separate swim lanes are performed concurrently and must therefore be exercised in parallel to reveal timing defects.

A test that measures how long the Inspector lane takes to complete under a realistic caseload, because the lane with the most actions in the diagram is the one most likely to become the bottleneck of the permit process.

A test in which the Registrar issues the permit directly from the Applicant lane without the Inspector acting, because every pair of swim lanes in the diagram has to be exercised as a direct interaction at least once.

The Antenna accepting a downlink frequency outside the band it supports, which would be found by applying domain testing to the frequency parameter carried on the Acquire message sent by the Scheduler.

The Scheduler choosing the wrong antenna when several are free, which depends on the allocation rules in the specification and would be covered by building a decision table over those rules.

The ground station failing to recover after the link drops mid-pass, which is a reliability concern exercised by interrupting the stream and observing whether the session is re-established within the agreed window.

Two condition combinations are missing from the table, because the shortfall between the five written rules and the eight possible combinations is what the checksum procedure reports as the gap to be filled by the analyst.

The table has been correctly minimised using don't-care entries, because merging rules with don't-cares is exactly what raises the sum of the rule weights above the number of distinct condition combinations in the table.

Two of the five rules are infeasible and should be struck out, since a checksum above the number of combinations is how the procedure marks rules whose condition values cannot occur together in practice.

A scripted test case with concrete inputs and expected results for every observation made during the session, so that any behaviour seen while exploring can be re-executed later by a different tester without further analysis.

The percentage of the requirements specification covered by the session, calculated from the traceability matrix so that exploratory effort can be reported in the same units as the scripted regression suite.

A risk score for each defect found during the session, agreed with the product owner before the session is closed, so that the manager can rank the findings across all the sessions run during the iteration.

Continue unchanged, because generation from a model produces systematic coverage and that benefit outweighs any amount of effort spent on keeping the model current with the weekly rule changes.

Abandon generation and return to manual design, because a model that has to be reworked every week has been shown to be the wrong basis for designing tests for a rules engine of this kind.

Keep generating but stop reviewing the regenerated suite, because the generator applies the same coverage criterion every time and so cannot introduce a defect into the cases that it produces from the model.

Sixteen sequences have to be exercised, because 1-switch coverage requires every one of the four transitions to be followed by every one of the four transitions in the machine, including itself.

Achieving 0-switch coverage on this machine also achieves 1-switch coverage, because each of the four transitions takes part in exactly one pair and so is covered as soon as the transition itself has been executed.

Attempting the invalid sequence Completed followed by Scheduled is required, because 1-switch coverage is defined over all ordered pairs of states and therefore includes the pairs for which no transition is specified.

25 hectares, because it is the value furthest from either end of the permitted range and the OUT point is defined as the value that lies outside the region where boundary defects are expected to cluster.

51 hectares, because it is the first value that the permit system has to reject and the OUT point is by definition the smallest value lying outside the boundary of the domain under test.

50 hectares, because the border value itself is the one most likely to be handled incorrectly and the OUT point is the name given to the value that sits exactly on a closed border.

Both gateways need one test per outgoing path, because in BPMN every gateway hands control to a single outgoing sequence flow and the inclusive gateway merely relaxes the order in which those flows are evaluated.

The exclusive gateway needs tests for every combination of its two outgoing paths, while the inclusive gateway needs only one test per path because its outputs are produced independently of one another at run time.

Neither gateway affects scenario test design, because gateway semantics are an implementation concern for the process engine and the Test Analyst derives scenarios from the use case descriptions instead of from the BPMN model.

Base case Collectibles, 10 days, reserve set, international, giving 7 test cases, because taking the least frequent value of each parameter as the base concentrates the single-change variations on the paths users exercise least often.

Base case Electronics, 7 days, no reserve, domestic, giving 36 test cases, because every value of every parameter has to be combined with every value of all the other parameters once the base case has been fixed.

Base case Electronics, 7 days, no reserve, domestic, giving 4 test cases, one for each parameter in the classification, since a single substituted variation per parameter is enough to satisfy the criterion.

Have a domain expert inspect the parsed output of each generated file and decide from experience whether the station has interpreted the malformed telemetry sensibly in that particular case.

Compare the parsed output of each generated file with the parsed output of the previous one, and report a failure whenever the two results differ by more than a configured tolerance for the measured values.

Accept the run as passed for every file that produced no entry in the station's error log, on the grounds that the parser writes a log entry whenever it encounters input it cannot interpret correctly.

Reliable domain coverage is achieved but 1-switch coverage is not, because 2.00, 1.99 and 5.00 supply the ON, OFF and IN points that the reliable criterion asks for on a closed lower border.

1-switch coverage is achieved but reliable domain coverage is not, because running Occupied to Released and then Released to Empty forms a consecutive pair and no further transitions exist in the dock model.

Both are achieved, because the three balances cover the border of the balance domain from both sides and the two transitions cover the dock cycle from the moment of release to the moment the dock becomes free.

Interaction capability, because the reviewers formed a judgement about the submission process while operating it and any evaluation gathered during operation falls under that characteristic of the product quality model.

Functional appropriateness, because a submission process whose value the reviewers doubt cannot be facilitating their task, and appropriateness is the sub-characteristic concerned with task support in the functional group.

Accessibility, because reviewers who are uncertain about the value of the process have in effect been excluded from using the system fully, and accessibility covers the widest possible range of people being able to use a product.

Using well-researched personas lets the session run without recruiting real participants, because the described behaviour of each persona can be walked through by the Test Analyst against the catalogue instead.

A session built on personas yields a defect count comparable with the one produced by functional system testing, since every difficulty a participant meets is recorded as a defect against the catalogue requirements.

Including a persona with a visual impairment covers the accessibility requirements for the catalogue, so a separate evaluation against the WCAG success criteria is no longer needed before the catalogue is released.

A is adaptability and B is installability, because the folder relocation is a variation in the environment that the product must adapt to, while the printer configuration is settled as part of the installation routine.

Both are replaceability findings, because in each case a component of the shop environment has been exchanged for a different one and the terminal application has to go on working with the replacement.

Both are coexistence findings, because the terminal application has to share the shop hardware with the other software and peripherals already installed on it without interfering with any of them.

Functional correctness, because a dashboard that omits one of the four specified reports cannot be producing the correct results for the greenhouse as a whole, however accurate the three delivered reports are.

Functional appropriateness, because the growers cannot complete their planning task without a yield forecast and appropriateness is the sub-characteristic that asks whether the functions facilitate the user's task.

Interaction capability, because the growers have no way of reaching the forecast information through the dashboard interface and therefore cannot operate the product to achieve the goal they came to it with.

Checklist-based review, because working through an agreed list of defect types is the most efficient way of covering a document whose structure has not yet settled and whose sections are still being added to.

Scenario-based review, because walking a draft against the scenarios the system is expected to support keeps even an unfinished document anchored to the behaviour that the stakeholders have actually asked for.

Perspective-based reading, because assigning each reviewer a stakeholder viewpoint spreads the attention across the draft and is therefore the technique that finds the most defects in a document of any maturity.

Opportunity cost, which measures the value of the features that were not built because the available development capacity was spent on testing and on fixing the defects that testing reported.

Capital expenditure on the test environment, covering the servers, network equipment and licences that the organization has to buy before any testing of the product can begin at all.

Tool licence costs, counted separately from the other categories because a test management or automation licence is renewed annually whether or not any defects are found during the period it covers.

25%, taking the 6 defects that escaped the requirements phase as a share of the 24 defects traced back to it, which is the figure that reports how much of the phase's defect content leaked onwards.

33%, dividing the 6 escaped defects by the 18 that the reviews caught, which expresses how many defects slip through for every three the reviews in the phase manage to contain.

90%, which is the defect removal efficiency of the project rather than the phase, since defect removal efficiency is the metric that counts the defects found before release against all the defects known.

Defect cluster analysis, grouping the reported incidents by module in order to show that the royalty calculation component carries a higher defect density than the rest of the platform and should receive more test effort.

Defect detection percentage, calculated for the release in order to establish what share of the defects now known to exist in the platform was actually found by the team before the royalty changes were released.

Defect arrival pattern analysis, plotting the incidents over the weeks since release to judge whether the arrival curve has peaked and the platform is approaching the stable part of the Rayleigh distribution.

That the testing has been highly effective and the phase can close, because a rising number of defects found each week is direct evidence that the team is finding more of the content of the release as it goes on.

That the test cases have begun to overlap, because the steady weekly increase in defects reported is what the Rayleigh model predicts when the same behaviour is being exercised repeatedly by different test procedures.

That the defect arrival data cannot be interpreted at all until the release has been in production for a comparable number of weeks, because the model requires post-release arrivals to anchor the shape of the distribution.

Introduce a checklist-based review of every design document so that defects which did find their way into the design are reported while the design phase is still open and before coding starts.

Run root cause analysis on the five most severe field defects of the release and classify the results against a defect taxonomy so that the pattern behind them can be addressed in the next release cycle.

Add an exploratory testing session for each new tariff feature before the release is handed over, so that defects not covered by the scripted suite are found while there is still time to fix them.

Extend the regression suite with pairwise combinations of the excise duty configuration parameters, so that the rare configurations behind the reported field defects are exercised during every release of the distribution platform.

Add production monitoring that raises an alert whenever a duty calculation is performed for one of the rare configurations, so that incorrect results are noticed within hours instead of at the end of the reporting quarter.

Reclassify the field defects against IEEE 1044 as well as ODC, so that two independent classification schemes agree on the nature of the excise duty findings before any improvement action is selected by the team.

Decline the move, because design phase containment effectiveness of 90% is the strongest figure the product has and reducing the reviewer count there would put the one phase that is demonstrably working under avoidable risk.

Recommend the move on the strength of the 55% figure alone, since the phase with the lowest containment effectiveness is where additional appraisal effort returns the most value to the organization.

Reply that phase containment effectiveness cannot support a staffing decision, because it counts defects rather than the effort spent finding them and the two phases may differ in the number of work products reviewed.