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

White-box testing is work for the period after the iteration, because the structure of the system is only stable once all of the stories of that iteration have been merged into a single integrated build, and only then can the paths that really exist be seen.

White-box testing sits outside the test types that the syllabus discusses for iterative delivery, so the team should agree only on when its functional, black-box and exploratory testing take place and leave structural coverage to the judgement of the individual developers.

White-box testing is purely a developer concern, so the testers only decide when black-box testing happens.

The suite should stay at its present size and merely be run less often, because the information an end-to-end run gives about the behaviour of the whole system cannot be obtained from any other source once the product is live in production.

Only the four-hour runtime is a real concern here, since high maintenance cost and poor defect localisation are properties of component-level tests rather than of end-to-end tests.

Feature toggles and A/B testing are release techniques only, so they have no bearing on how much end-to-end testing is needed.

Excessive rigidity and over-reliance on documented requirements, the drawbacks that appear once a team spreads testing responsibility across all of its members.

Delayed feedback and low cognitive engagement, because a holistic approach pushes the testing effort towards the end of the delivery cycle, where results arrive too late to act on.

A lack of focus and the need for a culture change, which describe a team that has not yet agreed how it intends to work together.

The whole-team session is the exploratory regression approach, in which the team sets its documented regression tests aside and instead relies on unscripted sessions carried out by each tester separately during the closing days of the iteration.

Tagging tests against user stories is a form of risk-based regression testing, because each tag records the impact and the likelihood of failure that the team assigned to that story.

Taken together the two practices form the DevOps-oriented regression approach, whose hallmark is a smoke test used as a quality gate.

Treat the load test as being out of the team's scope, because a test that cannot be finished inside the timebox passes to the operations group that owns the shared environment and is reported outside the iteration review entirely.

Declare the story done with no performance information at all, since non-functional testing belongs to the period after the release rather than to iterative development.

Shrink the load test until it fits the iteration and accept the reduced data set as the final result.

Centralise the testers into a separate test group that serves the five delivery teams, so that test design becomes consistent and each team is sent the specialist it happens to need for the current iteration.

Rotate every tester into a different team each iteration, because the resilience the syllabus asks for comes from people who have worked in every part of the programme.

Ask each team to document its test design decisions and have the programme office review them monthly.

Write her participation into the Definition of Done as a mandatory sign-off, so that no future story can be closed until she has repeated that kind of session on it, which turns her involvement into a scheduled obligation.

Give her a formal test case specification to execute before each release, so that her testing becomes repeatable and her results can be compared between iterations.

Thank her privately and keep her out of further test activities so that her time stays available for fundraising work.

Ask the operations group to send a weekly incident summary to the test manager, who decides which of the incidents become defect reports for the team.

Add a non-functional test phase after the iteration, run by the operations group, so that developers can concentrate on functional behaviour while the iteration lasts.

Extend the automated regression suite until it covers each failure pattern already seen in production, since repeating those checks on every build is what keeps the knowledge inside the team.

Three days before the release is a good moment for a tissue tester, because the sample-intake screen is by then complete enough to be used end to end and what he finds can still reach the release branch.

The two-hour briefing on the accreditation rules is sound preparation for the visit.

Have the two specialists write detailed handover documents for their areas and store them in the team wiki, so that anybody can take the work over during an absence without having practised it beforehand.

Make every team member responsible for every activity from the next iteration onwards, since a team of pure generalists has no bottlenecks and the two specialisms will be picked up along the way.

Recruit a second specialist for each area, treating the bottleneck as a capacity problem rather than a knowledge-sharing one.

A mind-mapping workshop, in which the whole team draws the scope of the coming release, its dependencies, its integration points and its first test ideas on one shared map, and then keeps that map visible for the rest of the release so that anyone can add a newly discovered dependency or a further test idea to it as the release work proceeds.

A release readiness assessment, in which the team checks the increment against the release-level Definition of Done, reviews the remaining open quality risks together with the results of the non-functional work, and collects the positions of the external stakeholders.

An iteration readiness check of the test environments and the test data, in which the tester confirms before the iteration begins that an environment holding representative collection-route data is available to the whole team.

Only the failed pipeline run counts as a test control trigger, because test control reacts to the results of planned test execution; the production monitoring signal and the customer messages are operational matters that the operations group handles outside the team's testing work.

