iSQI CTFL-AT Certified Tester Foundation Level Agile Tester Exam Practice Test

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.

Comprehensive and Detailed Explanation From Exact Extract:

FromCTFL-AT Syllabus v4.0, Section 3.4The Testing Quadrants, it states:

"The Agile testing quadrants are used to ensure that the team considers all important test types and levels during an Agile project. The quadrants categorize tests by their purpose (support development, critique the product) and by the type of feedback (business-facing vs technology-facing)."

Thus,Option Ccorrectly reflects theuse and purposeof the quadrants as aguidance tool, not a fixed sequence or hierarchy.

Option AandBare incorrect — the quadrants arenot mapped to strict levels or chronological order.

Option Dis false —risk is not the basis for quadrant numbering.

Continuous integration is a practice of integrating code changes frequently and automatically into a shared repository, and running automated tests to verify the integration. Continuous integration can introduce some risks to the testing process, such as:

Testers sometimes have too many builds to test, which reduces the quality of testing. This can happen when the code changes are too frequent or too large, and the testers do not have enough time or resources to test each build thoroughly. This can lead to missed defects, incomplete test coverage, and reduced confidence in the product quality.

Testers sometimes have to deal with unstable or broken builds, which affects the testability of the product. This can happen when the code changes introduce errors or conflicts that cause the build to fail or malfunction. This can waste the testers’ time and effort, and delay the feedback cycle.

Testers sometimes have to cope with changing requirements and priorities, which affects the test planning and execution. This can happen when the stakeholders or customers provide new or modified requirements or feedback during the development cycle. This can require the testers to adapt their test strategy, test cases, and test data accordingly, and to balance the testing of new features and regression testing of existing features. References: ISTQB® Foundation Level Agile Tester Syllabus1, Section 2.2.3, page 14; ISTQB® Glossary of Testing Terms2, version 4.0, page 15.

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 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 2.4Testing and Iterations, it states:

"In Agile projects, testing activities are conducted in parallel with development activities within an iteration, unlike traditional models where testing is done after development."

Therefore,Option Dis correct — Agile promotesparallel testing, while traditional projects (e.g., V-model) followsequential phases.

Option Ais incorrect — Agile projectsdo perform system testing, but it's integrated within iterations.

Option Bis misleading — while Agile emphasizeslower-level test automation, traditional projects also use automation at various levels.

Option Cis partially correct but oversimplifies the process —risks are reassessed iteratively, not just once during release planning.

 Behavior-Driven Development (BDD) is a software development approach that allows a developer to define accurate unit tests focused on business needs. BDD uses a common language that is understandable by both technical and non-technical stakeholders, such as Given-When-Then scenarios. BDD helps to align the development and testing activities with the customer expectations and business goals . References:

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

: ASTQB Agile Tester Certification Resources, Agile Testing Foundations, Chapter 3, Section 3.2.2

Comprehensive and Detailed Explanation From Exact Extract:

FromCTFL-AT Syllabus v4.0, Section 2.2Release and Iteration Planning, it describes Planning Poker as:

"Planning Poker involves group discussion, especially from the highest and lowest estimators, to ensure that different perspectives and assumptions are aligned, which leads to more accurate and shared understanding of the effort involved."

Thus,Option Cis correct — Team B usesdiscussion-based estimation, which is a corebenefitof Planning Poker.

Option Ais speculative — we cannot know the actual effort difference.

Option Bis incorrect — convergence without discussion may indicatelack of engagement or pressure to agree.

Option Dis false — Planning Poker isnot based on averaging, but onconsensus.

Comprehensive and Detailed Explanation From Exact Extract:

From theCTFL-AT Syllabus v4.0, Section 2.1User Stories and Acceptance Criteria, it states:

"Acceptance criteria are defined collaboratively and refined during the conversation to ensure mutual understanding. They may be added or updated as new insights emerge."

This supportsOption D, which reflects how acceptance criteria evolveduring conversations— a key component of the"Card, Conversation, Confirmation"model.

Option Ais incorrect — the user story istestable, especially with the acceptance criterion.

Option Bis false — the story provides clear user value (printed hard copy for daily records).

Option Cis misleading — the Given-When-Then formatsupportsdiscussions; it doesn’t replace them.

Comprehensive and Detailed Explanation From Exact Extract:

FromCTFL-AT Syllabus v4.0, Section 3.3Behavior-Driven Development, and 3.2Test-Driven Development:

