ISTQB Advanced (CTAL-AT v2.0) Mock Exam #1 — 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.
A mobile banking team has replaced its quarterly release cycle with two-week iterations. The team now has to decide which testing happens inside an iteration and which is deferred until after it. Which two statements describe an appropriate split of test types according to the syllabus? (Choose two.)
Functional and non-functional checks that can already be run against the increment are performed inside the iteration, and the team records that decision in its Definition of Done and its test approach.
Correct. Chapter 1.1 links the in-iteration/post-iteration decision for each test type to the Definition of Done and the test approach.
End-to-end testing of the full payment journey across the card processor and the core banking system is scheduled closer to the release rather than in every iteration.
Correct. End-to-end testing is expensive to maintain and slow to run, so the syllabus places it closer to the release and on high-risk system integrations.
Exploratory testing is scheduled only after the iteration, because an increment has to be feature-complete before there is anything meaningful to explore.
Incorrect. Exploratory testing is one of the test types performed during the iteration, including on partial functionality and where acceptance criteria are still vague.
Non-functional testing is deferred to the period after the iteration, because only a release build placed on production-like infrastructure carries realistic load.
Incorrect. Non-functional aspects are addressed inside the iteration where the increment allows it; postponing all of them recreates the late-feedback problem the team left behind with quarterly releases.
The split follows from the test types themselves: functional testing belongs inside the iteration and every other test type belongs after it, independently of the product context.
Incorrect. The syllabus treats this as a context-dependent decision the team takes and revisits, not a fixed mapping from test type to phase.
Chapter 1.1 asks the team to decide, per test type, what can be covered inside the iteration and what has to wait, and to record that decision in the Definition of Done and the test approach. Functional and non-functional checks that can already be run against the increment belong inside the iteration; end-to-end testing across external systems is one of the activities typically placed closer to the release (1.2). The split is a context-dependent decision that is revisited, not a property of the test types themselves.
A food-delivery platform is built from 14 services. The order-placement journey crosses the customer app, the restaurant service, the courier dispatch service and an external payment provider. The team is deciding how much end-to-end testing the release should contain. Which consideration best reflects the syllabus guidance on when end-to-end testing should be performed?
Weigh the risk of the journey, the feedback time the end-to-end tests add, and the maturity of the CI/CD pipeline; where the pipeline already provides production feedback and feature toggles, fewer end-to-end tests are needed.
Correct. These are exactly the three factors the syllabus names for the inclusion of end-to-end testing.
Because the journey crosses an external payment provider, every alternative path through the four services should be covered by its own end-to-end test before the release.
Incorrect. Exhaustive end-to-end coverage maximises exactly the drawbacks the syllabus warns about: high maintenance cost, long execution and weak fault localisation.
Substitute consumer-driven contract tests for the end-to-end tests, since a contract test verifies each interaction between two services and therefore covers the integration risk of the journey.
Incorrect. Contract testing checks that a pair of services agrees on an interface; it does not exercise the behaviour of the whole user journey, so it reduces rather than removes the need for end-to-end tests.
Concentrate the end-to-end testing in a hardening iteration at the end of each release, because the syllabus identifies this as the recommended home for end-to-end testing.
Incorrect. Hardening iterations are named as a place where end-to-end testing does occur, but the syllabus adds that needing one may indicate insufficient attention to quality during the regular iterations — it is not a recommendation.
Decide by the number of services a journey crosses: journeys touching more than three services get end-to-end coverage and the remaining journeys are covered at component level only.
Incorrect. A fixed threshold on service count is not one of the syllabus factors and ignores both the risk of the journey and the maturity of the pipeline.
Section 1.2 names three factors for deciding whether to include end-to-end testing: the risk of the journey (impact and likelihood), the feedback time the tests add, and the maturity of the CI/CD pipeline — a mature pipeline offers production feedback, feature toggles and A/B testing as alternative sources of confidence. Contract testing and the test pyramid reduce the need for end-to-end tests but do not answer for the behaviour of the whole journey.
A mobile banking team keeps a formal testing approach for the transaction-limit component that is subject to external audit, and works in a holistic way on the new spending-insights screen. Which statement correctly compares the benefits and drawbacks of the two approaches?
Formal testing provides traceability, conformance evidence and repeatability but risks delayed feedback and low cognitive engagement; holistic testing brings different perspectives and earlier feedback but is difficult to measure and heavily context-dependent.
Correct. This pairs each approach with the benefits and drawbacks the syllabus lists for it.
Holistic testing provides the traceability and conformance evidence the auditor needs, while formal testing is the approach that supports First Time Right and continuous testing across the team.
Incorrect. The benefits are swapped: traceability and conformance are formal-testing benefits, while First Time Right and continuous testing are holistic-testing benefits.
The main drawback of formal testing is that it requires a culture change, while the main drawback of holistic testing is excessive rigidity in the way test cases are specified.
Incorrect. The drawbacks are swapped: culture change is listed under holistic testing and excessive rigidity under formal testing.
The two approaches yield the same benefits and the same coverage; they differ only in how thoroughly the test results and the test basis are documented afterwards.
Incorrect. The syllabus lists different benefits and different drawbacks for each, and treats the choice as a genuine trade-off rather than a documentation style.
The team has assigned the approaches the wrong way round: holistic testing suits the audited transaction-limit component and formal testing suits the exploration of the new spending-insights screen.
Incorrect. The syllabus points formal testing at critical components and regulatory demands, and holistic testing at early feedback on complex or new scenarios — which is the assignment the team already made.
Formal testing offers traceability, alignment, verification, conformance, repeatability and automatability, at the price of excessive rigidity, over-reliance on documented requirements, missing the unexpected, delayed feedback and low cognitive engagement. Holistic testing offers different perspectives, First Time Right and continuous testing, but is difficult to measure, requires a culture change and is heavily context-dependent. The two are complementary: formal for critical and regulated parts, holistic for early feedback on complex scenarios.
The food-delivery team has retired most of its nightly regression suite. A small smoke suite now acts as a quality gate in the pipeline, the new courier-pricing logic is released behind a feature toggle to 2% of couriers as a canary release, and dashboards on error rates and order-completion telemetry are watched for 24 hours before the toggle is widened. Which of the regression test approaches described in the syllabus is the team applying?
The DevOps-oriented regression test approach.
Correct. Smoke tests as quality gates, feature toggles, canary releases and observability instead of a broad regression suite are the defining elements of this approach.
The risk-based regression test approach.
Incorrect. A risk-based approach selects which regression tests to run from the risk of the affected areas; here the selection mechanism is the pipeline gate plus production observation, not a risk analysis of test cases.
The incremental regression test approach.
Incorrect. An incremental approach grows the regression set as functionality stabilises; this team has shrunk its suite and shifted confidence to production feedback.
The exploratory regression test approach.
Incorrect. An exploratory approach re-examines changed areas through human sessions; no sessions are described here.
The collaborative regression test approach.
Incorrect. The collaborative approach uses bug bashes and whole-team walkthroughs of the changed areas, none of which appear in this scenario.
Section 1.4 differentiates five regression test approaches. The DevOps-oriented approach relies on smoke tests as quality gates, feature toggles, canary releases and observability in place of a large regression suite — which is precisely what this team has built.
A museum's online ticket-booking team plans a two-week period after the last feature iteration of the release in which no new functionality is added and the team only stabilises what has been built. How does the syllabus characterise this practice?
It is a hardening iteration: a recognised place for end-to-end and release-level testing, although needing one may indicate that insufficient attention was paid to quality during the regular iterations.
Correct. This reproduces both the definition and the caveat the syllabus attaches to hardening iterations.
It is a hardening iteration, and the syllabus recommends scheduling one before every release so that regression testing and end-to-end testing have a dedicated, uninterrupted slot.
Incorrect. The term is right but the claim is not: the syllabus warns that the need for a hardening iteration is a signal of a quality problem in the regular iterations, rather than recommending one per release.
It is a bug bash: a timeboxed period in which the whole team, including non-testers, hunts for defects in the assembled product before it is shipped.
Incorrect. A bug bash is a collaborative defect-hunting session, listed among the collaborative regression approaches; it is not a two-week stabilisation period.
It is a dark launch: the release is deployed but kept invisible to visitors so that its behaviour can be observed under real traffic before it is announced.
Incorrect. A dark launch is a deployment technique for observing hidden functionality in production, not a stabilisation period in the development timeline.
It is a canary release: the new booking functionality is exposed to a small share of visitors first so that problems affect only part of the audience.
Incorrect. A canary release is a gradual production rollout; the scenario describes development time set aside for stabilisation with no new functionality.
This is a hardening iteration — a syllabus keyword of chapter 1. The syllabus recognises it as a place where end-to-end and release-level testing happens, while explicitly noting that the need for one may indicate insufficient attention to quality during the regular iterations.
A fintech company runs two teams on the same mobile banking product: one works on the audited payment engine, the other on a small experimental savings feature. Which two statements about generalization and specialization within a team are consistent with the syllabus? (Choose two.)
A generalizing, T-shaped tester reduces bottlenecks and helps the team hold a sustainable pace, while deep specialization stays valuable in areas such as test automation, exploratory testing and usability testing.
Correct. This is the T-shaped model the syllabus describes, together with the areas where specialization is explicitly retained.
The balance is set by context: an audited payment engine tends to justify keeping specialists, whereas a small experimental feature team tends to need people who can cover several disciplines.
Correct. The syllabus names regulated domains as favouring specialists and lean startup-like teams as favouring generalists.
Because the whole team owns quality, every member has to reach the same depth in every test discipline before the team can be considered genuinely cross-functional.
Incorrect. Shared ownership of quality does not mean uniform depth; the T-shaped model keeps one area of depth per person alongside broad working knowledge.
Silos are best dissolved by having each specialist produce a written knowledge-transfer document each iteration, rather than by pairing or mobbing, which occupies two people on one task.
Incorrect. The syllabus names knowledge sharing together with pairing and mob programming or mob testing as the mechanisms against silos; documents alone are not offered as a substitute.
Generalization implies that testers hand over the leadership of practices such as BDD, exploratory testing and test automation to a separate discipline outside the team.
Incorrect. The syllabus explicitly keeps testers in the driving seat for the adoption of BDD, exploratory testing and test automation within the team.
Section 2.1.1 describes the Agile tester as a generalizing, T-shaped specialist: generalization brings a sustainable pace, fewer bottlenecks, resilience and shared ownership, while deep specialization remains valuable in areas such as test techniques, exploratory testing, test automation and usability testing. The right balance is set by context — regulated domains lean towards specialists, lean product teams towards generalists. Silos are broken down through knowledge sharing, pairing and mobbing, and testers keep leading the adoption of practices such as BDD, exploratory testing and automation.
On the food-delivery platform, the restaurant-operations representative attends refinement but takes no part in any test activity. Which course of action best matches the syllabus examples for motivating business representatives to perform test activities?
Involve the representative early in writing acceptance criteria as concrete examples, and make the effect visible through dashboards of coverage, defect trends and quality risks alongside business metrics such as customer satisfaction and support costs.
Correct. Early collaboration on examples plus visibility of both quality and business metrics are the syllabus mechanisms for motivating business representatives.
Ask the representative to sign off the iteration test report at the end of every iteration, so that business involvement in testing is documented and auditable.
Incorrect. A sign-off at the end creates a formality, not participation, and gives the representative no influence on what is tested.
Give the representative a read-only account and a list of scripted test cases to execute in the last two days of the iteration, so their domain knowledge is used on real functionality.
Incorrect. Executing someone else's scripts late in the iteration is the opposite of the early, example-driven collaboration the syllabus describes, and it is not what motivates business participation.
Transfer ownership of the acceptance test suite to the representative so that the testers can concentrate on component and integration level testing.
Incorrect. Handing over a test suite shifts work rather than motivating participation, and it conflicts with the whole team approach to quality.
Report only the number of test cases executed and passed each iteration, since a single simple figure is the most effective message for a non-technical stakeholder.
Incorrect. The syllabus asks for visibility of coverage, defect trends, quality risks and business metrics; an execution count carries no information the representative can act on.
Section 2.1.2 lists: involving business representatives early in acceptance criteria, using ATDD, BDD and specification by example, discussing testability at backlog refinement, giving visibility through dashboards of coverage, defect trends and quality-risk metrics, connecting testing to business metrics such as customer satisfaction, support costs and feature adoption, and inviting them into bug bashes and usability testing.
In an HR-onboarding SaaS team the developers say they get useful test feedback only in the last two days of the iteration. Which set of actions best summarises how the whole team approach can assist the development team, as described in the syllabus?
Turn the acceptance criteria into concrete examples before coding starts, coach the developers on component and component integration tests so that refactoring stays safe, and join code reviews while developers take part in exploratory sessions.
Correct. These are the supporting activities the syllabus lists for testers within the whole team approach.
Take over writing the component tests so that the developers can spend their whole capacity on production code, and report the resulting coverage figure at the iteration review.
Incorrect. The syllabus has testers coaching developers on component-level testing, not owning it; taking it over removes the fast feedback developers get from their own tests.
Review the developers' code only once the increment is complete, so that the tester's view stays independent of the implementation decisions that were taken.
Incorrect. Deferring review to the end reproduces the late-feedback problem described in the scenario; independence of that kind is not what this chapter asks for.
Limit the tester's contribution to finding and reporting defects, so that responsibility for the product's quality stays unambiguously with the people who write the code.
Incorrect. This contradicts the whole team approach, in which quality is a shared responsibility and testers act as facilitators and collaborators.
Wait for a build that passes the full pipeline before giving any feedback, so that the feedback is based on complete, integrated functionality rather than on work in progress.
Incorrect. Feedback on work in progress — examples, questions, pairing — is exactly what the syllabus asks testers to give the developers.
Section 2.1.3 describes testers giving early feedback through ATDD and BDD, supplying concrete examples instead of specification text, coaching developers on component and component integration tests so that refactoring stays safe, joining code reviews while developers join exploratory sessions, using production analytics, and involving operations and security early.
A museum's booking team has designed a new interactive seat-selection map and wants fresh-eyes feedback before it invests in the implementation. How should the team use tissue testers according to the syllabus?
Invite someone from outside the team to try the design early, before expensive implementation, explain as little as possible beforehand, and do not use that same person again once they have seen the design.
Correct. Early use, minimal briefing and single use per person are the three defining rules the syllabus gives for tissue testers.
Invite the same external person at the start of the design work and again at the end of the iteration, so that the two rounds of feedback can be compared and progress can be measured.
Incorrect. This breaks the central rule: once the person has seen the design they are biased, so a second round no longer delivers fresh eyes.
Brief the external person thoroughly on the visitor personas, the seat categories and the pricing rules first, so that their feedback is well informed and actionable.
Incorrect. The syllabus advises against explaining much to tissue testers; the briefing itself removes the naive perspective that makes them useful.
Use the tissue testers in place of the team's own structured testing of the seat-selection rules, since fresh eyes reliably surface more problems than scripted work.
Incorrect. The syllabus states explicitly that tissue testers do not replace structured testing; they complement it.
Recruit tissue testers only after the seat map has been released, because their value lies in reporting how real visitors behave under production conditions.
Incorrect. Their value is greatest early, before costly investment; production behaviour is observed through monitoring and analytics instead.
Section 2.2 describes tissue testers as temporary fresh-eyes testers from outside the team, most valuable early in design before expensive investment, given little explanation, and — the key rule — not reused once they have seen the design, because they can no longer be unbiased. They suit exploratory and usability work and checking assumptions, and do not replace structured testing.
Which description matches the keyword "tissue tester" as it is used in the syllabus?
A temporary tester from outside the team, used once for fast informal feedback with an unbiased perspective, a practice typical of volatile sectors such as the video game industry.
Correct. This matches the syllabus definition, including the single use and the sector example.
A team member who moves to a different team every iteration so that test knowledge is spread across the organisation and no single team owns a practice.
Incorrect. That describes role rotation and communities of practice, which the syllabus discusses as improvement measures, not tissue testers.
An external tester engaged under contract to execute the formal acceptance test suite before a release so that the sign-off is performed by an outside party.
Incorrect. Tissue testers give informal early feedback; they do not execute a formal acceptance suite.
A tester who works only on throwaway prototypes that are never intended to reach production, so that the effort spent on their test cases can be discarded.
Incorrect. The word refers to the disposable nature of the tester's involvement, not of the product under test; tissue testers examine real designs and products.
A business representative who exercises the product during the iteration review so that acceptance decisions are taken with the whole team present.
Incorrect. That is business representative participation described in 2.1.2; a tissue tester comes from outside the team and its stakeholders.
A tissue tester is a temporary, fresh-eyes tester brought in from outside the team for fast informal feedback and used only once, a practice the syllabus associates with volatile sectors such as the video game industry.
The mobile banking team plans testing at two levels. Which of the following activities belongs to release-level test planning rather than to iteration-level test planning?
Assessing the quality risks of the whole release, mapping the dependencies and integration points with the external card processor, and defining a release-level test strategy that distributes functional and non-functional testing across the iterations.
Correct. Release-wide quality risks, dependencies and integration points and a release-level test strategy are release planning activities in 3.1.1.
Breaking the next backlog items down into high-level test conditions and refining their acceptance criteria with the product owner so that the items become testable inside the coming two weeks.
Incorrect. Deriving high-level test conditions and refining acceptance criteria for the selected items is iteration-level planning.
Confirming that the test environments and the masked account test data needed by the selected items are available and correctly configured for the coming two weeks of work.
Incorrect. This is iteration readiness of environments and test data, an iteration planning activity.
Agreeing the team's Definition of Done so that it can serve as the exit criteria applied to each individual backlog item before that item is considered complete.
Incorrect. The team Definition of Done used as exit criteria per story is listed under iteration planning; the release-level Definition of Done is the release counterpart.
Running a risk-storming session, moderated by the tester, on the items that the team has just selected for the upcoming iteration so that risks are visible from day one.
Incorrect. Risk-storming on the selected items with the tester as moderator is an iteration planning activity in 3.1.1.
Section 3.1.1 separates iteration planning (backlog items, risk-storming, high-level test conditions, refining acceptance criteria, choosing types and techniques, iteration readiness of environments and data, Definition of Done as exit criteria per item) from release planning (business goals, scope and backlog order, quality risks for the whole release, dependencies and integration points, effort estimation, a release-level test strategy, release-level Definition of Done and release readiness assessments).
The food-delivery team wants to set up test monitoring and test control for its two-week iterations. Which approach matches the syllabus?
Monitor with burn-down charts, cumulative flow diagrams and dashboards showing trends in defect discovery, automated test coverage, exploratory findings and production monitoring data, and exercise control as a whole team in the stand-up, the iteration review and the retrospective.
Correct. This is the trend-based monitoring and whole-team control described in 3.2.
Measure progress mainly as the deviation between the number of test cases executed and the number planned, and escalate any deviation beyond ten per cent to the test manager for a decision.
Incorrect. The syllabus moves monitoring away from conformance to a plan and towards trends and empirical signals from the product.
Split the responsibilities so that the tester performs the monitoring and the team lead performs the control, keeping the observation of the process independent from the decisions taken on it.
Incorrect. Control in Agile development is a whole-team activity in this syllabus, not a responsibility separated from monitoring and assigned to a lead.
Take control actions only at the iteration boundary, so that the team is never disturbed mid-iteration and the effect of each change can be attributed to a single iteration.
Incorrect. Control triggers such as automated test feedback and production monitoring signals arrive continuously and are acted on in the daily stand-up.
Base control decisions on the trend in code coverage alone, since it is the only objective and continuously available signal the team can obtain inside a short iteration.
Incorrect. The syllabus warns against treating code coverage as a proxy for quality and asks for several complementary signals.
Section 3.2 bases monitoring on burn-down charts, cumulative flow diagrams and automated dashboards, and on trends — defect discovery, automated test coverage, exploratory findings and production monitoring data — rather than on conformance to a plan. Control happens in daily stand-ups, iteration reviews and retrospectives and is exercised by the whole team, with triggers coming from automated test feedback, production monitoring signals and customer feedback loops.
The HR-onboarding SaaS team is designing its test reporting and wants to use the coverage types the syllabus compares. Which two statements are correct? (Choose two.)
Exploratory coverage is reported through session-based test management artefacts, for example session sheets and test charter completion rates.
Correct. Session-based test management and charter completion rates are the reporting mechanism the syllabus names for exploratory coverage.
Code coverage is reported with care and complemented by measures such as fault seeding or assertion quality reviews, because on its own it is not a proxy for quality.
Correct. The syllabus explicitly cautions against code coverage as a quality proxy and names these complements.
Requirements coverage cannot be reported in Agile development, because user stories are not formal requirements and therefore offer no traceable units.
Incorrect. Acceptance criteria act as the traceable units for requirements coverage, established through ATDD and BDD.
Infrastructure and environment coverage is reported as the share of the test cases that were executed directly on the production environment during the iteration.
Incorrect. This coverage type concerns the configurations and environments exercised, reported as operational coverage through observability, not the share of tests run in production.
Once requirements, code, exploratory and environment coverage are all reported, the team can combine them into a single overall coverage figure for the release.
Incorrect. The syllabus warns teams to resist the illusion of completeness created by metrics; the four coverage types answer different questions and do not aggregate.
Section 3.3 compares four coverage types for reporting: requirements coverage (with acceptance criteria as traceable units through ATDD and BDD), code coverage (to be used with care and complemented by fault seeding or assertion quality reviews), exploratory coverage (through session-based test management and test charter completion rates) and infrastructure and environment coverage (operational coverage obtained through observability). The syllabus warns teams to resist the illusion of completeness created by metrics.
The museum booking team wants to improve its test process. Which approach is consistent with the way the syllabus describes test process improvement in Agile software development?
Hold focused, test-specific retrospectives, establish a baseline through an Agile test assessment, and treat each improvement as a hypothesis that a small experiment either supports or refutes.
Correct. Focused retrospectives, baseline assessment, small experiments and the hypothesis framing are all named in 3.4.2.
Publish a table comparing the museum team's test metrics with those of the two other product teams each month, so that improvement pressure comes from the comparison itself.
Incorrect. The syllabus asks for careful use of visible metrics explicitly without benchmarking between teams, because comparison drives local optimization rather than improvement.
Delegate improvement to a central quality department that defines one standard test process and rolls it out unchanged to every product team in the organisation.
Incorrect. Improvement in this chapter is team-driven and context-dependent; a uniform imposed process ignores the sociotechnical factors the syllabus stresses.
Postpone any improvement action until the team's metrics have stayed stable for at least three releases, so that the baseline the team measures against is beyond dispute.
Incorrect. Improvement proceeds through small experiments with the data available; waiting for a perfect baseline delays the feedback loop the chapter is built on.
Introduce all of the improvement approaches at once in the next iteration, so that their combined effect on the team's defect and coverage metrics becomes visible sooner.
Incorrect. Simultaneous changes make it impossible to tell which hypothesis held, which is why the syllabus asks for small, separately validated experiments.
Section 3.4.2 names focused, test-specific retrospectives, a baseline assessment through Agile test assessments and self-assessments, joint risk workshops, strengthening CI/CD feedback loops, small experiments, and careful use of visible metrics without benchmarking between teams. Every improvement is treated as a hypothesis to be validated.
A team wants a structured way to derive its test metrics so that every metric answers a defined question and every question serves a stated goal. Which approach named in the syllabus serves exactly this purpose?
Goal-Question-Metric.
Correct. GQM derives metrics from questions that in turn serve explicitly stated goals, which is precisely the requirement described.
Value Stream Mapping.
Incorrect. Value Stream Mapping visualises the flow of work and its waste and delays; it does not derive metrics from goals.
The Plan-Do-Check-Act cycle.
Incorrect. PDCA structures the improvement cycle itself; it says nothing about how the metrics used inside it are chosen.
Causal loop diagrams.
Incorrect. Causal loop diagrams model reinforcing and balancing relationships between factors; they are an analysis aid, not a metric-derivation model.
Cumulative flow diagrams.
Incorrect. A cumulative flow diagram is a monitoring chart showing work in each state over time; it is one possible metric, not a way of deriving metrics.
Goal-Question-Metric is the model the syllabus names for deriving metrics from goals via questions. Value Stream Mapping, PDCA and causal loop diagrams are also named in chapter 3, but they serve different purposes: mapping flow and waste, structuring improvement cycles, and modelling feedback relationships respectively.
A mobile banking team is outlining the project test strategy for the next release using the testing quadrants. The context is as follows. The payment domain is business-critical and subject to an external anti-money-laundering (AML) audit that requires demonstrable coverage of 29 transaction-limit rules. Leadership has a low risk appetite for regulatory findings. The team works in two-week iterations on a mature CI/CD pipeline that returns build feedback in six minutes and supports feature toggles. Production observability exists but the dashboards are reviewed only once a week, and the compliance representative has never taken part in a test session. The diagram shows how the team's tests are distributed over the four quadrants today.
Which two elements should the outlined project test strategy add, given these context factors? (Choose two.)
Extend Q2 with decision table, state transition and boundary value tests so that the remaining 17 of the 29 transaction-limit rules are covered, because a business-critical regulated domain combined with a low risk appetite calls for repeatable and traceable coverage of the rules.
Correct. Domain criticality and risk appetite are two of the eight context factors, and the syllabus names exactly these techniques for regulated environments in Q2.
Strengthen Q3 by scheduling exploratory and usability sessions on the payment flow with the compliance representative taking part, because Q3 is where the product is critiqued from a business perspective and it is currently the thinnest quadrant.
Correct. Q3 is business-facing critique of the product; with no usability review and no business participation it is the gap the context factors on team composition and customer feedback point to.
Reclassify the 1 840 component tests into Q2, because they cover the code that implements the business rules and everything that verifies business rules belongs on the business-facing side of the quadrants.
Incorrect. The quadrant axes classify the perspective of the test, not the rules it happens to touch; component tests written from a technical perspective to guide development stay in Q1.
Reduce the Q1 automation, because a six-minute feedback time shows that the component suite has grown larger than the project test strategy needs and its maintenance now competes with new coverage.
Incorrect. Six-minute feedback is evidence that tooling and infrastructure maturity are working in the team's favour; the syllabus treats fast Q1 feedback as a strength, and nothing in the context indicates over-investment.
Add nightly end-to-end runs of every user journey to Q4, because Q4 covers technology-facing critique of the product and end-to-end journeys are the most technical form of critique available.
Incorrect. Q4 concerns qualities such as performance, reliability and security; broad nightly end-to-end runs also contradict the guidance in 1.2 on limiting end-to-end testing where the pipeline already gives fast feedback.
Section 3.1.2 asks for a project test strategy outlined against eight context factors. Here domain complexity and business criticality plus a low risk appetite and a regulated environment point to strengthening Q2 with the techniques the syllabus names for regulatory demands — boundary value analysis, state transition testing and decision table testing — so that the remaining 17 of the 29 AML rules obtain repeatable, traceable coverage. Q3 is the weakest quadrant: no usability review of the payment flow and no business participation, even though Q3 is where the product is critiqued from a business perspective and where the customer feedback and observability factors ask for human judgement. The quadrant axes are business-facing versus technology-facing and guide development versus critique product, so component tests cannot be moved to Q2, and a short feedback time in Q1 is a benefit rather than a signal to reduce automation.
The food-delivery team reviews six iterations of measurements before its improvement workshop. The defect detection percentage has fallen from 88% to 61%, the number of defects escaping to production has risen from 2 to 11 per iteration, the number of flaky test reruns has risen from 4 to 31, and the mean time to repair a reported defect has grown from 3.1 to 7.4 days. The iteration 17 burn-down shows that testing of seven backlog items was still open on the last day of the iteration. The test environments have been stable throughout, and the pipeline runs the full suite in eleven minutes.
Which set of test process improvement measures best matches these metrics?
Run root cause analysis on the escaped defects and rework the test chartering with session-based test management; measure test maintenance effort and test execution lead times and rotate test ownership to address the growing test debt and flaky tests; and introduce whole-team defect triage with testers joining refinement earlier to shorten the repair cycle.
Correct. Each measure is matched to the signal the syllabus associates it with: falling detection percentage to root cause analysis and chartering, flaky tests and test debt to maintenance measurement and ownership rotation, and long defect cycle time to whole-team triage and earlier tester involvement.
Introduce service virtualization and containerized test environments, because a falling defect detection percentage over six iterations is the classic indicator that unstable environments are preventing tests from finding defects.
Incorrect. These are the measures the syllabus attaches to environment instability, and the scenario states that the environments have been stable throughout, so the signal for them is absent.
Adopt smart test selection in the pipeline, because the rise from 4 to 31 flaky reruns shows the suite has grown too large to be executed in full on every change and needs to be filtered by impact analysis.
Incorrect. Smart test selection answers long feedback and lead times; the pipeline already runs the full suite in eleven minutes, and selection would hide the flaky tests rather than address them.
Set a team target of a 90% defect detection percentage per iteration and display it prominently on the team dashboard, because a visible target reverses a declining trend faster than any process change.
Incorrect. The syllabus treats metrics as a feedback mechanism rather than a goal and warns against exactly this local optimization, in which the number improves without the underlying process changing.
Rebalance the automation towards more end-to-end tests, because the defects that now escape to production cross several services and only full journey tests can catch them before release.
Incorrect. Where coverage of critical paths is weak the syllabus points to strengthening component and component integration testing and rebalancing the test pyramid, not to adding end-to-end tests whose drawbacks are described in 1.2.
Raise the number of exploratory sessions from two to eight per iteration and move the seven unfinished items to the next iteration, because the burn-down shows that testing is the bottleneck in the iteration.
Incorrect. This reacts to the symptom without any root cause analysis, and it leaves the flaky tests, the test debt and the seven-day repair cycle untouched.
Section 3.4.1 pairs signals with measures. A falling defect detection percentage together with rising escapes points to root cause analysis and reworked test chartering with session-based test management. Rising flaky reruns and growing maintenance point to test debt: measure maintenance effort and test execution lead times and rotate test ownership. A long cycle time on defects points to whole-team defect triage, testers joining refinement earlier and linking MTTF and MTTR to retrospectives. Environment measures such as service virtualization and containerized environments answer environment instability, which the data explicitly rules out here, and smart test selection answers long feedback times, which eleven minutes does not indicate. Making a metric a team target is the local optimization the syllabus warns against.
In an HR-onboarding SaaS product, which situation is an example of testware being used as a form of requirements?
The BDD scenarios and acceptance-level test cases for the "invite a new hire" story are maintained as the authoritative description of the expected behaviour, and the team consults them instead of a separate specification document.
Correct. Testware maintained as the living description of what the system must do is exactly the executable specification idea in 4.1.1.
The team keeps its test cases in the same repository as the production code so that a change to the behaviour and a change to its tests are always released as one versioned unit.
Incorrect. This is configuration management of testware; it does not make the testware serve as the requirement.
The team writes an iteration test plan that lists which user stories will be covered by which test cases, so that every story can be traced to at least one test.
Incorrect. That is traceability from requirements to tests — the requirement still lives outside the testware.
The team reports requirements coverage each iteration as the percentage of acceptance criteria that have at least one automated test attached to them.
Incorrect. This is test reporting on requirements coverage, described in 3.3, not testware acting as a requirement.
The team archives the executed test results together with screenshots so that the evidence is available for the annual data-protection audit of the onboarding process.
Incorrect. Archived results are records of past execution; they describe what happened, not what the system must do.
Section 4.1.1 describes testware — user stories with acceptance criteria, checklists, BDD scenarios, acceptance-level test cases, examples, test charters, contracts and automated scripts — acting as living requirements, and ATDD, BDD and specification by example producing executable specifications. Versioning, traceability reporting and archiving results are useful practices but they are not testware taking the place of a specification.
The museum booking team wants to use storyboarding and testboarding to raise the quality of its test basis for a new "buy a family ticket" journey. Which statement describes the two techniques correctly?
Storyboarding visualises the visitor's journey scene by scene and exposes problems of usability, transitions and personas, while testboarding visualises what will be tested — main and alternative scenarios, shared terminology and priorities — and improves the maintainability of the test cases.
Correct. This matches the purpose the syllabus gives to each of the two techniques.
Storyboarding visualises the test scenarios and their priorities, while testboarding visualises the visitor's journey through the booking flow so that persona and transition problems become visible to the whole team.
Incorrect. The two purposes are swapped: the journey belongs to storyboarding and the test scenarios to testboarding.
Both techniques are applied once, at the start of the release, in order to produce a specification of the journey that is signed off before the first iteration begins.
Incorrect. The syllabus applies both iteratively during backlog refinement and iteration planning, and treats their output as living documentation rather than a signed-off specification.
Testboarding takes the place of the acceptance criteria of a user story, because the board shows the same information in a visual form that the whole team can read more quickly.
Incorrect. Testboarding complements the acceptance criteria by visualising what will be tested; the criteria remain the agreed statement of expected behaviour.
Storyboarding is applied to features that are already released, so that the journey can be documented for the support staff who answer visitor questions about the booking flow.
Incorrect. Storyboarding is a shift-left technique used before and during development to improve the test basis, not a post-release documentation exercise.
Section 4.1.2 has storyboarding visualising the user journey scene by scene, revealing problems in usability, transitions and personas, and testboarding visualising what will be tested — main and alternative scenarios, shared terminology and priorities — which raises the maintainability of the test cases. Both are applied iteratively at backlog refinement and iteration planning, serve as living documentation and help detect requirements drift.
The food-delivery team runs an example mapping session on the story "apply a promotion code at checkout". Which two statements about example mapping are correct? (Choose two.)
A yellow card carries the user story, blue cards carry the business rules, green cards carry the examples that later become test cases, and red cards carry the questions that remain open.
Correct. This is the card colour scheme the syllabus specifies for example mapping.
The conversation continues until the scope of the story is clear or until the timebox for the session runs out, whichever happens first.
Correct. The syllabus gives both stopping conditions: clarity of scope or the end of the timebox.
Every red card has to be resolved before the end of the same session, because an unanswered question makes the resulting examples invalid as a test basis.
Incorrect. Red cards are allowed to remain open; a large number of them is treated as information — a signal that much is still unknown about the story.
The green cards are written by the tester after the session, so that the business representative and the developers are not slowed down by discussing concrete data during the conversation.
Incorrect. Example mapping is a structured conversation in which the examples are produced collaboratively; writing them afterwards removes the shared understanding that is the point of the technique.
The number of blue cards should match the number of acceptance criteria already written for the story, otherwise the acceptance criteria have to be rewritten before the session can conclude.
Incorrect. No such correspondence is required; the number of blue cards is instead read as a signal about the size of the story.
Section 4.1.3 describes example mapping as a structured conversation with coloured cards: yellow for the user story, blue for the business rules, green for the examples that later become test cases, and red for the open questions. The conversation continues until the scope is clear or the timebox ends. Many red cards indicate that much is still unknown; many blue cards, or one rule carrying many green cards, indicate that the story is too large and needs slicing.
An example mapping session on the HR-onboarding story "a manager approves an onboarding checklist" ends with 1 yellow card, 7 blue cards and 19 green cards, one single business rule carrying 11 of those green cards. Only 2 red cards are left open. What does this pattern indicate according to the syllabus?
The story is too large and should be sliced, because a story with many business rules, or a single rule carrying many examples, is the syllabus signal for user story slicing.
Correct. Both patterns present here — seven rules and one rule with eleven examples — are the size signals the syllabus names.
The story is well understood and ready to be taken into the iteration, because only two questions were left unanswered at the end of the session.
Incorrect. Few red cards indicate that little is unknown, but the volume of rules and examples still shows the story is too big to be tested in one piece.
The examples are largely redundant and should be reduced until each business rule carries at most two, so that the resulting set of test cases stays economical to maintain.
Incorrect. The syllabus does not cap examples per rule; a rule with many examples is a signal to slice the story, not to discard examples.
The seven blue cards show that the acceptance criteria of the story are ambiguous, so the session should be repeated with a different facilitator and a rewritten story.
Incorrect. Business rules discovered during the conversation are the expected output of example mapping; their number indicates size, not ambiguity.
The low number of red cards shows the session was too short and that the participants should have been pushed to raise more open questions before stopping.
Incorrect. The session ends when the scope is clear or the timebox expires; a small number of open questions is a good outcome, not a defect in the session.
Section 4.1.3 reads the card pattern as a signal: many blue cards, or a single business rule carrying a large number of green cards, means the story is too large and should be sliced, which leads into user story slicing in 4.1.5. Few red cards say only that little is still unknown; they say nothing about the size of the story.
During refinement of a "split a bill" feature in the mobile banking product, the team agrees within minutes on the happy path. The first figure mentioned by the most senior developer frames the rest of the discussion, nobody contradicts it, and accessibility and internationalization of the amount fields are never raised. Which biases does the syllabus name for this situation, and what does it say about the whole team approach?
The anchoring effect and conformity bias; the syllabus states that the risk of bias is increased by the whole team approach and recommends countermeasures such as diversity of thought, psychological safety, paired testing and tissue testers.
Correct. The framing figure is the anchoring effect and the immediate agreement is conformity bias, and the syllabus does say the whole team approach increases the risk of bias.
Confirmation bias only; the whole team approach reduces the risk of bias, because a larger number of perspectives is present in the room during refinement.
Incorrect. The syllabus states the opposite: the whole team approach increases the risk of bias, since shared assumptions go unchallenged.
The anchoring effect only; bias in estimating and framing is a project-management concern and lies outside the scope of the team's test activities.
Incorrect. Bias is treated as a product-quality concern in this chapter, and the situation also shows conformity bias.
Conformity bias only, and the recommended countermeasure is to replace the refinement conversation with individual written reviews so that nobody is influenced by anyone else.
Incorrect. The anchoring effect is present as well, and the countermeasures the syllabus names keep the collaboration while adding diversity of thought, psychological safety and pairing.
No bias is at work here: fast agreement on the happy path is evidence of a shared understanding of the story, which is the goal of refinement.
Incorrect. Fast agreement is exactly the symptom the syllabus warns about, and the missing accessibility and internationalization concerns show the cost.
Section 4.1.4 names confirmation bias, the anchoring effect — with happy-path stories underestimating edge cases, accessibility and internationalization — and conformity bias, and states explicitly that the risk of bias is increased by the whole team approach. Countermeasures include diversity of thought, session-based exploratory testing, psychological safety, debriefs, paired testing, tissue testers and root cause analysis.
How does requirements engineering support shift left according to the syllabus?
It contributes elicitation, analysis, specification and validation; validation checks that requirements are correct, unambiguous, complete, consistent and testable, which moves defect detection into the test basis before code exists.
Correct. These are the four activities and the five validation criteria the syllabus lists.
It contributes elicitation, estimation, prioritisation and sign-off; shift left is achieved by approving the requirements earlier in the release so that development starts from an agreed baseline.
Incorrect. Estimation, prioritisation and sign-off are not the requirements engineering activities named here, and shift left is about earlier quality feedback rather than earlier approval.
It requires that requirements be specified semi-formally, so user stories should be replaced by state transition diagrams and business process models before the team starts development.
Incorrect. The syllabus lists free-form, semi-formal and glossary-supported specification as alternatives suited to different contexts, and does not require replacing user stories.
The validation criteria are that requirements be correct, complete and formally approved; testability is assessed later, at the point where the test cases are designed from them.
Incorrect. Testability is one of the five validation criteria applied during requirements validation, which is precisely what makes the shift left possible.
It supports shift left mainly by producing a glossary, since inconsistent terminology is the most frequent cause of requirements defects in Agile teams.
Incorrect. A glossary is one aid mentioned under specification; the support for shift left comes from the whole set of activities, above all validation.
Section 4.2 names four requirements engineering activities — elicitation, analysis, specification and validation — and five validation criteria: correct, unambiguous, complete, consistent and testable. Specification may be free-form (user stories, epics), semi-formal (use cases, business process models such as BPMN, state transition diagrams) or supported by glossaries; no single form is mandated.
Which statement about shift left and the test basis matches the way the syllabus uses these keywords?
Shift left moves test activities earlier so that defects in the test basis are found before the code is written, and testware such as examples, checklists and BDD scenarios can itself become part of that test basis.
Correct. This combines the purpose of shift left with the testware-as-requirements idea from 4.1.1.
Shift left means executing the existing regression suite earlier in the pipeline, on every commit instead of nightly, so that failures are reported to the developer who caused them.
Incorrect. That is continuous integration practice; shift left in this chapter is about test activities on the test basis before code exists.
Shift left means placing the testers earlier in the reporting structure, so that they report to the requirements engineers and can influence the specification before it is handed over.
Incorrect. Shift left concerns the timing of activities, not the organisational reporting line.
The test basis consists of the approved requirements documents; user stories, acceptance criteria and examples are working material and are not counted as part of it.
Incorrect. In Agile development the user stories, acceptance criteria and examples are the test basis the team works from.
Shift left applies to functional testing; non-functional aspects can only be addressed once a running system exists, so they stay on the right-hand side of the lifecycle.
Incorrect. Non-functional expectations can be elicited, specified and validated in the test basis just as functional ones can, and doing so is part of shift left.
Shift left moves test activities earlier so that defects in the test basis are found before code is written. The test basis in Agile development includes user stories, acceptance criteria, examples, checklists and other testware, and testware itself can become part of the test basis (4.1.1). Running the existing regression suite earlier in the pipeline is continuous integration, not the shift left this chapter describes.
The food-delivery team carries the story "As a customer I want to schedule an order for a later time so that my food arrives when I am home." Its six acceptance criteria cover: choosing a delivery window; validating the window against the restaurant's opening hours; handling restaurants that publish irregular hours per weekday; recalculating the courier assignment 45 minutes before the window; notifying the customer if the restaurant later closes the window; and applying a scheduling fee that differs across three subscription tiers. In refinement the team concludes that the story cannot be made testable inside one iteration and decides to slice it along the workflow dimension and the data-complexity dimension. Which slicing follows the syllabus guidance?
First slice: scheduling a window at a restaurant whose opening hours are identical every day, with no scheduling fee — the simplest path end to end. Later slices add the irregular weekday hours and then the three fee tiers, and each slice gets its own rewritten acceptance criteria describing one narrow user outcome.
Correct. This combines a workflow slice (simplest path first) with data-complexity slices (harder data variants later) and rewrites the acceptance criteria per slice, as the syllabus requires.
Copy all six acceptance criteria into each slice and mark in every slice which of them are in scope for that slice, so that the link back to the original story stays visible to the auditor and the product owner.
Incorrect. The syllabus states that the original acceptance criteria must not be copy-pasted into the slices; each slice needs criteria rewritten for its own narrow outcome.
Slice by layer of the system: one slice for the scheduling table and its migrations, one for the scheduling service, and one for the app screen; the workflow is then covered by the sum of the three slices.
Incorrect. A horizontal split by layer produces slices that deliver no user-visible outcome and cannot be tested independently, which contradicts testability as the primary slicing criterion.
Slice by test level: one slice covering the component tests of the scheduling logic and one slice covering the acceptance tests of the window picker, so that each slice has a clear owner and a clear test level.
Incorrect. Slices are narrow user outcomes, not packages of test work; test levels are chosen inside a slice, not used to define slices.
Keep the story whole but reduce its acceptance criteria to the simplest path only, and raise the removed criteria as defects once the feature is in production and real scheduling behaviour can be observed.
Incorrect. Dropping criteria instead of slicing means the slices no longer cover the original story, and planning to discover known behaviour as production defects contradicts the defect-prevention focus of the syllabus.
Section 4.1.5 names workflow, data complexity, interface, scenario, vertical slicing and constraints as slicing dimensions. A workflow slice takes the simplest end-to-end path first; a data-complexity slice adds the harder data variants afterwards. Acceptance criteria must be rewritten for each slice and never copy-pasted from the original, each slice must deliver one narrow user outcome, and the slices together must cover the original story. Testability is the primary criterion, which is why splitting by layer or by test level does not qualify.
The mobile banking team carries the story "As a customer I want to set up a standing order so that a fixed amount leaves my account regularly." Its acceptance criteria cover four frequencies (weekly, monthly, quarterly, annually), creation from the app, editing and cancelling an existing standing order, a confirmation notification, and a ledger entry that the audit trail can reconcile. The team wants to slice this story along the interface dimension and to make the first slice a vertical slice. Which slicing follows the syllabus guidance?
Slice 1 delivers the creation of a monthly standing order through the API only, as a thin path from the ledger entry through the service to a minimal confirmation response, with its own rewritten acceptance criteria; the app screen, the other three frequencies and the editing and cancelling behaviour follow in later slices.
Correct. Backend before user interface is the interface dimension, and a thin path through all layers for one narrow outcome is a vertical slice; the criteria are rewritten for the slice.
Slice 1 delivers the app screen for all four frequencies against a stubbed backend so that the business representative can see visible progress at the next iteration review, and the service and ledger arrive in slice 2.
Incorrect. The interface dimension puts the backend before the user interface, and a stubbed slice delivers no working user outcome that could be tested on its own.
Slice 1 covers the ledger schema change, slice 2 the standing-order service, slice 3 the app screen, and every slice keeps the original acceptance criteria so that nothing is lost between the slices.
Incorrect. This is a horizontal split by layer, and it also copy-pastes the original acceptance criteria — both explicitly rejected in 4.1.5.
Slice 1 delivers the API and the app screen for all four frequencies together, because a vertical slice has to contain every acceptance criterion of the original story in order to remain a complete, releasable increment.
Incorrect. A vertical slice is thin: it crosses all layers for one narrow outcome. Requiring all criteria in the first slice simply reproduces the original untestable story.
Slice the story by quality aspect: slice 1 for the functional behaviour, slice 2 for the performance of the scheduled execution, and slice 3 for the authorisation rules around editing an existing standing order.
Incorrect. Quality aspect is not one of the slicing dimensions, and slices 2 and 3 would not deliver an independent user outcome; non-functional expectations belong inside the acceptance criteria of a slice.
In the interface dimension the syllabus slices backend before user interface, delivering the capability through the API first. A vertical slice is a thin path through all layers — here from the ledger entry through the service to a minimal response — so that the slice is demonstrable and testable on its own. Acceptance criteria are rewritten for the slice, and the remaining frequencies, the app screen and the editing behaviour follow in later slices.
What is a test smell according to the syllabus?
A symptom of a poorly designed test; it is not necessarily a problem in itself, but it signals risk and a rising cost of maintaining the test.
Correct. This is the definition the syllabus gives, together with the caveat that a smell is a signal rather than a defect.
A test whose result changes between two runs on an unchanged product, so that its verdict cannot be trusted without a rerun.
Incorrect. That describes a flaky test. Flakiness is discussed in 3.4.1 as a metric signal; it is one possible consequence of a smell, not the definition of one.
A test that exercises functionality that has been removed from the product, so that it can no longer fail for a meaningful reason.
Incorrect. That is an obsolete test. A smell concerns the design of the test, independently of whether the functionality still exists.
A defect found in the test environment or the test data rather than in the product itself, which therefore does not count towards the product's defect metrics.
Incorrect. Environment and data problems are a different concern; a test smell is a property of the way the test case is written.
A test case that a static analysis tool has flagged for breaking the team's naming or formatting conventions in the test management tool.
Incorrect. Formatting and language smells do exist as one of the seven categories, but a smell is defined by what it signals about the test's design, not by a tool's convention check.
A test smell is a symptom of a poorly designed test. By analogy with code smells it is not necessarily a defect in itself, but it signals risk and rising maintenance cost. The syllabus describes smells in manual test cases and groups them into seven categories.
Which list corresponds to the five categories of test heuristics described in the syllabus?
Guidelines; generic checklists; rules of thumb; mnemonics; analogies and metaphors.
Correct. These are the five categories the syllabus names.
Guidelines; test case templates; test conditions; mnemonics; test oracles.
Incorrect. Templates, test conditions and test oracles are testing concepts from other chapters, not categories of heuristic.
Generic checklists; test charters; tours; mnemonics; user personas.
Incorrect. Charters and tours are exploratory testing instruments described in 5.1.3 and 5.1.4, not heuristic categories.
Rules of thumb; decision tables; state models; mnemonics; equivalence classes.
Incorrect. Decision tables, state models and equivalence classes are black-box test techniques rather than heuristics.
Guidelines; standards; regulations; generic checklists; quality metrics.
Incorrect. Standards, regulations and metrics may inform testing, but they are not the heuristic categories listed in 5.1.1.
Section 5.1.1 groups test heuristics into guidelines; generic checklists (including usability heuristics, the OWASP Top 10, Beizer's taxonomy and IEEE 1044); rules of thumb; mnemonics; and analogies and metaphors.
A tester on the museum booking product is choosing test mnemonics for the coming iteration. Which two statements about the mnemonics named in the syllabus are correct? (Choose two.)
SFDIPOT stands for Structure, Function, Data, Interfaces, Platform, Operations and Time, and helps the tester cover the product from several different angles.
Correct. This is the expansion and the purpose the syllabus gives for SFDIPOT.
RCRCRC stands for Recent, Core, Risky, Configuration, Repaired and Chronic, and is aimed at deciding what to cover in regression testing.
Correct. This is the expansion and the regression-selection purpose the syllabus gives for RCRCRC.
FEW HICCUPPS is the mobile-specific mnemonic, covering inputs, storage, location, interruptions and network conditions on a handheld device.
Incorrect. Those items belong to I SLICED UP FUN; FEW HICCUPPS is the mnemonic for test oracles.
TERMS is the mnemonic for test oracles, covering familiarity, history and comparable products among its consistency heuristics.
Incorrect. Those are FEW HICCUPPS items; TERMS covers success factors for test automation — Tools and Technology, Execution, Requirements and Risks, Maintenance and Security.
RCRCRC stands for Requirements, Coverage, Risk, Configuration, Regression and Compliance, and is used to structure the test planning of an iteration.
Incorrect. This is not the syllabus expansion of RCRCRC, and the mnemonic serves regression selection rather than iteration planning.
Section 5.1.2 names five mnemonics: SFDIPOT (Structure, Function, Data, Interfaces, Platform, Operations, Time), RCRCRC (Recent, Core, Risky, Configuration, Repaired, Chronic — for regression), I SLICED UP FUN (for mobile testing), FEW HICCUPPS (for test oracles) and TERMS (test automation success factors).
A tester is planning test tours of the museum's booking site. Which pairing of a tour district with its focus matches the districts described in the syllabus?
The seedy districts tour focuses on negative testing, error guessing and fault attacks.
Correct. The syllabus assigns negative testing, error guessing and fault attacks to the seedy districts.
The tourist district tour focuses on the features that generate most of the product's revenue and therefore carry the greatest business value.
Incorrect. The core business value belongs to the business district; the tourist district is about the shallow first impressions a newcomer forms.
The historical district tour focuses on the features added in the most recent iterations, since the newest history is the part most likely to have changed.
Incorrect. The historical district concerns older and legacy parts of the product, not the newest additions.
The hotel district tour focuses on the accessibility features that returning visitors rely on when they book a repeat visit to the museum.
Incorrect. The hotel district concerns background and rarely exercised idle behaviour, not accessibility for returning users.
The entertainment district tour focuses on the load and stress behaviour of the site during a high-demand exhibition ticket sale.
Incorrect. The entertainment district concerns the supporting features around the main ones; load and stress behaviour is a non-functional concern addressed elsewhere.
Section 5.1.3 describes six districts: the business district (the features that carry the core business value), the historical district (older and legacy parts of the product), the tourist district (the parts a newcomer visits, the shallow first impressions), the entertainment district (supporting features around the main ones), the hotel district (background and idle behaviour) and the seedy districts (negative testing, error guessing and fault attacks).
The HR-onboarding SaaS team wants to run its first mob testing session on the new approval workflow. Which two statements about mob testing match the syllabus? (Choose two.)
A mob is usually five to eight people, with the roles of Moderator, Navigator and Driver and the remainder of the group acting as observers.
Correct. This is the group size and the role set the syllabus specifies.
Roles rotate roughly every four minutes — the navigator takes over as driver and the driver rejoins the mob — while the moderator sits behind the group and does not rotate.
Correct. This is the rotation mechanism and the moderator's position described in the syllabus.
The moderator may step into any role in the group, including the driver, whenever the mob gets stuck on the workflow being explored.
Incorrect. The syllabus allows the moderator to take any role except driver, so that the moderator never ends up operating the product.
The driver decides what to test next and states the intention, while the navigator operates the keyboard and carries out the instructions.
Incorrect. The roles are the other way round: the navigator states the intention and the driver operates the keyboard.
A mob session runs for a full working day and ends when the charter has been exhausted, so that the whole group builds a complete picture of the feature.
Incorrect. A session usually lasts about two hours; a full day contradicts both the stated duration and the intensity of four-minute rotation.
Section 5.2.1 describes mob testing, also called ensemble testing, built on the idea of swarming. The group is usually five to eight people with the roles Moderator, Navigator, Driver and the rest of the mob as observers. Roles rotate roughly every four minutes: the navigator becomes the driver and the driver rejoins the mob. The moderator sits behind the group, does not rotate, and may take any role except driver. A session usually lasts about two hours and is followed by a retrospective.
Which statement about pair testing matches the syllabus?
Pair testing is most valuable for exploratory work, complex or new features, scenarios spanning the user interface and the API, and mentoring junior testers; its cost in effort and the risk of one partner dominating are managed by applying it strategically, swapping roles regularly and agreeing clear goals beforehand.
Correct. This reproduces both the situations where the syllabus recommends pair testing and the way it manages the associated problems.
Pair testing reduces the total effort spent on a feature because two people cover twice the ground in the same elapsed time, which is why the syllabus presents it as the default working mode for the test activities of an iteration.
Incorrect. The syllabus lists the effort cost as one of the problems of pair testing and asks for strategic, selective use rather than a default mode.
Pair testing works best when the two partners share the same background and testing style, since differing styles are the main reason pairs fail, so the syllabus advises pairing two testers of comparable seniority.
Incorrect. Differing styles are named as a challenge to manage, not a reason to remove diversity; mentoring a junior tester is one of the recommended uses.
Pair testing is a review technique in which a second tester re-executes the first tester's test cases afterwards and compares the two sets of results, which is why the syllabus groups it under assisted testing.
Incorrect. Pair testing means two people testing together at the same time; sequential re-execution and comparison is a different activity altogether.
Pair testing should be reserved for stable, well-understood features so that neither partner is interrupted by unknowns, while new features are better handled by a single tester working from a written charter.
Incorrect. This inverts the guidance: complex and new features are among the situations where the syllabus finds pair testing most valuable.
Section 5.2.2 names exploratory work, complex or new features, cross-functional scenarios spanning user interface and API, and the mentoring of junior testers as the situations where pair testing is most valuable. Its problems are the effort it costs, differing working styles, one partner dominating and mental fatigue; the remedies are to apply it strategically, swap roles regularly and agree clear goals before the session.
A developer on the food-delivery platform generated a new promotion-code service from a natural-language prompt. The tester wants to apply vibe testing. Which statement describes vibe testing as the syllabus does?
It is a new, not yet standardised AI-assisted approach that grew alongside vibe coding; it is intent-first validation — checking what the application should do in the real world rather than only what it does — and it targets gaps such as input validation, handling of invalid data and role-based logic.
Correct. This reproduces the syllabus description, including the intent-first framing and the typical gaps left by generated code.
It checks that the generated code matches the prompt that produced it, comparing the implementation against the developer's natural-language description rather than against the product's intended behaviour in the real world.
Incorrect. This inverts the essential point: vibe testing is intent-first, validating against the real-world intent, not against the prompt that produced the code.
It is a standardised technique in which the tester records a subjective confidence rating per feature after each session, and the ratings are aggregated into a release-readiness score presented at the iteration review.
Incorrect. The syllabus states explicitly that vibe testing is not yet standardised, and it is not a confidence-rating scheme.
It means having an LLM execute the existing regression suite and report the failures it considers relevant, so the team can retire its manual regression testing and rely on the model's judgement of the results.
Incorrect. That is a tool-supported execution scenario; vibe testing concerns validating intent, and the syllabus keeps automation as a complement to human testing rather than a replacement.
It is the practice of testing an application only through its user interface, using the tester's intuition instead of documented test cases, and it is the syllabus term for unstructured ad hoc testing.
Incorrect. Vibe testing is an AI-assisted, intent-first approach; unstructured testing driven purely by intuition is not what the syllabus names here.
Section 5.2.3 presents vibe testing as a new, not yet standardised AI-assisted approach that grew alongside vibe coding. It is intent-first validation: checking what the application should do in the real world rather than only what it happens to do, which targets the areas an LLM silently leaves out — input validation, handling of invalid data and role-based logic.
The HR-onboarding SaaS team is working on the epic "automated onboarding of a new hire". The epic contains five user stories: creating the hire record, handing the identity over to the corporate identity provider, generating a role-based checklist, assigning a buddy, and showing a progress view to the manager. The iteration goal is to demonstrate a first automated onboarding end to end. The identified product risks are a duplicate corporate e-mail address, a hire reporting to two managers, and salary fields becoming visible to the wrong role. The acceptance criteria of the checklist story say nothing about hires with two managers, and the buddy story has no acceptance criteria at all. The tester now has to derive test charters from this epic. Which set of charters follows the syllabus guidance for test charter creation?
Three charters, each stating at least a mission with test objectives and a scope: the identity handover for a hire whose corporate e-mail already exists; checklist generation for a hire reporting to two managers, where the acceptance criteria are silent; and role-based visibility of the salary fields across the HR-admin, manager and buddy roles. Scope, setup and priority are derived with the 5W1H questions, and the acceptance criteria are used as lightweight test oracle notes.
Correct. The charters are derived from the product risks and the iteration goal, they carry the mandatory mission and scope, 5W1H supplies the optional elements, and the acceptance criteria are treated as oracle notes rather than exhaustive oracles.
One charter per user story, each one containing that story's acceptance criteria copied in as the test oracle for the session, so that the five charters together give demonstrable coverage of the whole epic.
Incorrect. The syllabus states that acceptance criteria are lightweight oracle notes and not exhaustive test oracles; a charter mechanically derived per story also ignores the product risks and the iteration goal.
One charter for the whole epic containing detailed step-by-step instructions for every story, so that the session can be repeated identically by any tester and the results of two runs can be compared.
Incorrect. A charter is a short statement of mission and scope that leaves room for the tester's judgement; a step-by-step script is a test procedure and defeats the purpose of exploratory testing.
Charters only for the stories whose acceptance criteria are complete, with the checklist story and the buddy story held back until the product owner has filled in their missing criteria.
Incorrect. Missing or vague acceptance criteria are named in the syllabus as a reason to apply exploratory testing, not a reason to postpone it.
A single charter with the mission "test the onboarding epic", deliberately leaving the scope open so the tester can follow whatever looks interesting, with priority and setup decided while the session is running.
Incorrect. Scope is part of the mandatory minimum alongside the mission; an open-ended charter is not the testable hypothesis the syllabus asks for.
Section 5.1.4 defines a charter as a short statement of the mission, scope and test objectives of a session — a testable hypothesis — derived from user stories, acceptance criteria, product risks and iteration goals. Mission or test objectives and scope are the mandatory minimum; actor, purpose, setup, priority, data, activities, test oracle notes, variations, limitations and constraints are optional. The 5W1H (Kipling) questions help derive scope, setup and priority. Acceptance criteria give test conditions and serve as lightweight test oracle notes but are not exhaustive oracles, and missing or vague criteria are themselves a reason to explore.
The museum booking product has just released a "school group booking" feature to three museums; it is expected to carry a large share of next season's revenue. In the same iteration, the seat-map component that has been in the product for six years was refactored to support the new group layouts. The acceptance criteria say nothing about the maximum group size. The tester has 90 minutes before the iteration review. How should the exploratory session be applied, using the test tours the syllabus describes?
Split the 90 minutes into pre-session setup, execution and post-session review; run a business district tour over the school-group booking flow that now carries the revenue, then a historical district tour over the refactored seat map, and record coverage, evaluation notes and anomalies on a session sheet.
Correct. The timebox and the three phases match 5.1.5, and the two districts match the revenue-carrying feature and the refactored legacy component as described in 5.1.3.
Spend the whole 90 minutes on a seedy districts tour, since negative testing, error guessing and fault attacks yield the highest number of defects per hour, and report the defect count at the iteration review.
Incorrect. A single negative-testing tour leaves both the new revenue path and the refactored legacy component unexamined, and a defect count is not the coverage information the post-session review needs.
Drop the timebox and keep exploring until the charter is exhausted, since a fixed 90 minutes could stop the session while defects remain, and write the findings up afterwards from memory.
Incorrect. The syllabus specifies a 60 to 120 minute timebox and asks for notes taken during the session; reconstructing findings from memory loses the coverage and evaluation record.
Run a tourist district tour over the school-group flow, because the feature is new to the three museums and their staff are newcomers to it, and leave the refactored seat map to the existing regression suite.
Incorrect. The tourist district concerns shallow first impressions rather than the core revenue path, and a refactored six-year-old component is precisely where the historical district tour adds value beyond the regression suite.
Postpone the session until the maximum group size has been specified in the acceptance criteria, and use the 90 minutes to execute the existing regression suite for the booking flow a second time.
Incorrect. Vague or missing acceptance criteria are named in the syllabus as one of the triggers for exploratory testing, so they are a reason to run the session rather than to defer it.
Section 5.1.5 puts a test session in a 60 to 120 minute timebox with three phases: pre-session setup, test execution and post-session review, and asks the tester to record coverage, evaluation notes, actual behaviour and anomalies on a session sheet. Section 5.1.3 assigns the core business value to the business district and the older, legacy parts of the product to the historical district — which is exactly what the new revenue-carrying feature and the refactored six-year-old component are.
During the iteration review of the food-delivery product, the business representative asks how the new courier-reassignment logic behaves when a courier goes offline halfway through a delivery. The only acceptance criterion on the subject reads "the order is reassigned". The team has 60 minutes between the review and the retrospective, and the dispatch service was changed substantially in this iteration. How should exploratory testing be applied here, and what belongs in the post-session review?
Charter a 60-minute session on the reassignment behaviour, since the review itself, the substantial change to the dispatch service and the vague acceptance criterion are all triggers for exploratory testing; run setup, execution and review, and in the review discuss the charter against what actually happened, the defects found, the questions raised and the next steps.
Correct. Three of the four triggers in 5.1.5 apply, the timebox fits, and the four items listed are what the syllabus puts on the post-session review agenda.
Raise a defect against the vague acceptance criterion and defer any testing to the next iteration, because exploratory testing needs a precise oracle in order to judge whether the observed behaviour is correct.
Incorrect. Vague acceptance criteria are a trigger for exploratory testing, and the tester uses heuristics and oracle notes rather than requiring a precise oracle up front.
Use the 60 minutes to automate regression tests for the reassignment logic, because a question raised at a demo should be answered by a repeatable test rather than by a one-off exploratory session.
Incorrect. Automation does not answer an open question about unspecified behaviour; the syllabus keeps automation as a complement to exploratory testing rather than a substitute for it.
Run the session but keep the notes private to the tester and report only the number of defects found, so that the post-session review stays short and does not eat into the team's retrospective time.
Incorrect. The post-session review is where coverage, the charter against reality, the questions raised and the next steps are shared with the team; a defect count discards all of that.
Run an open-ended session across the whole dispatch service and stop only when nothing new is being found, since a timebox risks ending the session while defects remain, and record the total session length in the review.
Incorrect. The syllabus sets a 60 to 120 minute timebox and a scoped charter; an unbounded session over a whole service abandons both the scope and the review structure.
Section 5.1.5 names four points where exploratory testing applies: during the iteration, at the iteration review or demo, after major changes, and where acceptance criteria are vague. Three of the four are present here. A session runs pre-session setup, execution and post-session review, and the review discusses the test charter versus reality, the defects found, the questions raised and the next steps.
A reviewer looks at three manual test cases for the museum's booking flow. TC-101, TC-102 and TC-103 each begin with the same nine steps: open the site, accept cookies, log in as the demo visitor, close the newsletter dialog, open the exhibitions page, select the spring exhibition, open the calendar, pick a date and open the basket. All three then assert against the same fixed ticket identifier "TCK-4471" and the same fixed visitor account "visitor-88", written directly into the steps. A change to the login flow last iteration required all three test cases to be edited by hand. Which test smells are present and what is the appropriate solution?
Copy-Paste Duplication, an excess smell, and Hardcoded Test Data, a level-of-detail smell; extract the nine repeated steps into shared preconditions the three cases reference, and replace the fixed ticket and account identifiers with data the test creates or receives as a parameter.
Correct. The repeated preparation is Copy-Paste Duplication and the embedded identifiers are Hardcoded Test Data, and these are the solutions the syllabus pairs with them.
Interdependent Tests and No Cleanup or Teardown; make each test case create and then delete its own data so that the execution order of the three cases stops mattering to the outcome.
Incorrect. Nothing here says that one case depends on another having run, and no leftover state is described; the evidence is repetition of steps and fixed data.
Call on Me and Bulk Steps; merge the three test cases into one longer case so that the nine shared steps appear only once and the three verifications follow one after another.
Incorrect. Call on Me is one test case calling into another, which is not what these cases do, and merging them produces a God Test Case — replacing one smell with a worse one.
Overly Long or Detailed Test Case and Ambiguous Steps; shorten every step to a single sentence and delete the expected results that are repeated across the three cases.
Incorrect. The steps here are concrete rather than ambiguous, and deleting repeated expected results removes verification instead of removing the duplication.
Unstructured Formatting and Typos; apply the team's test case template and run a spell check, after which the duplicated preparation will be easier to spot and read.
Incorrect. These are format and language smells; the problem described is structural duplication and fixed data, which formatting does not address.
Repeating the same nine preparation steps in three test cases is Copy-Paste Duplication, one of the excess smells; embedding fixed identifiers directly in the steps is Hardcoded Test Data, one of the level-of-detail smells. The solutions are to extract the repeated preparation into shared preconditions or setup that the test cases reference, and to have the test create or parameterise its own data instead of depending on fixed records.
A reviewer examines three manual test cases in the HR-onboarding product. TC-210 creates a new hire record. TC-211 verifies the onboarding checklist and its steps begin with "the hire created in TC-210 is in the pending state". TC-212 verifies that a buddy can be assigned; it works on the demo tenant, where the "Buddy" role happens to be enabled, but no precondition of TC-212 mentions that role configuration and a new colleague running it on a fresh tenant sees an empty dropdown. None of the three cases removes the records it created. Which test smells are present and what is the appropriate solution?
Interdependent Tests and Hidden Dependencies, both dependency and complexity smells, together with No Cleanup or Teardown; give each case the setup it needs, state the required role configuration explicitly in the preconditions, and remove the created records at the end so the cases can run in any order.
Correct. The dependency on TC-210 is Interdependent Tests, the unstated tenant configuration is a Hidden Dependency, and the records left behind are No Cleanup or Teardown.
ORacle and No Clear Expected Results; add an explicit expected result to every step so that a tester running the cases does not have to ask a colleague what the correct behaviour is supposed to be.
Incorrect. These are real smells, but nothing in the scenario says the expected results are missing or that the tester must consult a person; the evidence points at dependencies and leftover state.
God Test Case and One More Step; split TC-211 so that each resulting case verifies exactly one behaviour and no verification is hidden inside the final step of a long sequence.
Incorrect. TC-211 is not described as oversized or as hiding a verification in its last step; the described problems are the cross-case dependency and the unstated configuration.
Environment Assumptions alone; record in the test plan that all three cases must be executed on the demo tenant and in the fixed order 210, 211, 212 so that any tester obtains the same result.
Incorrect. Documenting the required order preserves the interdependency rather than removing it, and it misses both the hidden role dependency and the absent cleanup.
Invalidation Heaven and Bulk Steps; reduce the number of negative variants across the three cases and group the preparation into a single step called "prepare the tenant" to keep the cases short.
Incorrect. No excess of negative variants is described, and collapsing the preparation into one opaque step deepens the hidden dependency instead of exposing it.
TC-211 relying on TC-210 having run is Interdependent Tests, and TC-212 relying on an unstated tenant configuration is Hidden Dependencies — both dependency and complexity smells; leaving created records behind is No Cleanup or Teardown, a lack smell. The solutions are to give each case the setup it needs, to state the required configuration explicitly in the preconditions, and to remove the created data at the end so that the cases can run in any order.
The mobile banking team is deciding what to automate for the next release. Which approach matches the syllabus guidance on test automation in Agile software development?
Automate the repetitive, deterministic checks whose automation removes the most risk — component and API tests plus a narrowly bounded set of end-to-end tests — and take the decision at refinement and iteration planning, leaving exploratory and one-off testing to be done manually.
Correct. This matches the risk-and-value driver, the typical distribution of automated tests and the planning moment the syllabus describes.
Automate first the tests that have not failed for several releases, because a stable test is cheap to maintain and gives the pipeline a dependable signal that nothing has regressed.
Incorrect. The syllabus states that tests which never fail deliver little benefit, so a long record of passing is an argument against prioritising them, not for it.
Automate the frequently changing screens first, because manual re-testing of functionality that changes every iteration is what consumes the most tester effort over a release.
Incorrect. Frequently changing functionality makes poor automation candidates, since the maintenance cost of the tests grows with every change.
Automate the end-to-end journeys first and add component tests only for the areas where defects escape to production, because end-to-end tests are the closest thing to the customer's experience.
Incorrect. This inverts the distribution the syllabus recommends and maximises the drawbacks of end-to-end testing described in 1.2.
Decide the automation scope once per release in a separate automation backlog owned by an automation specialist, so that iteration planning can stay focused on delivering the features.
Incorrect. The syllabus places these decisions in refinement and iteration planning precisely because doing so improves the predictability of the iteration.
Section 6.1 makes risk and value the drivers of the automation decision: repetitive, deterministic, high-value checks are good candidates, tests that never fail deliver little benefit, and frequently changing tests are poor candidates. What to automate and to what depth is decided at refinement and iteration planning. The typical shape is component tests, API tests and a narrowly bounded set of end-to-end tests, with exploratory and one-off testing remaining manual.
The food-delivery team is reviewing which categories of test tools support its Agile way of working. Which two statements match the syllabus? (Choose two.)
Monitoring and analytics tools, used in the sense of monitoring as testing, are one of the tool categories named as helpful for testing in Agile software development.
Correct. Monitoring and analytics is one of the categories in 6.2, explicitly under the heading of monitoring as testing.
AI tools that generate test cases from changes in code, requirements or user behaviour, predict build failures, and produce realistic test data including edge cases are named as a helpful category.
Correct. These are exactly the AI tool uses the syllabus lists in 6.2.
Tool selection should follow the team's existing familiarity with a product and its popularity on the market, so that recruiting and vendor support are easier to secure later.
Incorrect. The syllabus states that tool selection should follow from the test strategy and the automation layers, not from convenience or fashion.
The syllabus names a recommended product for each tool category so that teams across an organisation can standardise on one comparable toolchain.
Incorrect. The syllabus deliberately discusses categories of tools and names no products.
Test design, implementation and execution tools are listed as a category, but support for ATDD and BDD falls outside tooling and remains a purely human collaborative activity.
Incorrect. Support for ATDD and BDD as specification by example is explicitly named as part of that tool category.
Section 6.2 lists categories of tools rather than products: task management and tracking; communication and collaboration; test design, implementation and execution (including support for ATDD and BDD); continuous integration; configuration management; session recording and screenshot tools; monitoring and analytics, used in the sense of monitoring as testing; and AI tools. Tool selection should follow from the test strategy and the automation layers rather than from convenience or fashion.