Control belongs to a test manager who compares the actual testing progress with the agreed test schedule and issues corrective actions from that comparison, while the team continues undisturbed with the stories to which it committed during iteration planning and reports its status once per iteration.

The three signals should be collected and summarised at the end of the release in a test summary report, so that corrective measures are decided once the complete picture of the release is available to the stakeholders.

Requirements coverage is best expressed as the proportion of user stories that have at least one automated regression test attached to them, because an automated test is the record of a requirement that survives after the iteration has closed and the conversation is forgotten.

Infrastructure and environment coverage is adequately represented by the code coverage figure of the pipeline run, because the pipeline executes inside the same container images that are later deployed to the lending branches and therefore reflects the environments in use.

Exploratory coverage supersedes requirements coverage once charters exist.

A causal loop diagram, which shows how factors such as delivery pressure, test debt and defect density reinforce or balance one another over time, rather than where the elapsed time of a single story is spent.

Plan-Do-Check-Act, which structures the running of an improvement once it has been chosen, by planning the change, carrying it out, checking its effect against the expectation and acting on the result.

Goal-Question-Metric, which derives the metrics to be collected from a stated goal through explicit questions, so that every measurement answers a question that serves that goal.

A risk-storming session, in which the whole team identifies and prioritises the quality risks of the backlog items that it is about to take into the coming iteration, usually moderated by the tester.

An iteration readiness check, which confirms before an iteration starts that the test environments and representative test data for the stories of that iteration are available to the team.

A mind-mapping workshop, in which the team maps the scope, the dependencies and the first test ideas for the release collaboratively at the start of release planning.

Because the infrastructure is mature, extend the Quadrant 2 acceptance suite now so that every variant of the handover rules is covered and run it on each commit, so that regression for the feature is repeatable before the two planned rule changes arrive; tooling maturity is the factor that should decide the weighting here.

Because customer feedback mechanisms and production observability are strong, treat production as the primary source of test information: reduce the strategy to Quadrant 1 unit tests in the pipeline plus telemetry and A/B results, and let the member panel's complaints drive the defect backlog, since behaviour that matters becomes visible in the data within one weekly cycle and the other quadrants add cost without adding information.

Because the fleet consists of physical vehicles, weight Quadrant 4 above the other quadrants and build automated load, resilience and performance tests for the handover path as a release gate; technology-facing critique is the dominant need whatever the change frequency of the rules may be.

Because these measurements describe the testing work itself, concentrate the quarter on the testing queue: make one tester accountable for verifying all reported defects and for keeping the shared pre-production environment usable, and report that tester's verification throughput and the environment uptime as the two headline figures of each iteration, so that the cycle time and the unavailable hours acquire a single owner and improve without disturbing the flow of the development work; the other figures can then be revisited once those two have returned to their earlier levels.

Because escapes to production and restore times are operational figures, hand them to the airport operator's operations group and limit the team's own improvement work to a coverage target: raise the automated code coverage of the turnaround module by an agreed number of percentage points in each of the coming iterations, since coverage is the measure most directly under the team's control, is reported automatically by the pipeline and can be compared from iteration to iteration, and a higher figure will bring the escaping defects and the restore times down with it.

Remove the noise from the reports first: move the pipeline runs to the night hours when the baggage reconciliation interface is idle, re-run failing tests twice automatically and record a test as passed when a re-run succeeds, so that interface-related failures stop distorting the pipeline statistics.

The analytics dashboards are archived at the end of each iteration and handed to the release manager for the usage trend report, because the value of operational data for a delivery team lies in showing stakeholders how adoption of each release has developed over time.

The monitoring thresholds are tuned until the alerts stop firing in normal operation, because a quiet alerting channel is evidence that the behaviour agreed with the business is already in place.

The material is passed to the operations group, since only written user stories and their acceptance criteria can serve as a test basis for the team.

It shows that the testboard should give way to a storyboard, because only a scene-by-scene picture of the borrower's journey stays accurate across several iterations, while a board of scenarios and priorities cannot realistically be kept current at that level of detail.

It shows that the test cases derived from the board have become obsolete and should be deleted from the suite without further discussion, because a test that disagrees with the current wording of the story has lost its value as a record of what the team once agreed to build.

It proves that the queue limit was implemented incorrectly, so raising a defect report against the reservation queue is the correct next step.

The session should be repeated with the same participants until the green cards outnumber the red ones, because a story is only ready when each business rule carries at least three agreed examples and every open question has been converted into an example.