"TDD focuses on writing unit tests that guide the implementation of code."

"BDD focuses on writing scenarios that describe the behavior of the software, often using a language that stakeholders can understand."

Thus,Option Bis accurate — TDD targetscode implementation, BDD targetsbehavioral expectations.

Option Ais incorrect —TDD is at unit level, whileBDD is at the acceptance level.

Option Cis false —BDD is more readable and accessiblefor non-technical stakeholders.

Option Dconfuses BDD withuser story formats; BDD usesGiven-When-Then, not the "As a... I want..." template.

A whole-team approach is a way of working in agile projects where all team members share the responsibility for delivering high-quality software that meets the customer’s needs. This means that testers, developers, business analysts, and other roles collaborate closely throughout the project lifecycle, and use their different skills and perspectives to contribute to the quality of the product. A benefit of this approach is that it enables the team to leverage the various skill sets within the team to the benefit of the project, such as testing skills, coding skills, domain knowledge, user experience, etc. This can lead to faster feedback, better communication, higher productivity, and more innovation. References: ISTQB® Foundation Level Agile Tester Syllabus1, Section 1.1.1, page 7; ASTQB Agile Tester Certification Resources, Section 1.1.1, page 7.

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:

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.

The Test Pyramid is a model for organizing tests in a way to make the process of testing faster, efficient and cost-effective. This model focusses on getting maximum functional testing getting covered by faster and less brittle tests like Unit and API tests1. The main benefit of the Test Pyramid is that it helps in evaluating the amount of test cases needed for each level of testing. The Test Pyramid suggests that the number of test cases should decrease as we move up the pyramid, from unit tests to integration tests to end-to-end tests. This is because unit tests are more granular, isolated, and easy to write and maintain, while end-to-end tests are more complex, dependent, and brittle. The Test Pyramid also helps in balancing the test coverage and the test execution time, as unit tests provide high coverage and low execution time, while end-to-end tests provide low coverage and high execution time. By following the Test Pyramid, teams can optimize their testing efforts and resources, and ensure that they have a sufficient and effective test suite for their software. References: ISTQB® Foundation Level Agile Tester Syllabus, Section 2.2.1, page 16; ASTQB Agile Tester Certification Resources, Section 2.2.1, page 16; What is Test Pyramid : Getting started with Test Automation Pyramid, The Practical Test Pyramid - Martin Fowler, Testing Pyramid: What Is It and How To Use It | Solvd.

An Agile retrospective is a regular meeting where the team reflects on their work process and identifies the areas for improvement12. The following statements about Agile retrospectives are correct12:

During Agile retrospectives, testers should be encouraged to provide constructive suggestions on both testing and non-testing activities, as testing is an integral part of the Agile team and testers can contribute to the overall quality of the product and the process.

In an Agile retrospective, the moderator can encourage and make sure that good practices are kept by the team, by asking what the team is doing well. This helps to reinforce the positive aspects of the team’s work and to appreciate the team members’ efforts and achievements.

Agile retrospectives should be focused mainly on impediments that are within the control of the team because these issues are more actionable and can be resolved by the team. Impediments that are outside the control of the team should also be discussed, but they may require the involvement of other stakeholders or external parties to be addressed.

The following statement about Agile retrospectives is incorrect12:

Unlike working sessions or meetings held in non-Agile projects, Agile retrospectives do require follow-up activities. The team should agree on the action items that result from the retrospective and assign them to the responsible team members. The team should also monitor the progress and effectiveness of the action items in the next iteration and review them in the next retrospective.

Therefore, the correct answer is B, as it is the only statement that is correct about Agile retrospectives. References: ISTQB Foundation Level Agile Tester Extension Syllabus1, page 24; ISTQB Agile Tester Sample Exam2,

The acceptance criteria for a sprint are the conditions that must be met for the user stories to be considered done and deliver value to the customer1. The acceptance criteria should be specific, measurable, achievable, relevant, and testable2. In this case, the plan for the sprint is to increase performance of the system, so the acceptance criteria should reflect that goal. Therefore, the acceptance criteria that would be expected for Sprint 5 are:

100% of the existing regression test suite has passed. This criterion ensures that the system has not introduced any new defects or broken any existing functionality while improving performance3.

System is responding in less than 3 seconds, 90% of the time. This criterion defines a clear and quantifiable performance target that can be verified by testing4.

