CTAL-AT v2.0 · ISTQB · Test Strategy and Test Approach Challenges · Bank updated 2026-11-01
CTAL-AT v2.0 practice questions: Test Strategy and Test Approach Challenges
5 free questions from 17 on this area · answer and explanation for each · no sign-up
These 5 questions come from the Test Strategy and Test Approach Challenges section of our CTAL-AT v2.0 bank (17 questions on this area, which carries 13% of the real exam). Every question is original, with the correct answer explained and linked to the source it is drawn from.
Free: 6 questions in study mode, no card. All 17 Test Strategy and Test Approach Challenges questions and the full CTAL-AT v2.0 bank: $15 one-time.
1/5 · Test Strategy and Test Approach Challenges · easy
Which statement best describes what distinguishes a holistic testing approach from a purely formal, document-driven approach to testing in an agile team?
AHolistic testing requires a dedicated, independent test team to sign off every test case and its expected results before execution, a gate that a formal, document-driven approach does not normally impose on the team.
BHolistic testing means abandoning all test documentation, including charters and checklists, and relying exclusively on ad hoc exploratory sessions with no up-front planning or risk analysis.
CHolistic testing draws on multiple dimensions such as skills, risk, business value and quality characteristics, and keeps adapting the whole team's approach, rather than relying only on formally approved test cases.
DHolistic testing applies only to non-functional quality characteristics such as usability, security, and performance, while formal testing applies only to functional requirements and their traceability.
2/5 · Test Strategy and Test Approach Challenges
In a scaled agile program, an 'order fulfillment' end-to-end journey spans a Cart team, a Payment team, and a Shipping team, each working independent two-week sprints. The Cart team finishes its story in sprint 1, but the Payment component won't be ready until sprint 2 and Shipping until sprint 3. What is the most appropriate way to manage end-to-end test risk during sprint 1?
APostpone all testing of the Cart story until sprint 3, when the Payment and Shipping components are ready and the full journey can run end-to-end in a single pass.
BAsk the Cart team to also build and unit-test the Payment and Shipping components themselves in sprint 1, so a full end-to-end test of the order journey can run before that sprint ends.
CTest the Cart story in isolation with stubs or service virtualization for the missing Payment and Shipping interfaces, and add end-to-end sessions as each component becomes available.
DSkip end-to-end testing of the journey entirely, since Cart, Payment, and Shipping components that each pass their own sprint tests always guarantee the journey works.
3/5 · Test Strategy and Test Approach Challenges
When agile teams talk about testing across 'system boundaries' as part of end-to-end testing, what do they primarily mean?
AThe scope limit of a single user story, i.e., everything explicitly listed in its acceptance criteria.
BThe boundary values of an input field, as used in the boundary value analysis test design technique.
CThe points where the system under test interacts with other systems, services, or components that may be outside the team's direct control.
DThe calendar boundary between the end of one sprint and the start of the next.
4/5 · Test Strategy and Test Approach Challenges · hard
A story for a redesigned checkout page has clear, automatable acceptance criteria (e.g., 'total updates correctly when a discount is applied') but also carries meaningful usability and 'look and feel' risk that no automated check can evaluate. Which test approach best reflects a holistic, quadrant-informed strategy for this story?
ACombine Q2 automated acceptance tests for the documented criteria with charter-driven, session-based Q3 exploratory testing focused on usability and look-and-feel, since neither quadrant alone covers both types of risk.
BRun only Q4 performance tests, since checkout pages are primarily at risk of being too slow under load.
CSkip testing the documented acceptance criteria altogether and rely solely on an exploratory testing session, since exploratory testing can uncover any type of defect given enough time.
DRely exclusively on Q2 automated acceptance tests, since satisfying the documented acceptance criteria is sufficient evidence of quality for any story.
5/5 · Test Strategy and Test Approach Challenges
A team wants a lightweight, collaborative way to identify and rate product risks for the stories in its next sprint, involving the Product Owner, developers, and testers together, without producing a lengthy formal risk register. Which approach best fits this need?
AA quarterly external audit review that assigns risk ratings to the backlog independent of the development team's own input
BA short, informal whole-team risk workshop during backlog refinement or sprint planning where participants jointly identify risk items and agree rough likelihood and impact ratings
CAn automated static-analysis tool run against the codebase, with its output alone used to set every story's risk level for the sprint
DA single tester privately compiling a comprehensive, formally-approved risk register modeled on a sequential-lifecycle template before the sprint begins
Other CTAL-AT v2.0 areas
The same kind of free sample for every other section of the CTAL-AT v2.0 bank:
Practise CTAL-AT v2.0 with instant feedback
6 free questions in study mode · no card · full CTAL-AT v2.0 bank with area filters and the error log: $15 one-time · no dumps, no ads.
Start CTAL-AT v2.0 free →
ExamDeck is an independent study tool, not affiliated with, endorsed by, or sponsored by ISTQB. CTAL-AT v2.0 and related marks are trademarks of their respective owners, used for identification only. Exam facts checked against official ISTQB materials (as of October 2026); always confirm current details with the vendor before booking.