Nine red cards show that the rules are well understood but that the examples were written too late in the session, so the story can be pulled into the iteration and the missing examples completed while the work is in progress.

The red cards should be turned into defect reports so that the open points are tracked to closure.

The anchoring effect; the first figure quoted or the first happy-path story heard in refinement pulls the whole later discussion towards it, so edge cases, accessibility and internationalization end up underestimated by the group.

Conformity bias; the tester aligned her judgement with a view the rest of the team had already voiced, so the countermeasure is to collect each person's opinion before the group discusses the story at all.

A deviation produced by the whole team approach itself, which the syllabus says disappears once a separate independent test team takes over the acceptance decision for each story.

A free-form specification layer above the stories, in which every epic is restated in narrative prose by the product owner so that a reader can infer what each term means from the surrounding description of the business goal.

A state transition diagram of the appointment lifecycle, which fixes the states an appointment can occupy and the events that move it between them.

A prototype of the booking screen, so that the wording shown on the interface settles the question for everyone.

Validation, because the point of putting a prototype in front of residents and the parking office is to confirm that the requirements already recorded are correct, unambiguous, complete, consistent and testable before development starts.

Analysis, because the team is reconciling the competing needs voiced by the residents, the parking office and the accessibility representative, and is deciding which of those needs the permit service will satisfy first.

Specification, because the result of the sessions will be captured as user stories and semi-formal scenario models.

The action list agreed at the team's previous retrospective and reviewed at the next one.

A note recording which external services are stubbed in the test environment and which version of each one the team currently runs its tests against.

Slice along the layers of the solution: the first slice builds the result table and the synchronisation service, the second slice builds the countersignature service and its audit store, and the third slice puts the technician screen on top of both, so that each specialist works on the part of the stack they know best, the three pieces are joined only once at the end of the second iteration, and the technicians see the recording flow for the first time when everything is in place.

Keep the story whole and split the testing instead: one slice delivers all five criteria so the technicians get the complete behaviour at once, and a following slice adds the tests for the countersignature and the offline cases.

Deliver the two unbuilt parts first in a single slice carrying both the countersignature workflow and the offline store, with the original acceptance criteria copied into it so that nothing agreed with the laboratory is lost.

Take one slice per business rule but attach the six original acceptance criteria unchanged to every slice, so that the recruiters and the hiring manager can see at any point that the whole agreement is still in force and that nothing settled in the earlier refinement has quietly been dropped on the way.

Slice by the stages of the hiring pipeline, giving each slice the screen, the ownership check, the archiving behaviour and the notifications for the stage it covers, so that one stage is finished completely before work on the next stage begins.

Drop the story and raise three independent stories from the blue cards, since example mapping takes the place of a slicing discussion.

Mnemonics: memorable words whose letters each stand for a product dimension or a test idea, so that a tester can recall the whole list during a session without opening any document at all.

Rules of thumb: shortcuts that a tester has distilled from personal experience on this particular product and keeps as a private working note.

Analogies and metaphors: comparing the product with something familiar in order to import expectations from it.

SFDIPOT, because walking the product through structure, function, data, interfaces, platform, operations and time widens the set of dimensions being examined, which is what a tester needs when deciding where to look at a product under exploration.

TERMS, because it gathers the factors that decide whether test automation succeeds - tools and technology, execution, requirements and risks, maintenance, and security - and a regression set is where automation pays off.

I SLICED UP FUN, because it lists mobile aspects such as interruptions, ergonomics, platform and network conditions.

A tour of the tourist district is dedicated to negative testing, error guessing and fault attacks, since a visitor handles the product in ways its designers did not plan for and so reaches the places where it gives way.

A tour of the business district looks at the features that few shoppers ever reach, such as rarely opened preference screens, on the grounds that the main purchase flow is already covered by automated checks.

A tour of the hotel district visits the features that bring in the product's revenue.

The moderator writes the observations up as defect reports on behalf of the group afterwards, since the mob worked as a single tester and one consolidated record of the session is therefore enough.

The participant who held the keyboard during the final rotation summarises the findings for the rest of the team, because that driver saw the most recent state of the product.

The group turns its observations into test cases for the regression suite before leaving the room, so that the session leaves a reusable artefact behind it.

Candidate (a), because a long checklist is tiring to work through alone and a second person halves the time needed to reach the end of the steps.

