First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.
Continue in the practice tool above to load more questions, 50 at a time.
Question 1Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
In an agile project, which document most directly replaces the traditional detailed requirements specification as the primary statement of what the team intends to build?
- The test summary report produced at the end of each sprint
- The configuration management plan for the release pipeline
- The product backlog, refined continuously with the product owner Correct answer.
- The project charter signed at the start of the engagement
Explanation
In agile, requirements live in the product backlog, which is ordered and refined continuously rather than frozen in a specification. The backlog items, from epics down to user stories, express what the team intends to build and evolve with each iteration. Other documents may exist but do not serve as the living statement of requirements.
Question 2Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
A team writes a user story as: 'As a returning customer, I want to save my delivery address, so that I do not re-enter it on every order.' Which quality characteristic of the story is best demonstrated here?
- It defines precise acceptance criteria and test data
- It records the technical design of the address storage
- It estimates the effort required to implement the feature
- It states a clear user benefit that justifies the feature Correct answer.
Explanation
The 'so that' clause expresses the value or benefit to the user, which is the purpose of that part of the story template. Acceptance criteria, estimation and design are separate concerns that the story text does not yet provide. A benefit-focused clause helps the team judge priority and avoid building features with no user value.
Question 3Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
Which practice is most characteristic of whole-team approach to quality in agile testing?
- Business representatives, developers and testers collaborate on defining and verifying acceptance criteria Correct answer.
- A separate independent test team performs all system testing after each release
- Test automation is postponed until the final hardening sprint
- Testers write all test cases while developers focus only on code
Explanation
The whole-team approach means everyone with relevant knowledge contributes to quality, including helping define acceptance criteria and reviewing test results. Specialists still exist, but testing responsibility is shared rather than delegated to a separate group. This collaboration reduces handover delays and misunderstandings about expected behavior.
Question 4Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
During sprint planning, a team splits a large story into several smaller stories so each can be completed within a few days. Which agile testing benefit does this splitting primarily support?
- It guarantees that no defects will be found in integration
- It allows earlier and more frequent feedback on smaller increments Correct answer.
- It eliminates the need for acceptance criteria on each story
- It removes the need for regression testing across the sprint
Explanation
Smaller stories produce smaller increments, which can be tested and demonstrated sooner, giving faster feedback. Frequent feedback lets the team correct misunderstandings before they compound. Splitting does not remove the need for regression or acceptance criteria, nor does it guarantee defect-free integration.
Question 5Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
Which statement best describes the purpose of a definition of done in agile testing?
- It specifies the tools used to run the automated test suite
- It records the defects deferred to a future release
- It provides shared criteria that an increment must satisfy before it is considered complete Correct answer.
- It lists the individual tasks assigned to each developer for the sprint
Explanation
The definition of done is an agreed checklist of quality conditions an increment must meet, such as code reviewed and tests passed. It gives the whole team a common understanding of completeness and prevents half-finished work being counted as done. It is not a task list, defect log or tooling description.
Question 6Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
A tester is invited to a three amigos session for a story about applying discount codes. What is the tester's most valuable contribution in that session?
- Estimating the story in story points for the sprint backlog
- Choosing the programming language used for the discount service
- Proposing examples of boundary and negative scenarios that reveal ambiguity in the rules Correct answer.
- Approving the final production deployment schedule
Explanation
The three amigos session brings business, development and testing perspectives together to explore a story before coding. Testers contribute by raising concrete examples, especially boundaries and negative cases, that expose unclear or missing rules. Technology choice, estimation and deployment scheduling are separate activities.
Question 7Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
A team uses acceptance criteria written in Given/When/Then form. Which benefit does this format most directly provide for testing?
- It removes the need to discuss the story with the product owner
- It replaces the need for exploratory testing entirely
- It ensures the story is small enough to finish in one day
- It makes each criterion directly expressible as an executable or manual test scenario Correct answer.
Explanation
Given/When/Then structures a criterion as preconditions, action and expected outcome, which maps naturally onto a test case. This supports deriving tests directly from the agreed criteria. It does not remove the need for discussion, control story size, or make exploratory testing unnecessary.
Question 8Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
In an agile project, which activity best illustrates the shift from 'testing at the end' to 'testing throughout'?
- Producing a single test plan covering the entire project up front
- Running a full regression suite only in the release sprint
- Assigning all test execution to a separate team after code freeze
- Reviewing stories and writing acceptance tests before development starts Correct answer.
Explanation
Testing throughout means test activities start early, for example by reviewing stories and defining acceptance tests before coding. This prevents defects and gives the team a shared target. End-of-release regression, separate post-freeze teams and a single up-front plan reflect sequential models.
Question 9Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
Which statement about the test pyramid in agile testing is most accurate?
- It requires equal numbers of unit, service and UI tests
- It recommends a broad base of fast, low-level tests with fewer tests at higher levels Correct answer.
- It recommends that most tests be manual UI tests to mirror user behavior
- It states that UI tests are the most reliable and should dominate the suite
Explanation
The test pyramid places many fast, cheap unit-level tests at the base and progressively fewer service and UI tests above. This shape favors quick feedback and low maintenance cost while still covering integration and user-facing behavior. It is a guideline about proportions, not an equal split.
Question 10Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
An agile team automates a regression suite for their web application. Which criterion is most important when deciding which tests to include in the continuous regression set?
- The tests are the longest and most detailed in the repository
- The tests exercise every possible input combination exhaustively
- The tests were written by the most senior team member
- The tests cover high-risk and frequently changed functionality and run reliably Correct answer.
Explanation
Regression suites should prioritize high-risk, change-prone areas and must be reliable to give trustworthy feedback. Flaky or low-value tests waste time and erode confidence in results. Author seniority or test length is irrelevant, and exhaustive input coverage is infeasible in continuous runs.
Question 11Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
A team adopts behavior-driven development. Which artifact is central to linking business-readable specifications with automated checks?
- The burn-down chart
- The sprint retrospective minutes
- The executable specification written in a business-readable language Correct answer.
- The risk register maintained by the project manager
Explanation
BDD centers on executable specifications written in business-readable language, often with Given/When/Then scenarios, which can drive automated checks. This bridges business expectations and technical verification. Charts, risk registers and retrospective notes serve other purposes.
Question 12Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
Which example best illustrates exploratory testing in an agile context?
- Reviewing code for coding standard violations
- Executing a pre-scripted regression suite and recording pass or fail
- Running a static analysis tool over the source code
- A tester simultaneously designing and executing tests while learning about a new feature Correct answer.
Explanation
Exploratory testing combines test design, execution and learning in the same activity, guided by the tester's judgment and observations. In agile it complements scripted checks by finding issues that predefined cases miss. Scripted regression, code review and static analysis are distinct activities.
Question 13Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
A cross-functional agile team includes a business analyst, developers and testers. Which testing responsibility is most appropriately shared across all members?
- Maintaining the continuous integration server's hardware
- Reviewing acceptance criteria and giving feedback on story clarity Correct answer.
- Performing load testing against the production infrastructure
- Approving the production environment's security certificate
Explanation
Reviewing acceptance criteria and clarifying stories benefits from multiple perspectives and is a shared quality activity. Specialized tasks such as security approval, load testing and CI infrastructure maintenance may still be assigned to specific roles. Sharing story review spreads understanding and reduces late surprises.
Question 14Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
In agile planning, what is the primary purpose of a release plan?
- To provide a forecast of scope and timing that is updated as knowledge grows Correct answer.
- To fix the exact content and date of every future sprint
- To document the final acceptance of the delivered product
- To replace the product backlog with a detailed test schedule
Explanation
A release plan forecasts what might be delivered and when, based on current knowledge and velocity. Agile plans are intentionally revisable as feedback and priorities change. It does not freeze every sprint, replace the backlog, or certify final acceptance.
Question 15Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
A tester receives a user story with acceptance criteria that conflict with an earlier story. What is the most appropriate agile action?
- Implement tests for both stories and let the conflict surface in production
- Escalate directly to senior management without discussing it with the team
- Raise the conflict with the product owner and relevant team members to resolve the intended behavior Correct answer.
- Ignore the newer criteria because older stories take precedence
Explanation
Conflicting criteria indicate a requirements ambiguity that should be resolved collaboratively before testing proceeds. The product owner is best placed to decide intended behavior, supported by the team's analysis. Deferring to production or silently choosing one story risks building the wrong behavior.
Question 16Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
Which metric is most useful for an agile team to assess whether its automated regression suite provides timely feedback?
- The number of testers assigned to the team
- The total count of test cases stored in the repository
- The number of lines of test code written per sprint
- The time taken for the full automated suite to run after each integration Correct answer.
Explanation
Feedback timeliness depends on how quickly the automated suite completes after a change, so execution duration is the key indicator. Long-running suites delay defect detection and discourage frequent runs. Test code volume, headcount and raw test counts do not measure feedback speed.
Question 17Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
A team practices continuous integration. Which testing behavior does this most directly enable?
- Replacing exploratory testing with a single nightly run
- Deferring all defect fixes to the release sprint
- Running automated checks on every integrated change to detect regressions early Correct answer.
- Eliminating the need for a definition of done
Explanation
Continuous integration means changes are merged frequently and verified automatically, so regressions are caught soon after they are introduced. This shortens the feedback loop and keeps the mainline healthy. It does not remove the definition of done, replace exploratory testing, or justify deferring fixes.
Question 18Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
An agile team is selecting a test approach for a story with high business risk and frequent requirement changes. Which approach is most appropriate?
- Test only the happy path to save time
- Rely solely on a large manual regression suite run at release
- Combine risk-based test design with frequent automated checks and exploratory sessions Correct answer.
- Skip testing until the requirements stabilize completely
Explanation
High risk and changing requirements call for adaptive, risk-based testing supported by fast automated checks and exploratory investigation. Combining techniques addresses both known risks and unanticipated issues. Waiting for stability, testing only happy paths, or relying on a late manual suite increases exposure.
Question 19Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
A team's automated UI suite fails intermittently on the same tests, and the team has started ignoring failures. What is the most significant testing consequence?
- Exploratory testing is no longer needed
- The suite becomes faster because failures are skipped
- Trust in the suite erodes, so genuine regressions may go unnoticed Correct answer.
- The definition of done automatically becomes easier to satisfy
Explanation
Flaky tests that are routinely ignored train the team to dismiss red results, so real regressions can slip through. Reliability is essential for automation to provide trustworthy feedback. Ignoring failures does not improve speed, change the definition of done, or remove the value of exploratory testing.
Question 20Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
Which situation best justifies a team deciding to automate a particular test rather than keep it manual?
- The test requires human judgment about visual aesthetics
- The test is run once to explore a brand-new feature's usability
- The test is a stable, repetitive check executed on every build Correct answer.
- The test depends on unpredictable real-world data that changes each run
Explanation
Automation pays off for stable, repetitive checks that must run often, such as regression on every build. Exploratory usability checks, aesthetic judgments and highly unpredictable inputs are better suited to human evaluation. Automating those cases yields brittle or misleading results.
Question 21Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
A product owner keeps adding new acceptance criteria to a story already in progress. From a testing perspective, which response best reflects agile principles?
- Silently test only the original criteria and ignore the additions
- Assess the impact with the team and renegotiate scope or timing transparently Correct answer.
- Freeze the story and create a defect for each new criterion
- Refuse all changes until the next release to protect the test plan
Explanation
Agile welcomes changing requirements, but changes should be assessed for impact and handled transparently with the team. Renegotiating scope or timing keeps expectations aligned and testing realistic. Refusing changes, ignoring them, or logging them as defects misuses process.
Question 22Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
Which pairing of an agile testing activity with its main purpose is correct?
- Sprint review - demonstrating the increment and gathering stakeholder feedback Correct answer.
- Daily stand-up - running the full regression suite
- Sprint retrospective - verifying acceptance criteria of the increment
- Backlog refinement - executing performance tests against production
Explanation
The sprint review demonstrates the completed increment to stakeholders and collects feedback that shapes the backlog. Acceptance verification happens through testing during the sprint, while stand-ups coordinate work and refinement clarifies upcoming items. Performance testing against production is a separate, controlled activity.
Question 23Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
A team wants acceptance criteria that are testable. Which criterion is written in the most testable form?
- The checkout page should be user-friendly and modern
- The checkout page should generally work well under normal conditions
- The checkout page should feel fast and responsive to users
- When a valid order is submitted, the confirmation page displays within two seconds Correct answer.
Explanation
A testable criterion states a concrete condition and an observable, measurable outcome, as with a specified response time. Vague qualities such as 'fast', 'user-friendly' or 'works well' cannot be verified objectively. Precise criteria let testers design clear pass/fail checks.
Question 24Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
In agile testing, what does the term 'test-driven development' primarily involve?
- Writing a failing test before writing the code that makes it pass, then refactoring Correct answer.
- Writing all tests after the code is complete and frozen
- Assigning test writing exclusively to a separate quality team
- Replacing unit tests with manual system tests
Explanation
TDD follows a short cycle: write a test that fails, write just enough code to pass it, then refactor. This keeps design testable and provides immediate feedback. Writing tests after freezing code, delegating to a separate team, or substituting manual tests does not describe TDD.
Question 25Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
A team uses a kanban board with explicit work-in-progress limits. How does this practice most directly support testing quality?
- It guarantees that no defects escape to production
- It limits concurrent work so items are finished and tested before new ones start Correct answer.
- It eliminates the need for regression testing
- It removes the need for a definition of done
Explanation
WIP limits constrain how much work is in progress, encouraging the team to finish and test current items before pulling new ones. This reduces multitasking and half-done work that escapes testing. It does not guarantee defect-free releases, nor remove the definition of done or regression testing.
Question 26Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
In an agile project, what is the main purpose of the 'definition of done' for testing?
- To define the order in which test cases will be executed by the test team
- To create a shared, explicit set of quality criteria that every story must satisfy before it is considered complete Correct answer.
- To list the individual tasks each developer must finish during the sprint
- To record the defects found during the previous release for trend analysis
Explanation
The definition of done is a team-wide agreement describing the conditions a product increment must meet to be treated as complete, including quality and testing criteria. It gives testers and developers a common, visible standard, so 'done' does not depend on individual interpretation. It is not a task list, a defect log, or an execution schedule.
Question 27Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
Which statement best describes the role of a tester in agile estimation sessions?
- The tester postpones all estimation input until the acceptance criteria are finalized
- The tester silently accepts the estimate given by the developers to avoid slowing the session
- The tester raises test effort, test data needs and uncertainty so the estimate reflects the whole effort Correct answer.
- The tester converts every estimate into a fixed number of test cases to be written
Explanation
Agile estimation covers the whole effort needed to deliver a story, including testing activities, environment needs and unknowns. The tester contributes by surfacing test-related effort and risk so the team's estimate is realistic. Waiting for finalized criteria or staying silent hides effort that later causes overcommitment.
Question 28Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
A team writes acceptance criteria for a login story. Which set of criteria is written in the most testable form?
- After three failed attempts within ten minutes, the account is locked for fifteen minutes Correct answer.
- The login page should look modern and behave sensibly on mobile devices
- Login should be secure and user friendly for all customers
- Login must be fast and reliable under normal conditions
Explanation
Testable acceptance criteria state observable conditions with concrete values, so a pass or fail can be decided without debate. Specifying the number of attempts, the time window and the lock duration makes verification objective. Words such as 'secure', 'fast' or 'modern' are subjective and cannot be checked consistently.
Question 29Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
What does the agile testing quadrants model primarily help a team to do?
- Rank individual testers by the number of defects they report
- Assign every test to a single owner so accountability is clear
- Replace exploratory testing with scripted regression testing across the project
- Decide which tests support the team versus critique the product, and which are business-facing versus technology-facing Correct answer.
Explanation
The quadrants classify tests along two dimensions: whether they support the team or critique the product, and whether they are business-facing or technology-facing. The model helps a team see that all four kinds of testing are needed and plan a balanced approach. It is a planning aid, not a performance-ranking or ownership tool.
Question 30Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
During a sprint, a tester notices that a story's acceptance criteria omit an important error-handling scenario. What is the most appropriate agile response?
- Add the missing scenario to the automated suite without telling anyone
- Log a defect against the story and wait for the next sprint to discuss it
- Document the omission in the test summary report at the end of the sprint
- Raise the gap immediately with the product owner and developers and refine the criteria together Correct answer.
Explanation
Agile teams value early, face-to-face collaboration, so gaps in acceptance criteria are best resolved as soon as they are found, with the people who own and build the story. Joint refinement keeps the criteria and the tests aligned while the work is still in progress. Deferring to a later sprint or acting unilaterally undermines shared understanding.
Question 31Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
Which practice is most characteristic of test-driven development at the unit level?
- Running the full regression suite manually before each commit
- Writing all production code first and generating tests from coverage reports afterwards
- Reviewing test cases with the product owner before any code is written
- Writing a failing test first, then the production code, then refactoring while keeping tests green Correct answer.
Explanation
TDD follows a short red-green-refactor cycle: a test is written that fails, production code is added to make it pass, and the code is then refactored while the tests stay green. This drives design and gives fast feedback. Generating tests after the code, manual regression before commits, or business review of unit tests are different activities.
Question 32Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
An agile team wants fast feedback from its automated checks. Which approach best supports this goal?
- Scheduling all automated tests to run overnight only
- Keeping a fast, focused unit and component suite in the pipeline and running broader suites less frequently Correct answer.
- Increasing the number of manual regression cycles per sprint
- Running the entire end-to-end suite after every single code change
Explanation
Fast feedback comes from running quick, focused checks frequently and reserving slower, broader suites for less frequent runs such as nightly builds. This keeps the pipeline responsive while still providing wider coverage. Running everything on every change or relying on overnight runs delays the signal developers need.
Question 33Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
What is the main purpose of a retrospective in an agile project from a testing perspective?
- To re-estimate the remaining backlog items for the release
- To approve the next sprint's user stories before development starts
- To inspect how the team worked, including testing practices, and agree on improvements Correct answer.
- To demonstrate completed functionality to stakeholders
Explanation
A retrospective is a regular team reflection on process and collaboration, where testing practices, quality problems and tooling can be examined and improved. It produces agreed actions rather than approvals or demonstrations. Story approval, demos and re-estimation belong to other ceremonies.
Question 34Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
A team keeps discovering late in the sprint that stories are much larger than expected. Which agile testing practice would most directly reduce this risk?
- Extending the sprint length for every release
- Freezing the backlog at the start of the sprint
- Splitting large stories into smaller, independently testable slices during refinement Correct answer.
- Adding more testers at the end of the sprint to catch up
Explanation
Small, testable slices allow testing to start earlier and reveal complexity sooner, reducing the chance of late surprises. Refinement is the right point to identify and split oversized stories. Adding testers late, freezing the backlog or lengthening sprints treats symptoms rather than the cause.
Question 35Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
Which statement correctly pairs an agile testing activity with its main purpose?
- Sprint review: inspecting the working increment with stakeholders to gather feedback Correct answer.
- Backlog refinement: running the full regression suite against the release candidate
- Retrospective: demonstrating new features to the product owner
- Daily stand-up: producing the detailed test execution report for the sprint
Explanation
The sprint review inspects the increment with stakeholders so that feedback can shape the backlog. Each other ceremony has a different purpose: the stand-up coordinates daily work, refinement prepares and clarifies backlog items, and the retrospective improves the team's process. Pairing activities with the wrong ceremony confuses their goals.
Question 36Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
A team debates whether to automate a check for a rarely used report with a stable, well-defined output. Which consideration is most relevant to the decision?
- Whether the developer who wrote the report prefers automation
- Whether the report was requested by the product owner
- Whether the report is visually attractive to stakeholders
- How often the check will run and how much manual effort it replaces over time Correct answer.
Explanation
Automation decisions weigh the frequency of execution, the repeatability of the check and the manual effort saved against the cost of building and maintaining the automation. A stable output that is checked often is a good candidate. Aesthetics, personal preference and who requested the feature are not the deciding factors.
Question 37Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
What does continuous integration most directly require of a team's testing approach?
- That testers approve every commit before it is merged
- That integration happen only once per release
- That automated checks run on every integration so broken builds are detected quickly Correct answer.
- That all testing be performed manually before each integration
Explanation
Continuous integration means integrating frequently and verifying each integration with automated checks, so regressions are found within minutes. Slow or manual gates defeat the purpose of frequent integration. Integrating once per release or requiring per-commit tester approval contradicts the practice.
Question 38Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
In agile testing, which phrase best captures the meaning of 'whole-team quality'?
- Quality is guaranteed by a separate independent test department
- Quality is the shared responsibility of everyone in the cross-functional team Correct answer.
- Quality is assessed only at the end of the release by the product owner
- Only testers are accountable for quality, while developers focus on features
Explanation
Whole-team quality means business representatives, developers and testers all contribute to quality throughout delivery rather than delegating it to a separate group. Shared responsibility supports early defect prevention and continuous feedback. Isolating quality in testers, a separate department or a final assessment undermines this principle.
Question 39Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
A tester joins a refinement session for a story about a search filter. Which contribution is most valuable at this stage?
- Requesting that the story be moved to the next release to reduce risk
- Estimating the exact number of defects the story will produce
- Writing the complete automated test script before any criteria exist
- Asking about boundary values, invalid inputs and edge cases that acceptance criteria should cover Correct answer.
Explanation
Refinement is where the team builds shared understanding of what to build and how it will be verified, so a tester's most valuable input is identifying missing scenarios and edge cases for the acceptance criteria. This prevents ambiguity before development starts. Predicting defect counts, scripting prematurely or deferring the story do not improve shared understanding.
Question 40Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
Which technique is most appropriate when an agile team needs to evaluate a complex story with many interacting conditions and limited time for exhaustive scripted tests?
- Relying solely on the existing regression suite
- Waiting for the full specification before starting any testing
- Risk-based exploratory testing guided by charters Correct answer.
- Exhaustive pairwise execution of every possible input combination
Explanation
Risk-based exploratory testing uses charters to focus session-based investigation on the highest-risk areas, which suits complex, fast-changing stories where exhaustive scripting is impractical. It combines learning, design and execution in short cycles. Exhaustive combinations, waiting for specifications or relying only on regression all fail to target new risk efficiently.
Question 41Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
A team's automated checks are frequently red because of environment problems rather than product defects. What is the most useful first improvement?
- Asking testers to rerun the pipeline manually until it passes
- Adding more end-to-end tests to compensate for the instability
- Stabilizing the test environment and separating environment failures from product failures Correct answer.
- Disabling the failing checks so the pipeline turns green
Explanation
When failures come from the environment, the signal is unreliable and the team learns to ignore red builds. Stabilizing the environment and distinguishing infrastructure failures from genuine defects restores trust in the results. Disabling checks, adding more tests or manual reruns hides the problem or amplifies it.
Question 42Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
Which metric best indicates whether an agile team's automated checks give timely feedback on a change?
- The number of testers assigned to the project
- The total number of test cases stored in the repository
- The ratio of manual to automated test documentation pages
- The elapsed time from a commit to the pipeline result for the main suite Correct answer.
Explanation
Feedback speed is measured by how quickly a commit is verified, so the elapsed time from commit to pipeline result is the relevant indicator. Counting stored test cases, counting testers or measuring documentation volume says nothing about how fast the team learns whether a change broke something.
Question 43Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
What is the primary reason agile teams automate regression checks rather than repeat them manually each iteration?
- Automation makes repeated checks cheaper and frees people for exploratory and new-feature testing Correct answer.
- Automation eliminates the need for acceptance criteria
- Automation removes the need for any human judgement about quality
- Automation guarantees that no defects will reach production
Explanation
Regression checks are repeated many times, so automation lowers the marginal cost of each run and releases human effort for exploratory work and testing new features where judgement matters. Automation does not replace human judgement, guarantee defect-free releases or remove the need for acceptance criteria.
Question 44Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
During a sprint, the product owner proposes an additional acceptance criterion that would significantly expand a nearly finished story. What is the most appropriate testing-oriented response?
- Escalate to management to prevent any change to the sprint backlog
- Reject the addition because acceptance criteria cannot change during a sprint
- Accept the addition and quietly extend the tests without adjusting the plan
- Assess the impact on test effort and risk with the team, and agree whether to include it now or in a follow-up story Correct answer.
Explanation
Agile welcomes change, but the team should make its impact visible so the product owner can decide with full information. Assessing test effort and risk and agreeing on scope keeps quality and predictability intact. Silent acceptance, blanket rejection or escalation bypasses the collaboration the team needs.
Question 45Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
Which activity best shows testing being integrated throughout an agile iteration rather than performed only at its end?
- Testers write all test cases after the sprint review
- Testers receive the completed build on the final day of the sprint
- Testers wait for the release candidate before starting any verification
- Testers begin designing and executing checks as soon as slices of a story are available Correct answer.
Explanation
Testing throughout means verification starts as soon as there is something to examine, often slice by slice, so feedback arrives while changes are still cheap. Waiting for a completed build, the sprint review or a release candidate reverts to end-of-cycle testing.
Question 46Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
A team is choosing how to verify a story whose behaviour is well understood, stable and unlikely to change. Which approach is most suitable?
- Scripted, automated checks that can be rerun cheaply on every build Correct answer.
- Open-ended exploratory sessions with no charters
- Deferring verification until the next release
- Relying on users to report problems after deployment
Explanation
Stable, well-understood behaviour is a good fit for scripted automated checks because the expected results are clear and the checks can be repeated cheaply. Exploratory testing is most valuable where understanding is incomplete or risk is high. Deferring verification or relying on users shifts the cost of defects to production.
Question 47Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
In an agile context, what distinguishes a 'test condition' from a 'test case'?
- A test condition applies only to non-functional testing
- A test condition is a specific set of steps and data, while a test case is a general aspect to verify
- A test condition is an aspect to verify, while a test case adds concrete inputs, steps and expected results Correct answer.
- They are identical, and agile teams use the terms interchangeably
Explanation
A test condition identifies something that should be verified, such as a behaviour or quality attribute, while a test case specifies the data, steps and expected result needed to check it. Keeping conditions separate from cases lets teams track coverage before deciding how to test. The terms are not interchangeable and conditions are not limited to non-functional testing.
Question 48Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
A team holds a short 'three amigos' conversation before development. Which outcome most directly justifies the practice?
- A complete set of automated scripts ready before coding starts
- A definitive estimate that cannot be revised
- A shared understanding of the story from business, development and testing perspectives Correct answer.
- A signed approval document that prevents any later change
Explanation
The three amigos bring business, development and testing viewpoints together so ambiguities and missing examples surface before coding. The result is shared understanding and better examples, not a rigid approval, finished scripts or a frozen estimate. Those outcomes would contradict the collaborative and iterative nature of the practice.
Question 49Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
A tester must decide how much test documentation to produce for a fast-changing story. Which principle should guide the decision?
- Produce the same detailed documentation for every story regardless of risk
- Avoid all documentation because agile values working software
- Produce documentation that is just enough to support communication, traceability and future maintenance Correct answer.
- Document only after the release so nothing becomes outdated
Explanation
Agile favors just-enough documentation: enough to communicate decisions, keep useful traceability and support maintenance, without creating waste. Documentation effort should match risk and longevity. Uniform heavy documentation, no documentation at all, or documentation only after release all fail this balance.
Question 50Agile software development (ISTQB CTFL-AT syllabus content, not enumerated in source)
Which situation most clearly indicates that a team should invest in exploratory testing rather than more scripted checks?
- A stable calculation has clear rules and runs on every build
- A compliance rule requires the same check to be evidenced every release
- A new feature has unclear requirements and users report unexpected behaviour in similar areas Correct answer.
- A regression suite already covers all documented behaviour
Explanation
Exploratory testing shines where requirements are unclear and risk is high, because it lets testers learn and adapt while probing unexpected behaviour. Stable rules, existing regression coverage and mandated repeatable evidence are better served by scripted checks. The choice depends on uncertainty and the need for repeatability.