CTAL-AT v2.0 · ISTQB · Shift Left · Bank updated 2026-07-03
CTAL-AT v2.0 practice questions: Shift Left
5 free questions from 26 on this area · answer and explanation for each · no sign-up
These 5 questions come from the Shift Left section of our CTAL-AT v2.0 bank (26 questions on this area, which carries 22% of the real exam). Every question is original, with the correct answer explained and linked to the source it is drawn from.
1/5 · Shift Left
Which statement best captures the syllabus's guidance on the relationship between acceptance criteria and test cases when shifting testing left?
ATest cases must always be written before acceptance criteria to ensure independent verification of the story.
BAcceptance criteria replace the need for any exploratory testing once a story is implemented.
CAcceptance criteria are informal notes for the Scrum Master only and have no traceable relationship to executable tests.
DAcceptance criteria are a form of testware that defines the conditions of satisfaction for a story and can be directly used to derive test cases and BDD scenarios.
Show answer & explanation
2/5 · Shift Left · hard
After 25 minutes of example mapping a single story, the board shows two blue (rule) cards, three green (example) cards, and seven red (question) cards, with several fundamental questions about the story's scope still unanswered. What is the most appropriate conclusion and action for the team?
AThe team should proceed straight to sprint planning because example mapping's purpose is fulfilled once at least one example exists per rule, regardless of open questions.
BThe team should abandon example mapping and switch immediately to storyboarding, which is designed specifically to resolve unanswered business questions.
CThe seven red cards should be reclassified as green cards so that the story appears ready, since example mapping does not permit unresolved items to remain on the board.
DThe high ratio of unresolved question cards to rule/example cards signals that the story is too big or insufficiently understood; it should be split, clarified with the product owner, or deferred until refined further.
Show answer & explanation
3/5 · Shift Left
A large user story, 'As a customer, I want to complete the entire checkout process (cart review, shipping, payment, confirmation) so that I can buy items,' needs to be sliced for testability within a two-week sprint. Which slicing approach best matches the recommended technique of slicing along workflow steps?
ASplit the story into a spike to research checkout technology and a separate story to write documentation, with no testable behavior in either slice.
BSplit the story by developer skill set, e.g., one story for front-end code and one for back-end code, regardless of user-visible value.
CSplit into separate stories for cart review, shipping selection, payment, and confirmation, each independently valuable and testable, rather than building the whole flow at once.
DKeep the story whole but reduce its acceptance criteria to only the happy path, deferring all error handling to a later, unplanned release.
Show answer & explanation
4/5 · Shift Left
A team uses a storyboard (a sequence of sketches showing how a user will move through a new checkout flow) during backlog refinement. Which statement best distinguishes storyboarding from testboarding as shift-left techniques?
ATestboarding replaces storyboarding entirely once a team adopts BDD, because Given-When-Then scenarios make visual sketches redundant.
BStoryboarding is used only for mobile applications, while testboarding is a generic term for any Kanban board tracking defect counts.
CStoryboarding is a purely developer-facing UML technique, while testboarding is reserved for exploratory testing charters written after release.
DStoryboarding visualizes the user's journey to elicit and clarify requirements, whereas testboarding overlays test ideas, conditions, and potential failure points onto that same visual flow so test design shifts left alongside requirements analysis.
Show answer & explanation
5/5 · Shift Left · easy
Which statement correctly distinguishes Test-Driven Development (TDD) from Acceptance Test-Driven Development (ATDD) and Behaviour-Driven Development (BDD) as shift-left, test-first practices?
AATDD and BDD apply only to non-functional requirements such as performance, while TDD is reserved exclusively for functional business logic.
BTDD is a technology-facing, developer-driven practice of writing a failing unit test before minimal production code, while ATDD and BDD are business-facing, whole-team practices that define acceptance-level examples before a story is implemented.
CATDD and BDD are performed exclusively by developers after a feature is coded, while TDD is performed by the whole team during backlog refinement before a story is estimated.
DTDD, ATDD, and BDD are simply three interchangeable names for the same activity, differentiated only by which automation framework a team happens to use.
Show answer & explanation
B is correct. TDD is a technology-facing, unit-level design technique used by developers to drive code structure through red-green-refactor cycles. ATDD and BDD are business-facing, whole-team practices that turn a story's acceptance criteria into concrete examples before development begins. All three are 'test-first' and support shift-left, but they operate at different levels and involve different stakeholders.
↗ the ISTQB Advanced Level Agile Tester (CTAL-AT) Syllabus v2.0 — Shift Left
Other CTAL-AT v2.0 areas
The same kind of free sample for every other section of the CTAL-AT v2.0 bank:
Study Shift Left with instant feedback
6 free questions · filter study mode by area and difficulty · error log with spaced repetition · no card, no dumps, no ads.
Create your free account →
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 August 2026); always confirm current details with the vendor before booking.