Candidate (c), because two testers looking at the same screen are more likely to notice a wrong label than one tester working alone.

Candidate (d), because an overnight automated run needs a second person watching it so that any failure is diagnosed while the environment is still in the state in which it failed.

As a defined technique with prescribed steps and entry and exit criteria, so that any tester executes it the same way twice and a session counts as finished once its steps have been worked through.

As the team's substitute for exploratory testing, on the grounds that both are unscripted and both rest on the tester's judgement rather than on written test cases, so a single entry in the test approach can be made to cover both and no separate description is needed for the generated modules.

As a review activity for LLM-generated code, since the prompt and the generated source are the artefacts being judged.

A generic checklist becomes usable only once the team has rewritten it for its own product, because published lists of usability or security items were drawn from other products and carry no test ideas for a veterinary booking and records system.

A heuristic that has held on several products becomes a test technique and no longer needs an oracle.

One charter for each of the four user stories, each written as an ordered list of the steps the tester will carry out, with the expected result of every step filled in beforehand, so that another tester can repeat the session identically and the two outcomes can be compared step by step at the iteration review. The optional charter elements - actor, purpose, setup, priority, data, variations and limitations - are filled in for all four before the day starts, so that the whole day of testing is planned out in advance of it.

A single charter covering the whole epic, stating only its scope - 'the redirect feature' - and leaving the mission out, since the mission is implied by the title of the epic and the session notes will record what was examined in the end.

Two charters, for US-1 and US-3 only, because exploring a story whose acceptance criteria are still vague wastes the session; US-2 and US-4 wait until their criteria have been rewritten.

The time box should have been extended to the three hours actually needed, because a session runs until its charter has been covered and the stated 90 minutes is a planning estimate rather than a limit on the session. The tester should therefore have carried on into the afternoon until the charter was covered.

The stale data load and the missing feature switch should have been treated as the first findings of the session and raised as defects, since being unable to reach the feature is itself a result of the exploration, and the charter itself would then be rewritten once the environment had been corrected and the overnight data load refreshed.

The charter should have been dropped in favour of a scripted test procedure, because a feature needing specific data and a switch is not a candidate for exploratory testing.

Write free-form notes as the session proceeds and attach the saved timetable files to them, since those files are the evidence the developers asked for and a written note is quicker to produce than any other kind of record, and those same files can be attached to a defect report later on exactly as they stand.

Record nothing while the box is running and reconstruct the session in the post-session review, so that the tester's attention stays wholly on the product during execution.

Raise a defect report for each save attempt as it is made, so that the twenty attempts appear as separate records and the frequency of the failure can be counted from them afterwards.

Overly Long or Detailed Test Case: the case spells its navigation out at a level of detail that will break as soon as the portal's menu is rearranged, so the detail should be cut back and the case kept at the level of what the resident is trying to achieve.

Call on Me: step 3 reaches into the depot planner, which is the subject of its own test case, so this case should invoke that one at that point instead of repeating its content inside these steps, keeping the steps of each system inside the test case that owns that system.

Hotstepper: the case moves from the resident portal into the depot planner without saying how that second system is reached, so the missing navigation should be written in as steps a reader can follow through.

Invalidation Heaven: the case is weighed down with alternative outcomes for exceptional and invalid situations at the expense of the valid boarding path, so those variants should be lifted out into a separate negative test case and this one kept to the valid flow.

One More Step: the case stops before the outcome of its last action has been checked, so a closing step should be added in which the locked manifest is reopened and the passenger count compared with the number of tickets scanned, which is the closing check that the case as written leaves out of its sequence.

Hotstepper: step 3 jumps to closing the gate without the actions that take the sailing towards departure, so the intermediate steps should be written in.

Automate the check-in tests at once through the user interface, because automating a feature while it is still being written keeps the automated regression suite in step with the product and avoids a pile of automation work later on.

Automate the check-in tests only once the feature has been in production for a full quarter, because automation is a release-level activity rather than part of the iteration work.

Postpone the question until the feature is finished, because what to automate is settled outside refinement and iteration planning.

Version control of test code and environment definitions is a development concern rather than a category of test tool, so the team should judge it only by what the build pipeline needs and leave it out of its tool decisions.

The team should pick its tool categories from whatever the organisation has already licensed, so that the tooling in use stays consistent between the teams.

A category counts as a test tool category only when it produces a pass or fail verdict.