CTFL-AT Certified Tester Foundation Level Agile Tester Questions and Answers

Comprehensive and Detailed Explanation From Exact Extract:

FromCTFL-AT Syllabus v4.0, Section 1.2Fundamentals of Agile Software Development, it states:

"Kanban is a lean approach that uses visualization (typically via a task board) to manage work in progress and improve workflow. Unlike Scrum, iterations in Kanban are optional."

Thus,Option C (Kanban)is correct. It emphasizesvisualizationand doesnot require fixed-length iterations.

Option A (Scrum)is iteration-based.

Option B (Continuous integration)is a practice, not a development approach.

Option D (Slack)is a communication tool, not a methodology.

 Release planning is a process of defining the scope and timeline for an iterative or incremental product development project. It is used in agile or hybrid projects where a mid- to long-term planning of the product or system development or integration is required12. Release planning involves the following activities:

Identifying testable user stories with acceptance criteria. User stories are short descriptions of the features or functionalities that the customer or user wants from the product. Acceptance criteria are the conditions that must be met for the user story to be considered done and acceptable. Identifying testable user stories with acceptance criteria helps to define the scope and quality of the release13.

Prioritizing the user stories. User stories are prioritized based on the value they deliver to the customer or user, as well as the dependencies, risks, and costs associated with them. Prioritizing the user stories helps to determine the order and frequency of the releases13.

Performing high level estimation for the release. High level estimation is a technique to estimate the effort, time, and resources needed to complete the user stories in the release. High level estimation can be done using various methods, such as analogy, expert judgment, planning poker, etc. Performing high level estimation for the release helps to set realistic and achievable goals and deadlines13.

Therefore, activities 1, 3 and 6 are done in release planning. Activities 2, 4 and 5 are done in iteration planning, which is a more detailed and short-term planning of the work to be done in each iteration or sprint13. References: 1: ISTQB® Foundation Level Agile Tester Syllabus, Section 2.2, Fundamental Agile Testing Principles, Practices and Processes1; 2: Agile Release Planning in Hybrid and Agile Projects4; 3: How to Create an Agile Release Plan5

Comprehensive and Detailed Explanation From Exact Extract:

FromCTFL-AT Syllabus v4.0, Section 2.1Acceptance Criteria and Testability, and Section 3.1:

"Acceptance criteria may also address non-functional quality characteristics such as reliability, performance, and usability."

The criterion referencesfailure rate over time, which is areliability attribute, makingOption D (Quality characteristics)the correct answer.

Option A(Scenarios) refers to usage paths.

Option Brefers to functional correctness.

Option Crefers to interface interaction points.

Comprehensive and Detailed Explanation From Exact Extract:

FromCTFL-AT Syllabus v4.0, Section 4.3Test Automation and Continuous Integration, it states:

"Short iterations and continuous integration require well-designed automated test suites, and teams should adopt good practices for test design and implementation from the start."

OptionBis correct because it highlights theneed for proactive test design practicesto handle frequent changes — a key Agile challenge.

Option Amixes concepts:version controlrelates to code, not directly to regression management.

Option Cis incorrect — regressionrisk increaseswhen code is modified.

Option Dis misleading — tests may becomeobsoleteor needrefactoring, sono test is permanently untouchable.

The whole-team approach is a principle of agile testing that involves everyone with different knowledge and skills to ensure project success. The whole-team approach means that the business representatives, testers, and developers work together in every step of the development process, from planning to delivery. The whole-team approach aims to enhance communication and collaboration within the team, leverage the various skill sets of the team members, and make quality everyone’s responsibility12. Therefore, the statement C is the most direct advantage of the whole-team approach, as it captures the essence of the principle and its benefits. The other statements are not directly related to the whole-team approach, or are incorrect. Statement A is about continuous integration, which is a practice of agile development that involves having at least once a day an automated build and test process that detects integration errors early and quickly. Continuous integration is not a direct consequence of the whole-team approach, although it may be facilitated by it13. Statement B is about avoiding requirements misunderstandings, which may be a benefit of the whole-team approach, but not the most direct one. The whole-team approach does not only focus on requirements, but also on design, implementation, testing, and delivery. Moreover, avoiding requirements misunderstandings may also depend on other factors, such as the quality of the user stories, the use of acceptance criteria, and the feedback from the customers and users14. Statement D is incorrect, as it contradicts the whole-team approach. The whole-team approach does not reduce the involvement of business representatives, but rather increases it. Business representatives are an integral part of the whole-team approach, as they provide the vision, the value, and the validation of the product. They collaborate with the testers and developers to define the features, prioritize the backlog, and verify the outcomes12. References: ISTQB Foundation Level Agile Tester Syllabus1, Section 1.2.1, page 9; What is Whole Team Approach in Agile Testing?2, Section What is Whole Team Approach?; Continuous Integration3, Section What is Continuous Integration?; Effective User Stories - 3C’s and INVEST Guide4, Section The 3 C’s (Card, Conversation, Confirmation) of User Stories.