The other options are not relevant or appropriate acceptance criteria for Sprint 5:

User access for all roles has been validated. This criterion is not related to the performance of the system, but rather to the security or functionality of the system. It might be an acceptance criterion for a different sprint or user story, but not for Sprint 55.

A static analysis tool has been executed for all code. This criterion is not a customer

Comprehensive and Detailed Explanation From Exact Extract:

FromCTFL-AT Syllabus v4.0, Section 2.4Testing and Iterations, it states:

"In Agile projects, developers and testers work together to ensure the correct functionality is delivered during the iteration. Business representatives and testers may also validate the software during development to provide quick feedback."

This confirms thatOption Dis correct —collaborative testingby stakeholders and testers during development is a core Agile practice.

Option Ais incorrect — testing doesnot waitfor "done"; it occursconcurrentlywith development.

Option Bmisrepresents Agile — performance isn't based on metrics like defect counts.

Option Cis true in general, butdoes not directly answerthe integration of testing and development activities.

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.

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.

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).

 Equivalence partitioning is a black-box test design technique that divides the input domain of a system into classes of data from which test cases can be derived. The idea is that if a system works correctly for a representative value from an equivalence class, it will work correctly for all values from that class, and vice versa. Equivalence partitioning reduces the number of test cases by eliminating redundant ones. For the given user story, equivalence partitioning is the most suitable technique because it can test the different outcomes of the annual car tax calculation based on the power of the vehicle, which is the main input for the system. By testing one value from each partition, the tester can verify the functionality of the system and detect any errors in the calculation logic. The other techniques are not as suitable because they do not focus on the input domain of the system, but rather on the conditions, transitions, or scenarios that are not directly related to the user story. References:

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

: ASTQB Agile Tester Certification Resources, Agile Testing Foundations, Chapter 3, Section 3.2.2

: 3

The test charter for the exploratory testing session is focused on buying a bus ticket, not a parking ticket. Therefore, any defect related to the payment for parking ticket is out of scope for the given test charter. The other defects are related to the functionality, usability, or reliability of buying a bus ticket, which are in scope for the test charter. References: ISTQB Certified Tester Foundation Level Agile Tester Extension Syllabus, Version 2014, Section 2.3.2 Exploratory Testing1, Section 2.3.2.1 Test Charter2; ISTQB Glossary of Testing Terms, Version 3.2, 2017, Definition of Test Charter3

1: ISTQB Certified Tester Foundation Level Agile Tester Extension Syllabus, Version 2014, Section 2.3.2 Exploratory Testing 2: ISTQB Certified Tester Foundation Level Agile Tester Extension Syllabus, Version 2014, Section 2.3.2.1 Test Charter 3: [ISTQB Glossary of Testing Terms, Version 3.2, 2017, Definition of Test Charter]

Comprehensive and Detailed Explanation From Exact Extract:

FromCTFL-AT Syllabus v4.0, Section 2.5Testers and Independence, it states:

"Testers may be assigned to Agile teams on a permanent or rotating basis. While full independence is compromised, this setup allows for better collaboration and understanding of the product, while still maintaining some degree of independence."

Thus,Option Bis the most accurate —long-term embedded testerssupport Agile collaboration while preservingpartial independence.

Option Aleads tolate involvement, which contradicts Agile principles.

Option Csacrifices independence entirely.

Option Dis traditional and contrary to Agile values of collaboration.

Independence in testing is the degree of separation between the person who tests something and the person who developed it. Independence can help to reduce bias, increase objectivity, and provide different viewpoints. However, independence also has some drawbacks, such as increased communication overhead, reduced collaboration, and delayed feedback. In agile projects, testers are usually embedded in the agile teams to perform many of the testing tasks, such as unit testing, integration testing, acceptance testing, etc. This provides a high level of collaboration and fast feedback, but also reduces the independence of the testers. Testers from an independent test team who do not get involved with the agile team, but are assigned to do System Testing once all sprints are completed, would provide the most independence for testers working with agile teams. However, this would also introduce many disadvantages, such as lack of alignment with the agile principles, loss of context and domain knowledge, delayed defect detection and resolution, and increased risk of missing customer expectations. References: ISTQB® Foundation Level Agile Tester Syllabus, Section 1.1.2, page 8; ASTQB Agile Tester Certification Resources, Section 1.1.2, page 8.