ISTQB Advanced (CTAL-AT v2.0) Mock Exam #2 — Questions & Answers
Every question in this mock exam, with the correct answer marked and a written rationale behind each option below — for reading and review, not a timed run.
Chapter 1 · Test Strategy and Test Approach Challenges — 5 questions
A telemedicine team delivers video consultations in two-week iterations and wants to cover five test types: functional, non-functional, white-box, black-box and exploratory. How do these relate to testing during an iteration and after it?
All five types can appear both during and after an iteration; the team records the feasible depth in its Definition of Done and test approach.
Correct. It is a scope and depth decision per test type, fixed in the Definition of Done and the test approach.
White-box testing belongs after the iteration, because meaningful code coverage figures can be produced once the whole increment has been integrated into the release branch and the build has stabilised.
Incorrect. White-box testing sits closest to the code and is normally performed inside the iteration, story by story, as the code is written.
Inside the iteration only functional testing of the current stories fits, so the other four types are post-iteration work.
Incorrect. Non-functional, white-box and exploratory testing are all routinely performed within the iteration.
Exploratory testing follows the iteration, since a charter can be written once acceptance criteria are closed.
Incorrect. Charters are derived from stories and risks, so exploratory work starts inside the iteration.
All five types can be performed both during and after an iteration; only scope and depth differ. The team fixes that split in its Definition of Done and test approach.
On a fleet tracking platform the route optimisation module is built by an external subcontractor and reached through its API. When should the team perform end-to-end testing of the journeys that cross that integration?
On the high-risk journeys crossing the subcontractor integration, scheduled nearer the release, with the extent decided by risk, feedback time and CI/CD pipeline maturity.
Correct. These are the three factors the syllabus gives for deciding how much end-to-end testing to include.
On every commit across the full suite, because running the slowest journey tests most often is what keeps the subcontractor integration honest and pinpoints the broken layer fastest.
Incorrect. End-to-end tests are slow and diagnose poorly, so running them on every commit buys little and delays feedback rather than sharpening it.
Not at all once consumer-driven contract tests exist for the subcontractor API, because verifying the request and response contract on both sides already covers the risk that this integration carries.
Incorrect. Contract testing reduces how many end-to-end tests are needed, but it does not exercise complete user journeys across the platform.
Only in a hardening iteration, which exists so that integration testing the iterations cannot fit is absorbed there.
Incorrect. A recurring need for hardening iterations signals insufficient attention to quality during iterations.
End-to-end testing is expensive to maintain, slow to run and weak at diagnosis, so it is concentrated on high-risk journeys, typically closer to release, and its extent is decided by risk, required feedback time and the maturity of the CI/CD pipeline.
A logistics team follows a heavily documented test approach because part of the fleet software is delivered by a subcontractor under contract. It now wants to add holistic testing. Which drawbacks of formal testing does holistic testing help to address? (Choose two.)
Missing the unexpected, because attention stays on documented behaviour and problems outside it are not examined.
Correct. This is one of the listed problems of formal testing that holistic testing counters.
Delayed feedback, because testing waits for approved documents before it can start.
Correct. Holistic testing aims at continuous testing and early feedback instead.
Weak traceability between test cases and the contractual requirements.
Incorrect. Traceability is a benefit of formal testing, not a drawback.
Insufficient conformance evidence for an external audit of the parts built by the subcontractor.
Incorrect. Conformance evidence is a benefit of formal testing.
Difficulty in measuring what has been tested, since the coverage of a session is not expressed as documented artefacts.
Incorrect. Being difficult to measure is a drawback of holistic testing itself.
Formal testing brings traceability, alignment, verification, conformance, repeatability and automation, but suffers from rigidity, over-reliance on documented requirements, missing the unexpected, delayed feedback and low cognitive engagement. Holistic testing answers the last group; its own weaknesses include being hard to measure and highly context-dependent.
A MOOC platform team reworks course catalogue search and discusses regression test approaches. Which description matches a DevOps-oriented regression test approach?
A small smoke suite acts as a quality gate in the pipeline, while feature toggles, canary releases and production observability carry part of the regression signal.
Correct. This is the DevOps-oriented approach as described in the syllabus.
The regression set grows iteration by iteration as newly automated checks for completed stories are appended to it, and the pipeline runs that entire accumulated set before every deployment to production.
Incorrect. Growing and re-running the full accumulated set describes the incremental regression approach, not the DevOps-oriented one, which keeps the pipeline gate small.
A bug bash and a whole-team walkthrough are held before the release to re-examine what changed.
Incorrect. That describes the collaborative regression approach.
Testers use heuristics about recent, core and risky areas to decide what to re-check without a predefined suite.
Incorrect. That describes the exploratory regression approach.
The DevOps-oriented approach relies on a small smoke suite as a quality gate in the pipeline, plus feature toggles, canary releases and production observability. The other options describe the incremental, collaborative and exploratory regression approaches.
The release plan of an insurance claims mobile app schedules a hardening iteration before every quarterly release. Which statement about hardening iterations is correct?
It is an iteration dedicated to stabilising the product before release, and a recurring need for one may signal that quality received too little attention during the regular iterations.
Correct. This matches the definition and the caveat printed alongside it.
It is an iteration in which the whole team runs a time-boxed bug bash on the claims flow instead of accepting new stories, so that the defects found there are fixed before the quarterly release goes out.
Incorrect. A bug bash is an activity belonging to the collaborative regression approach, not the definition of a hardening iteration.
It is the iteration in which feature toggles are stripped from the code so that the release build carries only production paths, which is what makes that build stable enough to ship to customers.
Incorrect. Removing toggles is refactoring work; the iteration is defined by stabilising the product, not by which delivery mechanisms are cleaned out of the build.
It is the period after the release in which the team monitors production and fixes escaped defects.
Incorrect. That is post-release monitoring and support, which happens after delivery.
A hardening iteration is a dedicated iteration used to stabilise the product before release; the syllabus notes that a recurring need for one may indicate that quality received insufficient attention during the regular iterations. A bug bash is a separate concept, and feature toggles are a delivery mechanism, not the purpose of the iteration.
Chapter 2 · People and Teams — 5 questions
A telemedicine team debates whether its two testers should broaden into other activities or stay narrow. Which statement best compares generalisation and specialisation within an Agile team?
Generalisation supports a sustainable pace and reduces bottlenecks, while depth is kept for areas such as test techniques, exploratory testing, automation and usability; the balance follows the context.
Correct. This is the T-shaped, generalising specialist profile the syllabus describes.
In a regulated telemedicine product the team is better off moving to complete generalisation, so that any member can produce the regulatory acceptance evidence when the assigned specialist is unavailable during a release window.
Incorrect. A regulated domain is where the syllabus expects more specialisation to be retained, not less.
Specialists are better held in a pool outside the team and lent to iterations on request, which keeps deep skills available.
Incorrect. That rebuilds the silos the whole team approach is meant to break down.
Generalisation means that each team member performs every activity about equally often, and it is that even distribution of effort across analysis, automation and exploratory work which makes the profile T-shaped.
Incorrect. A T-shaped profile combines broad capability with one area of genuine depth, not an even spread of effort across activities.
The Agile tester is described as a generalising, T-shaped specialist. Generalisation supports a sustainable pace, removes bottlenecks and spreads ownership, while specialisation remains valuable for test techniques, exploratory testing, test automation and usability testing. The balance is context-dependent, so a regulated domain keeps more depth.
On a MOOC platform the two business representatives, a curriculum lead and a learner support manager, avoid test activities. Which approach best motivates them to take part?
Involve them early in acceptance criteria and example-based sessions, make quality visible through coverage and defect trends, and link testing to business measures such as course completion and support load.
Correct. Early collaboration, visibility and business-relevant measures are the motivators the syllabus lists.
Assign each of them a fixed number of regression test cases per iteration and report their execution rate at the iteration review, so that their personal contribution to the testing effort becomes visible to the rest of the team.
Incorrect. Using them as extra execution capacity wastes their domain knowledge and reduces rather than builds their engagement.
Ask them to review the automated test scripts of the catalogue service so they can confirm the assertions match the business rules.
Incorrect. Script review demands technical skill; examples and acceptance criteria are the right medium for them.
Schedule their involvement at the end of the iteration when the increment is stable, so their time is not spent on unfinished functionality.
Incorrect. Late involvement removes the defect prevention benefit that motivates them.
Business representatives are drawn in by early involvement in acceptance criteria and example-based collaboration such as ATDD, BDD and specification by example, by visible quality information, and by linking testing to business metrics such as course completion and support load. Handing them regression execution or script reviews misuses their expertise.
A telemedicine team is composed of developers, a tester, a business analyst, a clinical domain expert and an operations engineer. Which of these are ways the whole team approach assists the developers? (Choose three.)
The tester coaches developers on component and component integration testing, which makes refactoring safer.
Correct. Coaching on the lower test levels is one of the listed forms of support.
Concrete examples agreed with the clinical expert replace ambiguous specification text, giving developers earlier feedback.
Correct. Examples instead of prose specifications are named as developer support.
The tester joins code reviews and developers join exploratory sessions, so product knowledge travels in both directions.
Correct. This two-way participation is explicitly described.
A separate test group signs off the increment against the clinical acceptance criteria, so developers do not have to interpret quality data themselves.
Incorrect. Quality is a whole-team responsibility and sign-off cannot be delegated to a group outside the team.
Developers hand their component tests over to the tester, who then owns all test levels below the API.
Incorrect. Developers keep ownership of component tests; the tester coaches rather than takes over.
The whole team approach helps developers through coaching on component and component integration testing, concrete examples replacing ambiguous specification text, and two-way participation such as testers in code reviews and developers in exploratory sessions. Handing quality decisions to a separate team or moving component test ownership away from developers works against it.
An insurance claims app team wants to use tissue testers on the redesigned claim submission flow. How should they be used?
Bring them in early while designs and prototypes are still cheap to change, explain little, and do not reuse the same person once they have seen the design.
Correct. Early use, minimal briefing and no reuse are the defining rules for tissue testers.
Keep a small standing group of tissue testers and invite the same people for each release of the claim submission flow, so that their feedback stays comparable from one release to the next.
Incorrect. Reusing the same people removes the fresh-eyes effect that the technique depends on.
Use them late in the iteration as extra hands on the regression set, because fresh eyes work best once the claim submission flow is complete and behaves as specified.
Incorrect. Tissue testers give informal early feedback on designs; using them late as regression capacity wastes the fresh-eyes effect entirely.
Brief them thoroughly on the acceptance criteria first, so their observations can be traced to requirements.
Incorrect. A thorough briefing biases them towards the intended behaviour.
Tissue testers are fresh-eyes testers brought in from outside the team for quick informal feedback. They are most valuable early, while designs and prototypes are still cheap to change, they should be given little explanation, and the same person should not be reused once they have seen the design, because they are no longer unbiased.
A tester has been embedded in the same MOOC enrolment team for six iterations…
A tester has been embedded in the same MOOC enrolment team for six iterations. She notices she mostly designs tests that confirm behaviour she helped specify, that her first guess about risky areas follows the happy path in the story, and that she rarely contradicts the team in refinement. Which combination best reduces these biases?
Mix perspectives deliberately, run exploratory sessions with a debrief afterwards, pair with a colleague on test design, and occasionally bring in a fresh-eyes tester from outside the team.
Correct. These are the mitigations the syllabus lists against confirmation, anchoring and conformity bias.
Move test design to a colleague outside the team and leave the embedded tester to execute what she is given, so that the designs no longer carry the expectations she formed during refinement sessions.
Incorrect. Removing her from design discards her domain knowledge and leaves the underlying biases unaddressed.
Replace exploratory sessions with a fully scripted regression set, because scripted steps are not shaped by the tester's expectations.
Incorrect. Scripts written by the same person carry the same expectations, and exploratory testing is one of the countermeasures.
Automate more happy-path checks so confirming expected behaviour becomes cheap and frees the tester's time.
Incorrect. This reinforces the anchoring on the happy path rather than counteracting it.
The three biases are confirmation bias, the anchoring effect and conformity bias, and the syllabus notes that the whole team approach can increase the risk of bias. The countermeasures are diversity of thought, exploratory testing in sessions with a debrief, paired testing, fresh-eyes tissue testers, psychological safety and root cause analysis.
Chapter 3 · Test Management and Test Process Improvement — 7 questions
A telemedicine team plans testing at two levels. Which activity belongs to release-level test planning rather than iteration-level test planning?
Deciding how regression and non-functional testing are distributed across the iterations of the release and which external stakeholders must be involved.
Correct. Distribution of test effort across iterations and stakeholder involvement belong to the release-level test strategy.
Running a risk-storming session on the backlog items pulled into the current iteration, with the tester moderating and the clinical expert rating how likely each identified risk is.
Incorrect. Risk storming on the items of the current iteration is part of iteration-level test planning.
Refining the acceptance criteria of the stories the team has just accepted and deriving high-level test conditions from them, which is where the release-wide regression split is settled.
Incorrect. Refining acceptance criteria for accepted stories is iteration planning; how regression is spread over the release is decided separately at release level.
Confirming that the test environment and the anonymised patient data needed for the current stories are ready.
Incorrect. Iteration readiness of environment and data is an iteration planning concern.
Iteration planning covers the current backlog items: risk-storming, high-level test conditions, refining acceptance criteria, iteration readiness of environments and data, and the Definition of Done as story exit criteria. Release planning takes the wider view: quality risks for the whole release, dependencies and integration points, effort estimation, and how regression and non-functional testing are distributed across iterations.
A logistics team tracks testing of its fleet tracking releases. How is test monitoring and test control performed in Agile software development?
Trends from dashboards, defect discovery, automated coverage, exploratory findings and production monitoring are read, and the whole team adjusts course in stand-ups, reviews and retrospectives.
Correct. Monitoring is trend-based and control is a whole-team activity inside the existing events.
Progress is judged by comparing executed test cases against the numbers forecast in the release test plan, and any deviation from that forecast is escalated to the test manager for a control decision.
Incorrect. Agile test monitoring reads trends and signals rather than conformance to a forecast held in a plan, and control is shared by the team.
Control actions are prepared by the tester and applied at the end of the release, when enough data has accumulated to justify them.
Incorrect. Control is continuous and shared, so waiting until the release end removes its value.
The burn-down chart is the single source of test progress, since it already aggregates all quality information the team needs.
Incorrect. A burn-down chart is one of several instruments and carries no quality information by itself.
Monitoring uses burn-down charts, cumulative flow diagrams and automated dashboards, and reads trends in defect discovery, automated coverage, exploratory findings and production monitoring, rather than conformance to a plan. Control is exercised by the whole team in daily stand-ups, iteration reviews and retrospectives, triggered by automated test feedback, production signals and customer feedback loops.
A MOOC team reports test coverage to its stakeholders each iteration. Which statements about the coverage types used for test reporting are correct? (Choose two.)
Code coverage is not a proxy for quality on its own and is better complemented by fault seeding or assertion quality reviews.
Correct. The syllabus warns explicitly against reading code coverage as a quality measure.
Exploratory coverage can be reported through session-based test management and test charter completion rates.
Correct. These are the reporting units suggested for exploratory work.
Requirements coverage is reported by counting the user stories accepted in the iteration, since an accepted story is a covered requirement.
Incorrect. Acceptance criteria, not accepted story counts, are the traceable units for requirements coverage.
Infrastructure and environment coverage is reported as the share of the environments in which the regression suite ran.
Incorrect. Operational coverage is derived from observability of the running system, not from suite execution counts.
Reporting all four coverage types together lets the team treat the combined figure as completeness.
Incorrect. The syllabus warns teams to resist the illusion of completeness created by metrics.
Requirements coverage is expressed through acceptance criteria as traceable units. Code coverage is a weak proxy for quality and should be complemented by fault seeding or assertion quality reviews. Exploratory coverage is reported through session-based test management and charter completion rates. Infrastructure and environment coverage relies on observability. Teams should resist the illusion of completeness that metrics create.
Two logistics teams working on the same fleet platform want to improve their test process. Which way of running that improvement matches Agile software development?
Each team runs focused test retrospectives and a self-assessment, then tries one small change as a hypothesis and evaluates it; metrics are visible but not used to rank the teams against each other.
Correct. Small hypothesis-driven experiments plus visible metrics without cross-team benchmarking is the described approach.
A shared dashboard ranks both teams on defect detection percentage every iteration, so that the team with the lower score can see precisely how much ground it still has to make up on the other team before the next review.
Incorrect. Benchmarking teams against one another on such metrics is warned against and encourages local optimisation.
An external assessor defines a target maturity level for both teams and audits progress towards it every quarter, so that improvement is measured against an independent scale rather than team judgement.
Incorrect. Baseline assessments are meant to be team-owned self-assessments, and an externally imposed maturity target drives conformance rather than learning.
All improvement ideas are collected for a single large change programme rolled out after the next release.
Incorrect. Improvement proceeds through small experiments rather than one large batched rollout.
Improvement is driven through focused test retrospectives, baseline self-assessments, joint risk workshops, stronger CI/CD feedback loops and small experiments. Metrics may be made visible but must not be used to benchmark one team against another, and every improvement is treated as a hypothesis to be evaluated.
An insurance claims app team releases the new payout engine to two percent of users first and watches error rates and support contacts before widening the rollout. Which term describes this?
A canary release.
Correct. A small user share receives the new version first and the rollout widens if the observed signals are good.
A dark launch.
Incorrect. In a dark launch the code is deployed but not reachable by users, so no user share is exposed.
A feature toggle.
Incorrect. A toggle is the switch mechanism; it does not by itself describe a staged rollout with observation.
A Definition of Done check.
Incorrect. The Definition of Done is the set of exit criteria agreed by the team, not a release technique.
A canary release exposes a new version to a small share of users and widens the rollout if observed behaviour is acceptable. A dark launch deploys code that users cannot yet reach, a feature toggle switches functionality on or off, and a Definition of Done is the agreed set of exit criteria.
A telemedicine provider ships its appointment and video-consultation platform to…
A telemedicine provider ships its appointment and video-consultation platform to production twice a week behind feature toggles. A national health authority requires documented acceptance evidence for every change that touches prescription handling, and that evidence must be approved before clinicians can see the change. Observability in the clinical environment is poor: production telemetry is anonymised so aggressively that a failure cannot be traced back to a scenario. The team is stable and cross-functional, and the pipeline is mature, with containerised environments on demand. You are asked to outline the project test strategy using the testing quadrants. Which outline fits these context factors best?
Automate Q1 and Q4 heavily to sustain twice-weekly delivery; strengthen Q2 for prescription handling with boundary value analysis, state transition and decision table testing, and add simulations and prototypes to compensate for weak observability; keep Q3 manual and time-boxed for clinician-facing exploration.
Correct. Delivery frequency drives Q1 and Q4 automation, regulatory criticality drives Q2 technique choice, and low observability is answered by simulations in Q2.
Concentrate effort on Q3 and Q4 because the pipeline is mature and the team is stable, and cover prescription handling by analysing production behaviour after each release, using the anonymised telemetry to assemble the acceptance evidence the health authority asks for and keeping that regulatory work outside the iteration.
Incorrect. The authority requires approved evidence before clinicians see the change, and the aggressive anonymisation makes production telemetry an unusable evidence source.
Put nearly all effort into Q1 and Q2 and drop Q3 and Q4, since those two quadrants deliver the repeatability and confidence a regulator asks for.
Incorrect. Removing Q3 and Q4 removes the innovation and learning side of the strategy and leaves non-functional risk uncovered.
Run one manual Q3 regression pass before each release and rely on feature toggles to limit exposure, deferring Q1 and Q4 automation until the authority relaxes its evidence requirement, since toggles keep unapproved prescription changes hidden from the clinicians and so carry the regulatory risk on their own account.
Incorrect. A single manual pass cannot keep pace with twice-weekly delivery, and toggles limit exposure without producing the approved evidence the authority requires.
Frequent delivery and a mature pipeline argue for heavy automation in Q1 and Q4. High business criticality and a regulatory risk appetite pull effort into Q2, where boundary value analysis, state transition testing and decision table testing produce the required evidence before release. Low observability is answered by simulations and prototypes in Q2. Q3 stays business-facing and manual but time-boxed, because quadrants 3 and 4 are what foster innovation and learning.
Over four iterations a MOOC team collected these figures. Maintenance effort on…
Over four iterations a MOOC team collected these figures. Maintenance effort on the manual regression set rose from 6 to 19 hours per iteration. Thirty-one percent of regression test cases were edited in the last two iterations although the requirements behind them did not change. Twelve percent of automated checks fail intermittently. Component and component integration coverage of the enrolment payment path is 22 percent, while the same path is exercised three times over by end-to-end tests. Feedback time from commit to test results grew from 14 to 41 minutes. Which set of test process improvement measures do these metrics support?
Track maintenance effort and test execution lead times as test debt indicators, rotate test ownership, apply page object and test data builder patterns to the fragile tests, and rebalance the payment path towards component and component integration testing.
Correct. Each measure answers a specific signal in the data: test debt, fragility and an unbalanced distribution of coverage.
Add the missing end-to-end coverage of the enrolment payment path and set an eighty percent code coverage target for the enrolment service, reporting attainment to stakeholders every iteration so that the remaining gap is visible and closes under steady pressure from the dashboard.
Incorrect. The payment path is already exercised three times over end to end, and turning coverage into a target invites local optimisation rather than better tests.
Freeze regression maintenance for two iterations and spend the freed capacity on exploratory sessions, then revisit the suite once the intermittent failure rate has settled.
Incorrect. Suspending maintenance grows the test debt the metrics are already reporting.
Publish a ranking of defect detection percentage across the platform teams each iteration and move testers to whichever team scores lowest.
Incorrect. Cross-team ranking is warned against and none of the collected metrics concerns defect detection percentage.
Rising maintenance effort, edits without requirement changes and intermittent failures are test debt and fragility signals: measure maintenance effort and test execution lead times, rotate test ownership, and apply page object and test data builder patterns. Low coverage of a critical path combined with triple end-to-end coverage calls for rebalancing towards component and component integration testing. Coverage targets and cross-team ranking invite local optimisation.
Chapter 4 · Shift Left — 9 questions
A telemedicine team has no maintained specification for its prescription renewal service. Which example shows testware being used as a form of requirements?
The agreed examples and acceptance-level test cases for renewal eligibility are maintained with the code and consulted as the current statement of required behaviour.
Correct. Examples and acceptance-level test cases kept current are living requirements, an executable specification.
The test results of the last regression run are attached to the release record, which lets stakeholders read the required behaviour of renewal eligibility off the list of checks that passed.
Incorrect. Results record which checks were executed and how they ended; the required behaviour cannot be reconstructed from a pass list.
Defect reports for the renewal service are grouped by component so the team can see where behaviour is unclear, and that grouping then stands in for the missing renewal specification.
Incorrect. Defect reports describe observed problems; a pile of them grouped by component still states no required behaviour for renewal eligibility.
A traceability matrix links each automated check to the backlog item it came from, so coverage gaps become visible.
Incorrect. A matrix relates existing items; on its own it carries no statement of required behaviour.
Testware acts as requirements when acceptance criteria, examples, behaviour-driven scenarios and acceptance-level test cases become living requirements or executable specifications. Test results, defect reports and traceability matrices document what happened or how items relate; they do not describe the required behaviour.
A MOOC team uses storyboarding and testboarding during backlog refinement of the new certificate download journey. Which statements about the two techniques are correct? (Choose two.)
Storyboarding lays the journey out scene by scene, which surfaces usability problems, awkward transitions and unserved learner personas.
Correct. This is the purpose of storyboarding as described in the syllabus.
Testboarding visualises main and alternative scenarios and their priorities, giving the team shared terminology and more maintainable test cases.
Correct. Testboarding makes the intended testing visible and improves maintainability.
Both boards are drawn once, after the product owner has signed the journey off, because redrawing them in later refinement sessions costs more effort than the shared understanding is worth.
Incorrect. Both techniques are applied iteratively during refinement and iteration planning, and the boards are revisited as the journey changes.
Testboarding replaces the acceptance criteria of the story, since the board already shows the scenarios to be checked and their priorities.
Incorrect. A testboard complements acceptance criteria; the criteria stay the agreed statement of what the story must do.
Storyboarding is a design deliverable owned by the designer, so testers contribute only after the board is finished.
Incorrect. Both techniques are collaborative and testers take part while the board is being built.
Storyboarding visualises the user journey scene by scene and exposes usability, transition and persona problems. Testboarding visualises what will be tested: main and alternative scenarios, shared terminology and priorities, which improves the maintainability of test cases. Both are applied iteratively during refinement and planning, act as living documentation and reveal requirements drift.
During an example mapping session on an insurance claims story the wall ends up with one yellow card, two blue cards and eleven green cards, nine of them under a single blue card. How should the team read this result?
One business rule carrying nine examples suggests the story is too large, so it is a candidate for user story slicing.
Correct. A rule with many examples is the signal the syllabus gives for slicing the story.
The absence of red cards proves the story is fully understood, so the session can be closed and the story pulled into the iteration.
Incorrect. No open questions is a good sign, but it does not resolve the size problem the green cards reveal.
Eleven green cards mean the team already has enough test cases, so no further test design is needed.
Incorrect. Examples become a starting point for test cases; they are not a complete test design.
Two blue cards for one story means the rules were written too finely and should be merged into a single rule.
Incorrect. Merging rules hides the imbalance; the number of examples per rule is the meaningful signal.
In example mapping yellow is the user story, blue are business rules, green are examples that become test cases and red are open questions. One rule attracting a large number of examples, or many blue cards, indicates that the story is too large and should be sliced. Many red cards would instead mean that too much is still unknown.
A logistics team writes its fleet tracking stories around the smooth case: a…
A logistics team writes its fleet tracking stories around the smooth case: a driver with one assigned route, a charged phone and a stable connection. Six months later most field complaints concern tunnels, shared vehicles and drivers using screen readers. Which bias does this illustrate, and how does it harm product quality?
The anchoring effect: stories framed on the happy path leave edge cases, accessibility and internationalisation under-examined, so those gaps reach the field.
Correct. This is the harm the syllabus attaches to anchoring on happy-path stories.
Confirmation bias: the team sought evidence that fleet tracking worked as intended and read the tunnel and shared-vehicle reports as isolated incidents rather than as a pattern.
Incorrect. Confirmation bias concerns how evidence is sought and interpreted; here the harm came from the narrow framing of the stories themselves.
Conformity bias: the tester did not voice doubts about the narrow framing of the stories because the rest of the development team was satisfied with them as written.
Incorrect. Conformity bias is about aligning with the group; here the damage came from how the stories were framed, not from unspoken doubts.
No bias is involved: the missing scenarios are simply requirements that the product owner chose not to prioritise.
Incorrect. The pattern of systematically framing stories on the smooth case is precisely what bias means here.
The anchoring effect makes the team fix on the first framing it received. Happy-path stories anchor the team so that edge cases, accessibility and internationalisation receive too little attention, and the resulting gaps appear in the field. Confirmation bias concerns seeking evidence that supports existing beliefs, and conformity bias concerns aligning with the group.
A telemedicine team reviews a story that says the portal should show appointment slots quickly and only for suitable clinicians. Which requirements engineering activity does this review belong to, and which validation criteria does the story fail?
Validation; the story is neither unambiguous nor testable, because quickly and suitable are not defined in measurable terms.
Correct. Validation applies the criteria correct, unambiguous, complete, consistent and testable, and two of them fail here.
Elicitation; the undefined terms show that interviews, workshops and prototyping with clinicians were skipped, so the detail has to be gathered rather than judged.
Incorrect. The activity described is a review of a statement that already exists, which belongs to validation.
Analysis; the story is incomplete and inconsistent because it mixes a performance concern with an eligibility rule.
Incorrect. Reviewing against criteria is validation, and the named failures are ambiguity and testability.
Specification; the story should have been recorded as a state transition diagram to remove ambiguity.
Incorrect. Choosing a notation is specification, and a diagram alone does not define what quickly or suitable mean.
Validation checks that requirements are correct, unambiguous, complete, consistent and testable. Quickly and suitable are not measurable, so the story fails on being unambiguous and testable. Elicitation gathers requirements, analysis structures them and specification records them in a chosen form.
A MOOC team decides that during backlog refinement the tester, a developer and the curriculum lead will draft test charters together for each story they discuss. How does this practice support shift left?
Drafting the charter forces the group to state mission and scope while the story is still being shaped, so vague acceptance criteria and unstated assumptions surface before any code is written.
Correct. Producing testware during refinement is defect prevention, which is what shift left aims at.
It moves exploratory execution earlier, so the charters drafted during refinement can be run against the current increment in that same meeting and the defects they reveal are caught before the story is accepted.
Incorrect. The story under refinement is not built yet, so there is nothing to execute the charter against; the benefit comes from the conversation.
It lets the team replace the acceptance criteria with the charter, which removes the duplication between the two artefacts and gives refinement one single testable statement of what the story owes.
Incorrect. Acceptance criteria feed the charter and serve as lightweight oracle notes; a charter states a mission to explore and cannot replace them.
It shifts responsibility for test design onto the curriculum lead, freeing the tester to concentrate on automation.
Incorrect. Charter drafting is collaborative and does not transfer test design to the business representative.
Charters drafted while the story is still being refined are testware created before code exists. Writing them forces the group to state the mission and scope of testing, which exposes vague acceptance criteria and unstated assumptions at the cheapest moment and gives the team a piece of living documentation to work from.
An insurance claims team wants to record the claim lifecycle in a semi-formal scenario model so the states a claim can reach are unambiguous. Which specification forms serve that purpose? (Choose two.)
A state transition diagram of the claim lifecycle.
Correct. State transition diagrams are one of the semi-formal scenario models listed.
A business process model of claim handling, for example in BPMN.
Correct. Business process models are named as a semi-formal scenario model.
User stories for each step of the lifecycle.
Incorrect. User stories are free-form specification, not a semi-formal scenario model.
An epic gathering all claim handling work under one short business narrative.
Incorrect. An epic is also free-form and describes scope rather than modelling the states a claim passes through.
A glossary defining terms such as claim, adjuster and payout.
Incorrect. A glossary aligns terminology but models no scenarios or states.
Semi-formal scenario models include use cases, business process models such as BPMN and state transition diagrams. Free-form specification covers user stories and epics, and a glossary standardises terminology without modelling scenarios.
A logistics team holds this story: as a dispatcher I want to import the daily…
A logistics team holds this story: as a dispatcher I want to import the daily route plan so that drivers see their stops. Its acceptance criteria are: CSV, XLSX and the partner XML feed are all accepted; a row with an unknown depot code is rejected and its line number reported; duplicate stop identifiers inside one plan are merged; a plan of more than 5000 rows is processed in the background with a progress indicator. The story clearly does not fit one iteration, and the team decides to slice it by data complexity. Which slicing produces the most testable first slice and handles the acceptance criteria correctly?
First slice: import a CSV plan under 5000 rows with known depot codes and unique stop identifiers, with acceptance criteria rewritten for exactly that case; the other formats, the rejection rule, merging and background processing follow as later slices with their own rewritten criteria.
Correct. The simplest data set gives a narrow testable outcome, and each slice carries acceptance criteria written for it.
First slice: accept all three formats without validating the rows, and copy the four original acceptance criteria onto the slice unchanged so that traceability to the parent story is preserved; validation, merging of duplicate stop identifiers and background processing then follow in later slices.
Incorrect. The syllabus rules out carrying the parent criteria into a slice, and a slice that accepts unvalidated data delivers no complete outcome.
First slice: implement the rejection and merging rules for all three formats and defer only the background processing, since the volume rule is the single non-functional criterion.
Incorrect. This keeps almost the whole story in one slice and slices by criterion type rather than by data complexity.
Split the work by team member, making one slice per acceptance criterion and assigning each to whoever has capacity, so all four criteria land in the same iteration.
Incorrect. Capacity is not a slicing dimension and a criterion alone is not a narrow user outcome.
Slicing by data complexity starts from the simplest data the dispatcher can still get value from and adds complexity in later slices. Every slice needs its own rewritten acceptance criteria; the original criteria are not copied into the slices, and the slices together must cover the original story.
A MOOC team must deliver this story in the next two iterations: as a learner I…
A MOOC team must deliver this story in the next two iterations: as a learner I want to book a live tutoring slot so that I get help before the exam. Acceptance criteria: a slot can be booked only if the learner is enrolled in the course; a learner may hold at most two open bookings; a booked slot disappears from the list for other learners; the learner sees a confirmation with the tutor name and the time in the learner's own time zone. The team slices by interface, taking the backend first. Which statement describes that slicing correctly?
The first slice delivers the booking endpoint with the enrolment and two-booking rules, with acceptance criteria rewritten so they can be verified through that endpoint; the learner-facing screen and the confirmation in the learner's time zone follow as a later slice with its own criteria.
Correct. Each slice states a narrow outcome and carries criteria written for the interface it exposes, and together they cover the story.
Because the first slice has no screen, its acceptance criteria can be judged only once the second slice exists, so testing of the enrolment and two-booking rules waits for the learner-facing screen, and the backend slice is only reviewed rather than tested until that screen has been delivered.
Incorrect. Testability is the main criterion for slicing, and an endpoint slice is verifiable through its own interface without waiting for a screen.
Both slices keep the four original acceptance criteria unchanged, which preserves traceability to the story and ensures nothing is forgotten.
Incorrect. Acceptance criteria are rewritten per slice; copying them leaves each slice unverifiable on its own.
Interface slicing stops being applicable as soon as a story requires a screen, so the team should abandon it and switch to vertical slicing instead, giving every slice a thin path from the database through the service layer to the screen while keeping the four original acceptance criteria unchanged.
Incorrect. Interface slicing is a listed dimension and stays applicable, and vertical slicing would also require criteria rewritten per slice.
Interface slicing separates the backend from the user interface and commonly delivers the API first. The first slice must still be testable in its own right, through the interface it exposes, so it needs acceptance criteria rewritten for that interface. The criteria of the original story are not carried over unchanged, and the slices together must cover the original story.
Chapter 5 · Agile Approaches and Test Techniques — 12 questions
A telemedicine tester keeps a personal note that says: whenever a screen shows a date, check the day the clocks change. Which category of test heuristic is this, and what does its use imply?
A rule of thumb: an experience-based shortcut that guides attention but can be wrong, so it complements rather than replaces test analysis.
Correct. Rules of thumb are one of the five heuristic categories and are fallible by nature.
A generic checklist, because the note states a condition the tester applies to every screen showing a date and so works as a reusable list for the whole product.
Incorrect. A generic checklist is a reusable list covering a domain such as usability or security, not one remembered condition.
A mnemonic, because it helps the tester remember a class of conditions that is easily overlooked.
Incorrect. A mnemonic uses a memorable letter structure to recall a set of areas, such as SFDIPOT.
An analogy, because it transfers experience from one product to another product with similar date handling.
Incorrect. Analogies and metaphors compare the system under test to something else; this note states a condition directly.
Test heuristics come in five categories: guidelines, generic checklists, rules of thumb, mnemonics, and analogies and metaphors. A short experience-based rule of this kind is a rule of thumb. Heuristics guide attention and are fallible, so they support rather than replace analysis.
A team testing an insurance claims mobile app wants a mnemonic that reminds it of areas such as interruptions, ergonomics, platform and network conditions. Which mnemonic fits, and what is it intended for?
I SLICED UP FUN, a mnemonic for mobile testing covering areas such as inputs, store, location, interruptions, ergonomics, platform and network.
Correct. This mnemonic was created for mobile applications and includes exactly those areas.
SFDIPOT, a mnemonic for structure, function, data, interfaces, platform, operations and time, proposed specifically to structure the testing of mobile applications.
Incorrect. SFDIPOT covers product elements of any system and names neither interruptions nor ergonomics; it was not proposed for mobile.
RCRCRC, a mnemonic for recent, core, risky, configuration, repaired and chronic areas, proposed for choosing what to cover on a given mobile device.
Incorrect. RCRCRC helps select regression tests by risk and change history rather than explore mobile-specific conditions.
FEW HICCUPPS, a mnemonic for consistency dimensions used when reasoning about test oracles.
Incorrect. FEW HICCUPPS supports deciding whether observed behaviour is a problem, not mobile coverage.
I SLICED UP FUN stands for Inputs, Store, Location, Interactions and Interruptions, Communication, Ergonomics, Data, Usability, Platform, Function, User scenarios and Network, and it was proposed for mobile testing. SFDIPOT covers product elements generally, RCRCRC supports regression selection and FEW HICCUPPS supports test oracles.
Before extending its automated checks a MOOC team walks through the TERMS mnemonic. Which set of factors does TERMS bring to that discussion?
Tools and technology, execution, requirements and risks, maintenance, and security, as success factors for test automation.
Correct. These are the five elements of TERMS and its stated purpose.
Structure, function, data, interfaces, platform, operations and time, as product elements.
Incorrect. That is SFDIPOT, which structures coverage of the product rather than automation factors.
Recent, core, risky, configuration, repaired and chronic areas, as criteria for choosing what to re-check.
Incorrect. That is RCRCRC, a regression selection mnemonic.
Familiarity, explainability, world, history, image, comparable products, claims, users' desires, product, purpose and statutes.
Incorrect. That is FEW HICCUPPS, which supports reasoning about test oracles.
TERMS stands for Tools and Technology, Execution, Requirements and Risks, Maintenance, and Security, and it collects factors that influence the success of test automation. The other options describe product elements, regression selection criteria and oracle consistency dimensions.
A tester plans test tours of a logistics fleet tracking portal. Which statements about test tours are correct? (Choose two.)
A tour of the business district concentrates on the features that carry the main business value of the product.
Correct. The business district covers the core value-carrying functionality.
A tour of the seedy districts uses negative testing, error guessing and fault attacks.
Correct. This is the stated purpose of the seedy districts tour.
A tour of the historical district covers the features released in the current iteration, because their history is still short.
Incorrect. The historical district covers older, legacy parts of the product rather than the newest ones.
Each tour has to be written up as a scripted test suite before it is run, so the route can be repeated.
Incorrect. Tours organise exploration and do not require a scripted route.
A tour of the hotel district covers the features demonstrated to buyers.
Incorrect. That fits the tourist district idea; the hotel district concerns secondary features left running in the background.
Test tours borrow the metaphor of touring districts of a city. The business district covers the features that carry the main business value, and the seedy districts cover negative testing, error guessing and fault attacks. The historical, tourist, entertainment and hotel districts each have their own focus, and a tour organises exploration rather than forming a scripted suite.
Six people from a telemedicine team hold a two-hour mob testing session on the new clinician calendar. How is such a session organised?
One person drives the keyboard, one navigates, the rest observe, and the driver and navigator roles rotate roughly every four minutes; the moderator stays outside the rotation and the session closes with a retrospective.
Correct. This matches the roles, the rotation interval and the closing retrospective described for mob testing.
The moderator keeps the keyboard for the whole two hours so the group can concentrate on observing and suggesting, and the navigator and mob roles are assigned at the start and left in place, since rotating them would break the flow.
Incorrect. The moderator may take any role except driver, and rotation roughly every four minutes is central to the technique.
The group splits into three pairs, each pair takes one part of the calendar, and the findings are merged at the end of the two hours, which keeps all six people productive instead of leaving four of them watching a keyboard.
Incorrect. That is parallel pair testing; mob testing keeps the whole group working on one thing at a time, which is where the shared learning comes from.
Roles are fixed for the whole session and assigned by skill, so the most experienced tester navigates and a developer drives throughout.
Incorrect. Fixed roles remove the shared learning that rotation produces.
Mob testing, also called ensemble testing, is usually done by five to eight people and rests on the idea of swarming. The roles are moderator, navigator, driver and the mob of observers; roles rotate roughly every four minutes, with the navigator becoming driver and the driver returning to the mob. The moderator sits behind the group, does not rotate and may take any role except driver. A retrospective closes the session.
A MOOC team has paired its senior tester with a new joiner for every session over three iterations. The senior tester reports mental fatigue and the new joiner says she mostly watches. How should the team respond?
Use pairing selectively for the areas where it pays off, swap roles regularly inside each session, and agree the objective of the session before it starts.
Correct. These are the three remedies the syllabus gives for the known problems of pair testing.
Extend each session by an hour so the new joiner gets her turn at the keyboard once the senior tester has worked through the difficult parts of the catalogue search on her own.
Incorrect. Longer sessions add to the fatigue already reported and leave the domination problem untouched.
Stop pairing and let each of them test separately, since pair testing suits neither mentoring nor exploratory work.
Incorrect. Mentoring and exploratory testing are named as situations where pair testing is particularly useful.
Convert the pair into a mob of five so the workload spreads across more people and no single person dominates.
Incorrect. Mob testing serves a different purpose and consumes considerably more team effort.
Pair testing is effortful and can suffer from mismatched working styles, domination by one participant and mental fatigue. The remedies are to use pairing selectively where it pays off, to swap roles regularly during a session and to agree clear objectives before the session starts.
Part of an insurance claims app was generated from natural-language prompts, and the team now applies vibe testing to it. What does vibe testing mean here?
Intent-first validation: checking what the application ought to do in real use, which exposes omissions such as missing input validation, unhandled invalid data and role-based logic.
Correct. Vibe testing works from intent rather than from the behaviour the generated code happens to exhibit.
Deriving the test cases from the generated code itself, so that every branch the model produced is covered by at least one check and a coverage figure can be reported for the generated part.
Incorrect. Tests derived from the generated code reproduce whatever the model left out, so the omissions stay invisible.
Asking the language model to grade the quality of the increment and accepting its verdict as the test results, since the model that wrote the code can also judge whether it meets intent.
Incorrect. The tester keeps the judgement, and a model asked to grade its own output repeats the assumptions that produced the omissions.
A standardised ISTQB technique for testing AI-generated code, with a defined set of steps and exit criteria.
Incorrect. The syllabus states that vibe testing is new and not yet standardised.
Vibe testing is a new, not yet standardised AI-assisted approach that grew alongside vibe coding. It is intent-first validation: the tester checks what the application should do in the real world rather than what it happens to do, which surfaces things a language model silently omitted, such as input validation, handling of invalid data and role-based logic.
A telemedicine epic called prescription renewal without a consultation holds…
A telemedicine epic called prescription renewal without a consultation holds three stories. US-1: as a patient I want to request renewal of an existing prescription, with the criteria that only prescriptions issued in the last twelve months qualify and that a request appears as pending. US-2: as a clinician I want to approve or decline requests from a queue, with the criterion that a decline needs a reason from a fixed list. US-3: as a patient I want to be told the outcome, with the criterion that notification goes out by push and by email. Two product risks are recorded for the epic: a withdrawn medicine being renewed, and a request approved by a clinician not registered for that patient. Which set of test charters follows best from analysing this epic?
Three charters organised around the recorded risks rather than the story boundaries: eligibility of the source prescription including withdrawn medicines; clinician authorisation and handling of decline reasons in the queue; delivery and consistency of the outcome notification. Each states a mission and a scope, with the acceptance criteria used as oracle notes.
Correct. Charters built on the epic's risks cross story boundaries and carry the required mission and scope.
One charter per story, each taking the full text of the story as its mission and the acceptance criteria of that story copied in unchanged as its scope, so that traceability from the epic through each story to its charter stays complete, and the two recorded product risks are then picked up by whichever of the three charters happens to touch them during the session.
Incorrect. Neither recorded risk sits inside a single story, so leaving their coverage to chance leaves both of them untested.
A single charter for the epic with the mission to test prescription renewal end to end, with the scope left open so the session can follow whatever the tester notices.
Incorrect. Scope is a mandatory part of a charter, and one open charter for a whole epic gives no usable focus.
Three charters that restate the acceptance criteria of each story as pass or fail checks, treating those criteria as the complete test oracle for the epic.
Incorrect. Acceptance criteria are lightweight oracle notes rather than exhaustive oracles, and this reduces exploration to confirmation.
Charters are derived from user stories, acceptance criteria, product risks and iteration goals, and each needs at least a mission or test objective and a scope. Recorded epic-level risks cut across story boundaries, so charters organised around those risks cover more than one charter per story would. Acceptance criteria serve as lightweight oracle notes but are not exhaustive test oracles.
A telemedicine tester has three hours left before the iteration review and one…
A telemedicine tester has three hours left before the iteration review and one charter: explore the clinician calendar sync for clashes between externally imported appointments and slots booked in the portal, using two clinician accounts and a shared room resource. She wants to apply exploratory testing in a session-based way so the outcome can be reported at the review. How should she organise the three hours?
Run two sessions of roughly ninety minutes, each with a pre-session setup, an execution phase and a post-session review, recording coverage, evaluation notes and anomalies in a session sheet as she goes.
Correct. Two time-boxed sessions within the recommended range, each with all three phases, produce reportable results.
Work through all three hours as a single uninterrupted session and write the notes up afterwards from memory, so that none of the remaining time before the review is lost to repeated setup and post-session overhead.
Incorrect. Three hours exceeds the recommended time box, and recording during execution is part of the technique rather than overhead.
Spend the first two hours converting the charter into scripted test cases with expected results, then execute them in the final hour and report the pass rate.
Incorrect. This replaces exploratory testing with scripted execution and loses the learning the charter is meant to produce.
Run six short sessions of thirty minutes each so that more areas are touched, and defer every review to the team retrospective after the iteration.
Incorrect. Thirty minutes falls below the recommended time box and deferring the review removes the immediate feedback.
A test session is time-boxed, typically between 60 and 120 minutes, and has three phases: pre-session setup, test execution and post-session review. During execution the tester records coverage, including risk coverage, evaluation notes, actual behaviour and anomalies on a session sheet or in equivalent notes. The post-session review compares the charter against reality and identifies defects, open questions and next steps.
A telemedicine team ran four exploratory test sessions in iteration 14. The…
A telemedicine team ran four exploratory test sessions in iteration 14. The chart shows, per session, the time box, the time actually spent on the chartered mission, the number of product areas touched, the anomalies logged and the open questions raised. At the post-session reviews the team must decide what to change for the next iteration.
Which conclusion is best supported by these session results?
Session 4 drifted from its charter, spending 55 of 120 minutes on the mission across nine areas and raising six open questions, so its charter should be split into narrower ones and the questions taken to refinement; session 3, at 45 minutes and two areas, is small enough to be merged with another charter.
Correct. Time on mission against areas touched and open questions is what reveals a charter that is too broad, and session 3 fell below the usual time box.
Session 2 logged the most anomalies, so its charter is the best written of the four and should be reused as the template for the other three areas.
Incorrect. Anomaly count depends on where the defects happen to be and is not a measure of charter quality.
Session 4 touched nine separate product areas, so it delivered the broadest coverage of this release and its charter should be left exactly as it is; its time box should instead be extended to 180 minutes in the next iteration so that the tester can finish all the areas she did not reach within the 120 minutes.
Incorrect. Nine areas on 55 minutes of mission time is unfocused breadth, and 180 minutes sits outside the recommended time box.
Session 3 found one anomaly in 45 minutes, the best rate per minute of the four, so all sessions should be shortened to 45 minutes.
Incorrect. Session 2 logged five anomalies in a comparable period, and shortening every session below the recommended time box is not supported.
The post-session review compares the charter against reality. Session 4 spent only 55 of its 120 minutes on the chartered mission while touching nine areas and raising six open questions, which is the signature of a charter whose scope is too broad. Session 3 ran only 45 minutes, below the usual 60 to 120 minute time box, and touched two areas, so its charter is small enough to be combined with another. Anomaly counts alone say nothing about charter quality.
A team maintaining an insurance claims app reviewed the six manual test cases of…
A team maintaining an insurance claims app reviewed the six manual test cases of its iteration-9 regression set and marked the test smells it found in each. The matrix below shows the result, grouped by smell category.
The team wants to tackle the fragility of the set first, meaning the test cases most likely to fail for reasons that have nothing to do with the behaviour under test. Which test case should be reworked first, and how?
TC-04, because it carries interdependence, hidden dependencies, environment assumptions, a missing teardown and hardcoded data at once: make it runnable on its own, state its preconditions, parameterise or generate its data and add a teardown step.
Correct. It is the only case carrying all five fragility-related smells, and each part of the remedy answers one of them.
TC-02, because smells in the expected results category leave the tester unable to reach any verdict at the end of the run, and a case that yields no verdict is worth less to the team than one that occasionally fails for reasons outside the behaviour under test.
Incorrect. Unclear expected results weaken the verdict, but the team is addressing fragility, which is about failing for unrelated reasons.
TC-01, because hardcoded test data is by itself the strongest fragility signal and the photo upload data expires soonest, so refreshing that one fixture restores the stability of the whole iteration-9 regression set before the other cases are touched.
Incorrect. TC-01 shows only one fragility smell, while TC-04 shows five, so refreshing its data leaves the fragile case in the set untouched.
TC-06, because a missing cleanup step leaves state behind that will break whichever test case happens to run next in the set.
Incorrect. TC-06 does show that smell, but TC-04 shows it together with four more and is therefore the more urgent case.
TC-04 carries Interdependent Tests, Hidden Dependencies, Environment Assumptions, No Cleanup or Teardown and Hardcoded Test Data at the same time. Every one of these makes the outcome depend on something other than the payout logic, so it is the most fragile case in the set. The remedy follows the smells: make it runnable on its own, state its preconditions explicitly, generate or parameterise its data and add a teardown.
Two steps from a manual test case for the claim rejection flow of an insurance…
Two steps from a manual test case for the claim rejection flow of an insurance app read as follows. Step 2: click or push the submit control and see what happens. Step 4: check that the claim looks right afterwards. The team is evaluating the quality of the test case using test smells. Which two evaluations, each with its remedy, are correct? (Choose two.)
Step 4 shows No Clear Expected Results; replace looks right with the state to be observed, such as the resulting claim status and the recorded rejection reason.
Correct. Without a stated expected result the step yields no verdict, and naming the observable state fixes it.
Step 2 shows Ambiguous Steps with the click-push-press pattern; name the control being used, state the expected outcome and keep one consistent verb throughout the test case.
Correct. Vague action wording and a varying verb are exactly this smell, and precise naming with a consistent verb resolves it.
The two steps show Bulk Steps; merge them into one instruction so the test case becomes shorter and easier to follow.
Incorrect. Bulk Steps means several actions crammed into one step, and merging would make the wording less precise.
Step 4 shows Hidden Dependencies; the state of the claim is produced by an earlier test case in the regression set, and that is why the expected result of this step cannot be written down.
Incorrect. Nothing in the steps points to another test case, and a dependency on one would not stop the team stating an expected result.
Step 2 shows Invalidation Heaven; the case checks too many invalid inputs at once, which is what makes the expected outcome of the submit action vague and unverifiable.
Incorrect. Invalidation Heaven is an excess of negative checks, and only one submit action is described here.
Step 4 shows No Clear Expected Results: the tester cannot reach a verdict because the state to be observed is not stated, and the remedy is to name it, for example the resulting claim status and the recorded rejection reason. Step 2 shows Ambiguous Steps together with the Click-Push-Press pattern: the control and the expected outcome are not identified and the verb varies, so the remedy is to name the control, state the outcome and keep one consistent verb.
Chapter 6 · Test Automation and Test Tools — 2 questions
A logistics team decides what to automate for its fleet tracking product. Which candidate selection matches the automation approach described for Agile software development?
Automate the repetitive, deterministic checks that reduce real risk at component and API level, keep a narrowly bounded end-to-end set, and leave exploratory and one-off testing manual.
Correct. Risk and value drive selection, and the distribution across levels follows the shape the syllabus describes.
Automate first the checks that have passed in every run of the last year, because their stability keeps maintenance cost low and a green suite gives the team a dependable signal before each release.
Incorrect. A check that keeps passing yields little information, so low maintenance cost on its own is a weak reason to automate it.
Automate the areas that change most from iteration to iteration, so that the automated set keeps pace with the newest behaviour of the product and the newest code is the first one to be covered.
Incorrect. Frequently changing tests are poor automation candidates because the maintenance cost outruns the information they return.
Automate the exploratory sessions on the tracking map first, since they consume the most tester time each iteration.
Incorrect. Exploratory testing stays manual; automation complements it rather than replacing it.
Automation decisions follow risk and value. Repetitive, deterministic checks that reduce real risk are good candidates, while frequently changing tests are poor ones and checks that never fail add little. The typical shape is component tests, API tests and a narrowly bounded set of end-to-end tests, and exploratory and one-off testing stay manual, since automation complements rather than replaces them.
A MOOC team reviews which categories of tool support its Agile delivery. Which statements about test tools in Agile software development are correct? (Choose two.)
Monitoring and analytics tooling belongs in the list, because observing the running system is itself treated as a form of testing.
Correct. The syllabus describes monitoring as testing and names monitoring and analytics as a tool category.
AI tools can generate test cases from code or requirement changes, flag ambiguity in user stories and produce realistic test data including edge cases.
Correct. These are the uses of AI tooling listed for Agile testing.
The tool set should be chosen first, because the available tooling then determines which test strategy the team can realistically adopt.
Incorrect. Selection is meant to follow from the test strategy and the automation layers, not the other way round.
Task management and communication tools fall outside the test tool categories, since they support the process only.
Incorrect. Both are named as tool categories that help Agile testing, for instance during refinement and reviews.
Session recording and screenshot tools are of little use once exploratory testing is session based, because the session sheet already holds the evidence the team needs later.
Incorrect. Recordings and screenshots are named among the ways of capturing what happened during a session.
Useful tool categories include task management and tracking, communication and collaboration, test design, implementation and execution frameworks, continuous integration, configuration management, session recording and screenshots, monitoring and analytics, and AI tools. Monitoring is treated as a form of testing, and AI tools can generate test cases from changes, predict build failures, analyse stories for ambiguity and generate realistic data with edge cases. Tool choice must follow the test strategy and the automation layers rather than convenience or fashion.