Risk-based testing fits well in Agile development processes, as risks are easy to identify when the work is divided into user stories. User stories are short descriptions of features or functionalities that are valuable to the customers or users. They help to define the scope and priority of the work in each iteration. By breaking down the work into user stories, the Agile team can identify the potential risks associated with each story, such as technical complexity, business criticality, or user feedback. The team can then prioritize the testing effort based on the risk level of each story, ensuring that the most important and risky features are tested first and thoroughly. Risk-based testing also helps to optimize the testing time and resources, as the team can focus on testing the most relevant aspects of the software, rather than testing everything equally. References: ISTQB Foundation Level Agile Tester Syllabus, Section 2.3.2, page 181; ISTQB Foundation Level Agile Tester Sample Exam Questions, Question 2.3.2-1, page 92

Comprehensive and Detailed Explanation From Exact Extract:

FromCTFL-AT Syllabus v4.0, Section 3.2Test-Driven Development, it states:

"Test-Driven Development (TDD) is a practice where test cases are written before the code is developed. Typically, these tests are automated, and the code is written to make the tests pass."

This directly matchesOption A, making it the correct and complete answer.

Let’s review the other options:

Option Bdescribes atest strategy, not TDD.

Option Cis a definition ofAgile software development, not TDD.

Option Ddescribesexploratory testing, not TDD.

Comprehensive and Detailed Explanation From Exact Extract:

FromCTFL-AT Syllabus v4.0, Section 3.2Test-Driven Development, and 1.3The Whole-Team Approach, testers:

"Collaborate in test-related activities including test case creation, exploratory testing, and user story clarification."

"Unit tests are typically the responsibility of developers, especially in TDD practices."

Therefore,Option Aisleast likely, asunit test tracking in TDDis primarily adeveloper responsibility, not a tester's routine task.

Options B, C, and D all describekey Agile tester activities, such asmaintaining regression tests,collaborating with developers, andparticipating in specification workshops (BDD/ATDD practices).

Comprehensive and Detailed Explanation From Exact Extract:

From theCTFL-AT Syllabus v4.0, Section 4.2Continuous Integration, it states:

"Continuous integration involves integrating code into a shared repository several times a day. Each integration is verified by an automated build and automated tests."

Hence,Option D—at least once a day— correctly reflects best practice in continuous integration.

Option A(once per iteration) andB,Care far too infrequent to meet the goals of CI.

The objective is to detect integration issuesearly and often, which is only achievable throughdaily (or more frequent)integrations.

Comprehensive and Detailed Explanation From Exact Extract:

From theISTQB CTFL-AT Syllabus v4.0, Section 1.2The Fundamentals of Agile Software Development, Kanban is explained as:

"In Kanban, work is visualized using a board that shows tasks in various states of progress. The transparency of the workflow helps teams identify bottlenecks, improve flow, and collaborate effectively."

This directly supportsOption C, whereKanban boardsare used for visualizing active tasks — increasingtransparencyandprogress visibility.

Let’s clarify the other options:

Option A: The five values listed —communication, simplicity, feedback, courage, and respect— are associated withExtreme Programming (XP), not Kanban.

Option B: Scrumdoes not prescribe specific testing techniques, but italso does not dictate how development must be done, which makes this atrick answerthat’s partially true butnot complete or precise enoughto be correct.

Option D: The roles areincorrectly named. The correct Scrum roles are:

Product Owner,

Scrum Master,

Developers (Development Team is no longer a formal term post-2020 Scrum Guide)

 A task management tool is a software application that helps agile teams plan, organize, and monitor their work. A task management tool typically allows the team to create, assign, prioritize, update, and track user stories, tests, and other tasks that are part of the agile project. A task management tool can also provide various views and reports to visualize the progress and status of the project, such as Kanban boards, burndown charts, velocity charts, etc. Some examples of task management tools are Jira, Trello, Asana, and Monday.com12345. References: ISTQB® Foundation Level Agile Tester Syllabus, Section 2.1.1, page 13; ASTQB Agile Tester Certification Resources, Section 2.1.1, page 13.

