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 is an after-iteration activity, because code coverage can be judged once the increment is integrated.
Incorrect. White-box testing sits closest to the code and is normally done inside the iteration, per story.
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, since end-to-end runs give the fastest diagnosis of where an integration broke.
Incorrect. End-to-end tests are slow and give poor diagnostic precision, which is why their scope is limited.
Not at all once consumer-driven contract tests exist for the subcontractor API, because contracts cover the integration risk.
Incorrect. Contract testing reduces the number of end-to-end tests needed but does not cover whole user journeys.
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 they cover.
Incorrect. Traceability is a benefit of formal testing, not a drawback.
Insufficient conformance evidence for an external audit of the subcontracted parts.
Incorrect. Conformance evidence is a benefit of formal testing.
Difficulty in measuring what has been tested, since coverage 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 added to it.
Incorrect. That describes the incremental regression approach.
A bug bash and a whole-team walkthrough are organised before the release to re-examine the areas that 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 instead of accepting new stories.
Incorrect. A bug bash is a collaborative regression activity, not a definition of a hardening iteration.
It is the iteration in which feature toggles are stripped from the code so the release build carries only production paths.
Incorrect. Toggle removal is refactoring work and is unrelated to the purpose of the iteration.
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 should move to full generalisation so that any member can produce the regulatory acceptance evidence.
Incorrect. Regulated domains are exactly where the syllabus expects more specialisation to be retained.
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 each team member performs every activity about equally often, which is what makes the profile T-shaped.
Incorrect. A T-shaped profile combines breadth with one area of real depth, not uniform effort.
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.
Incorrect. Turning them into extra execution capacity wastes their domain knowledge and demotivates.
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, so developers need not interpret quality data themselves.
Incorrect. Quality is a whole-team responsibility and cannot be delegated to a separate group.
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 and invite the same people each release, so their feedback becomes comparable over time.
Incorrect. Reuse destroys the fresh-eyes effect the technique depends on.
Use them late in the iteration as extra hands on the regression set when the team is short of capacity.
Incorrect. They give informal exploratory feedback and do not substitute for structured testing.
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, leaving the embedded tester to execute what she is given.
Incorrect. Removing her from design loses her domain knowledge and does not address the biases.
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.
Incorrect. Risk storming on the current items is an iteration planning activity.
Refining the acceptance criteria of the stories the team has just accepted and deriving high-level test conditions from them.
Incorrect. Refining acceptance criteria for accepted stories is iteration planning.
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 deviations are escalated to the test manager.
Incorrect. Agile monitoring works from trends and signals rather than conformance to a forecast.
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 environments in which the regression suite was executed.
Incorrect. Operational coverage is derived from observability of the running system, not from suite execution counts.
Once all four coverage types are reported together, the team can treat the combined figure as evidence of 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 each iteration, so the weaker team can see what it must catch up on.
Incorrect. Cross-team benchmarking on such metrics is warned against and provokes local optimisation.
An external assessor defines a target maturity level for both teams and audits progress towards it every quarter.
Incorrect. Baseline assessments are meant to be team-owned self-assessments, not externally imposed maturity targets.
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 cover prescription handling by analysing production behaviour after each release to build the acceptance evidence.
Incorrect. The authority requires approved evidence before exposure, and poor telemetry makes production analysis 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.
Incorrect. A single manual pass cannot keep pace with twice-weekly delivery, and deferring automation wastes the mature pipeline.
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 payment path and set an 80 percent code coverage target for the enrolment service, reporting attainment to stakeholders every iteration.
Incorrect. The path is already covered three times end to end, and turning coverage into a target invites local optimisation.
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 so stakeholders can see what was verified.
Incorrect. Results report what was executed; they do not state the required behaviour.
Defect reports for the renewal service are grouped by component so the team can see where behaviour is unclear.
Incorrect. Defect reports describe observed problems rather than the intended behaviour.
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 are one-off activities performed once the journey has been signed off, so that the boards do not have to be redrawn.
Incorrect. Both are applied iteratively during refinement and iteration planning.
Testboarding replaces the acceptance criteria of the story, since the board already shows the scenarios to be checked.
Incorrect. It complements acceptance criteria rather than replacing them.
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 has produced enough test cases, so no further test design is needed for this story.
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 at too fine a level 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 looked for evidence that the tracking feature worked and interpreted ambiguous field reports in its favour.
Incorrect. Confirmation bias concerns how evidence is sought and read, not the narrow framing of the stories.
Conformity bias: the tester did not voice doubts because the rest of the team was satisfied with the story as written.
Incorrect. Conformity bias is about aligning with the group, which the scenario does not describe.
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 missing detail shows that interviews, workshops or prototyping were not used before writing the story.
Incorrect. The activity described is a review of an existing statement, which is 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 written as a state transition diagram so that the wording could not be ambiguous.
Incorrect. Choosing a notation is specification, and a diagram alone does not remove undefined terms.
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 can be run against the increment during the same refinement meeting.
Incorrect. Nothing is built yet at refinement; the benefit comes from the conversation, not from early execution.
It lets the team replace the acceptance criteria with the charter, which removes the duplication between the two artefacts.
Incorrect. Acceptance criteria feed the charter and serve as lightweight oracle notes; the charter does not 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.
A set of user stories for each step of the claim lifecycle.
Incorrect. User stories are free-form specification, not a semi-formal scenario model.
An epic gathering all claim handling work with a short narrative.
Incorrect. An epic is also free-form and describes scope rather than modelling states.
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 with no validation, copying the four original acceptance criteria onto the slice so that nothing is lost, then add validation, merging and background processing later.
Incorrect. Copying the original acceptance criteria into a slice is exactly what the syllabus rules out, and the slice covers 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 rules waits for the user interface.
Incorrect. Testability is the main criterion for slicing, and an endpoint slice is verifiable through its own interface.
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 does not apply when the story requires a screen, so the team should switch to vertical slicing and give every slice a thin path from database to screen.
Incorrect. Interface slicing is a listed dimension and remains applicable; vertical slicing is an alternative, not a correction.
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 lists a condition that has to be verified on every screen showing a date.
Incorrect. A generic checklist is a reusable list covering a domain, such as usability or security items, not a single remembered rule.
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.
Incorrect. SFDIPOT covers product elements in general and does not name interruptions or ergonomics.
RCRCRC, a mnemonic for recent, core, risky, configuration, repaired and chronic areas.
Incorrect. RCRCRC helps select regression tests 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 worth covering.
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 executed, so that the route can be repeated exactly.
Incorrect. Tours organise exploration and do not require a scripted route.
A tour of the hotel district covers the features the sales team demonstrates most often to prospective customers.
Incorrect. That description 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 session so the group can concentrate on observing and suggesting, and rotation is unnecessary.
Incorrect. The moderator may take any role except driver, and rotation 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.
Incorrect. That is parallel pair testing; mob testing keeps the whole group working on one thing at a time.
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 the sessions so the new joiner eventually gets her turn at the keyboard once the senior tester has finished the difficult parts.
Incorrect. Longer sessions increase fatigue 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 test cases from the generated code so that every branch a model produced is covered by at least one check.
Incorrect. Working from the generated code reproduces its omissions instead of revealing them.
Asking a language model to grade the quality of the increment and accepting its verdict as the test result.
Incorrect. The tester keeps the judgement; the approach is not a delegation of the verdict to a model.
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 story text as its mission and the story's acceptance criteria copied in as its scope, which keeps traceability from epic to charter complete.
Incorrect. Copying story text leaves the two epic-level risks uncovered, since neither belongs to a single story.
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 the whole three hours as one uninterrupted session and write the notes afterwards from memory, so that no time is lost to setup and review overhead.
Incorrect. Three hours exceeds the recommended time box, and recording during execution is part of the technique.
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 areas, so it gives the broadest coverage of the release; its time box should be extended to 180 minutes next iteration and its charter left unchanged.
Incorrect. Touching nine areas in 55 minutes on mission is unfocused breadth, and 180 minutes exceeds 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 without a verdict, which is the most damaging kind of defect a test case can have.
Incorrect. Unclear expected results reduce the value of the verdict but do not make the case fail for unrelated reasons, which is the fragility the team is addressing.
TC-01, because hardcoded test data is by itself the strongest fragility signal and the photo upload data expires soonest.
Incorrect. TC-01 shows only one fragility smell, while TC-04 shows five, so it is not the first candidate.
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 claim state comes from an earlier test case, which is why the expected result cannot be stated.
Incorrect. Nothing in the steps points to another test case, and a dependency would not prevent 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 vague.
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 the checks that have never failed in the last year first, because their stability makes them the cheapest to maintain.
Incorrect. Checks that never fail deliver little information, so stability alone is not a reason to automate them.
Automate the areas that change most from iteration to iteration, so that the automated set always reflects the newest behaviour.
Incorrect. Frequently changing tests are poor automation candidates because of their maintenance cost.
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 rather than testing itself.
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.
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.