Comprehensive and Detailed Explanation From Exact Extract:

FromCTFL-AT Syllabus v4.0, Section 2.1:

"Acceptance criteria should be testable, meaning they should define expected behavior or measurable outcomes that can be verified."

Option Ais testable because it includesspecific, measurable conditions: response time, user load, and percentage of pages.

Option Bis vague aboutwhich vulnerabilitiesandhow errors are defined.

Option Cusessubjective language("clear and intuitive").

Option Dis vague about what "reasonable accuracy" means.

Comprehensive and Detailed Explanation From Exact Extract:

FromCTFL-AT Syllabus v4.0, Section 5.2Daily Stand-Ups, it states:

"The daily stand-up is a short meeting used to discuss progress, plans for the day, and any impediments that are blocking progress."

Therefore,Option Bis correct — highlightingimpediments/blockersis a key goal of thedaily stand-up.

Option Ais aretrospectiveactivity.

Option Cis done duringplanning or risk assessment, not the daily meeting.

Option Dis part ofiteration planning, not the stand-up.

Comprehensive and Detailed Explanation From Exact Extract:

FromCTFL-AT Syllabus v4.0, Section 3.1Exploratory Testing:

"Exploratory testing benefits from tools that record tester activity, allowing the tester to reproduce and document issues found during unscripted testing sessions."

Option Dis correct —activity capture toolshelp testerslog, replay, and reportfindings effectively in exploratory sessions.

Option Ais for test data preparation, not reporting.

Option Bis related to integration, not exploratory testing.

Option Chelps track tasks but lacks session capture features.

Testers replace developers in writing unit test automation scripts. Comprehensive Explanation: The integration of development and testing activities in Agile projects is based on the principle of cross-functional teamwork, where all team members collaborate and share their skills and knowledge to achieve a common goal. In the context of testing, this means that testing is not seen as a separate activity or phase, but as an integral part of the development process. Therefore, the following sentences are correct:

While developers develop automated unit test scripts, testers write automated system level tests. This is an example of how developers and testers can work in parallel and complement each other’s testing efforts. Developers can focus on testing the internal quality of the code, while testers can focus on testing the external quality of the product.

Developers write acceptance criteria and test cases, together with testers. This is an example of how developers and testers can work together to define and verify the user requirements and expectations. Developers can provide their technical expertise and input, while testers can provide their business and user perspective and feedback.

Developers and testers may work as a pair to develop and test a feature. This is an example of how developers and testers can work closely and interactively to deliver a feature. Developers and testers can exchange ideas, suggestions, and information, and support each other in the coding and testing tasks.

The following sentence is incorrect:

Testers replace developers in writing unit test automation scripts. This is not a valid example of the integration of development and testing activities in Agile projects, because it implies that testers take over the responsibility of developers, rather than collaborate with them. Testers should not replace developers in writing unit test automation scripts, because developers have more knowledge and experience in coding and debugging, and because unit testing is an essential part of the development process. Testers should instead work with developers to ensure that the unit test automation scripts are adequate, effective, and maintainable. References: ISTQB® Foundation Level Agile Tester Syllabus1, Section 1.2.1, page 9; ISTQB® Glossary of Testing Terms2, version 4.0, pages 16 and 55.

 Agile software development is a term that encompasses a group of software development methodologies that are based on iterative incremental development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. Agile methods promote adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourage rapid and flexible response to change. Some examples of agile methods are Scrum, Extreme Programming (XP), Kanban, and Lean Software Development. References:

: ISTQB® Foundation Level Agile Tester Syllabus, Version 2014, Section 1.1.1

: ASTQB Agile Tester Certification Resources, Agile Testing Foundations, Chapter 1, Section 1.1.1

An Agile task board is a visual framework to display and sync up on the tasks moving between production steps. It is usually applied to the two most popular Agile development frameworks — Kanban and Scrum. Used by software developers and project managers, an Agile board helps manage workloads in a flexible, transparent, and iterative way1. An Agile task board provides a detailed visual representation of the whole team’s status, showing which tasks remain to be started, which are in progress, and which are done. It also helps to track the progress of the current sprint, identify bottlenecks, and facilitate collaboration and communication among team members2. References:

: ISTQB® Foundation Level Agile Tester Syllabus, Version 2014, Section 2.1.1

: ASTQB Agile Tester Certification Resources, Agile Testing Foundations, Chapter 2, Section 2.1.1

: 6

The 3C concept of user stories consists of three elements: card, conversation, and confirmation12. The card is a written description of the user story that captures the essence of the feature or functionality from the user’s perspective. The conversation is a dialogue between the product owner and the development team to clarify the details, assumptions, and expectations of the user story. The confirmation is a set of criteria or tests that verify that the user story is implemented correctly and meets the user’s needs12. Therefore, by applying the 3C concept, the correct statement is A, as the conversation should include the acceptance criteria discussion. This will help the team to understand the scope, priority, and value of the user story, as well as the conditions of satisfaction that the product owner expects12. The other statements are incorrect, as they violate the 3C concept. Statement B is wrong, as the card should contain the user story, not the requirements. The user story is a brief and informal way of expressing the user’s goal and benefit, while the requirements are more detailed and specific descriptions of how the software should work. The requirements can be added later as part of the conversation or confirmation12. Statement C is wrong, as the product owner has written a user story, but confirmation is still needed. The confirmation is a vital part of the 3C concept, as it ensures that the user story is testable, measurable, and verifiable. The confirmation also helps to avoid ambiguity, misunderstanding, or disagreement between the product owner and the development team12. Statement D is wrong, as the conversation is required and the team should not start developing without it. The conversation is an essential part of the 3C concept, as it allows the team to ask questions, share ideas, and collaborate with the product owner to refine the user story and reach a shared understanding. The conversation also helps to identify the dependencies, risks, and assumptions that may affect the implementation of the user story12. References: ISTQB Foundation Level Agile Tester Syllabus1, Section 2.2.1, page 16-17; Effective User Stories - 3C’s and INVEST Guide2, Section The 3 C’s (Card, Conversation, Confirmation) of User Stories.

Comprehensive and Detailed Explanation From Exact Extract:

From theCTFL-AT Syllabus v4.0, Section 5.1, it states:

"The team uses the retrospective to review how they worked during the iteration, including planning accuracy and team collaboration, and to identify actionable improvements."

Thus,Option Dis correct — retrospectives help reflect on iterationplanning accuracy, team dynamics, andefficiencyto improve future iterations.

Option Ais incorrect — retrospectives aim to focus on what the teamcan improve, not just on external hindrances.

Option Bis false — Agile retrospectivesrequire follow-up, often in the form ofaction itemstracked in the next iteration.

Option Cis incorrect —Product Ownerand possibly others may contribute, depending on team context.

Comprehensive and Detailed Explanation From Exact Extract:

FromCTFL-AT Syllabus v4.0, Section 2.2Release and Iteration Planning:

"During early phases like Sprint Zero, testers collaborate with the team to identify the product backlog, define high-level test strategies, and contribute to the overall planning and architecture discussions."

Therefore,Option Ais correct — testerscollaborate from the beginning, not as isolated contributors.

Option BandDsuggestindividual work, which isagainst Agile principles.

Option Cis incorrect — the backlog items committed for Sprint 1 are determined duringSprint Planning, not in Sprint Zero.

Cross-functional teamwork is an important organizational and behavioral best practice for a tester in the SCRUM team that should have also been practiced when using the sequential model. Cross-functional teamwork means that all team members, regardless of their functional roles, collaborate and share their skills and knowledge to achieve a common goal. In the context of testing, this means that testing is not seen as a separate activity or phase, but as an integral part of the development process. All team members contribute to testing in various ways, such as:

Involving people with the test strategy, test planning and execution as well as test reporting. This can help ensure that the testing activities are aligned with the business objectives, the user needs, and the technical requirements. It can also help improve the test coverage, the test quality, and the test efficiency.

Sharing the responsibility for testing among the team members. This can help reduce the workload and the dependency on a single tester or a testing team. It can also help increase the feedback and the communication among the team members, and foster a culture of quality and learning.

Leveraging the diverse skills and perspectives of the team members. This can help enhance the test design and the test execution by applying different techniques, tools, and approaches. It can also help identify and address the risks, the issues, and the opportunities for improvement from various angles. References: ISTQB® Foundation Level Agile Tester Syllabus1, Section 1.2.1, page 9; ISTQB® Glossary of Testing Terms2, version 4.0, page 16.