ISTQB CTFL-AT Certified Tester Foundation Level Agile Tester Exam Dumps and Practice Test Questions Set 3 Q41-60

Visit here for our full ISTQB CTFL-AT exam dumps and practice test questions.

Question 41: 

Which of the following best describes the purpose of the Agile principle “responding to change over following a plan”?

A) Teams should ignore planning activities entirely
B) Teams must adapt to changing requirements even late in development
C) Teams must follow the initial plan strictly
D) Teams only consider changes during sprint planning

Answer: B) Teams must adapt to changing requirements even late in development

Explanation:

Option A suggests that teams should ignore planning activities entirely. This is a misunderstanding of Agile principles. Agile does not eliminate planning; rather, it emphasizes adaptive and iterative planning. Teams still conduct planning sessions to define goals, priorities, and deliverables, but the plan is flexible and continuously refined based on feedback, evolving requirements, and stakeholder input. Ignoring planning altogether would likely result in chaotic development with unclear priorities and misaligned expectations, which is contrary to the purpose of Agile.

Option B is correct because Agile prioritizes responding to change over strictly adhering to a plan. In Agile environments, requirements, business priorities, and market conditions can evolve rapidly, and teams must be prepared to adapt even late in the development process. This principle ensures that the product continues to deliver maximum value to customers and stakeholders, and that development effort is not wasted on outdated requirements. Agile frameworks, such as Scrum and Kanban, support iterative cycles, continuous feedback, and adjustment of scope, which directly aligns with this principle.

Option C, following the initial plan strictly, is antithetical to Agile thinking. A rigid adherence to a plan assumes that requirements and conditions are static, which is rarely true in real-world projects. By focusing solely on a pre-defined plan, teams risk delivering features that no longer match current user needs or business priorities, leading to inefficiency and reduced stakeholder satisfaction. Agile promotes adaptability and responsiveness to maintain relevance and value throughout the project lifecycle.

Option D suggests that teams only consider changes during sprint planning. While sprint planning is indeed a structured opportunity to review priorities and incorporate new information, Agile encourages continuous adaptation throughout the iteration. Feedback from stakeholders, product demonstrations, and testing insights can prompt necessary adjustments at any point. Limiting responsiveness to formal planning sessions undermines the principle of flexibility and continuous value delivery, which is why this option is incorrect.

The reasoning for selecting B is that Agile’s core philosophy centers on adaptability. Responding to change over following a rigid plan allows teams to adjust to evolving requirements, stakeholder feedback, and unforeseen risks. By embracing this principle, Agile teams maintain alignment with business goals, optimize resource utilization, and ensure that delivered features remain valuable. This iterative, flexible approach is what distinguishes Agile from traditional plan-driven methodologies, enabling teams to deliver high-quality products efficiently while accommodating change.

Question 42: 

Which Agile testing approach uses predefined business rules to generate tests automatically?

A) Risk-Based Testing
B) Model-Based Testing
C) Exploratory Testing
D) Ad-hoc Testing

Answer: B) Model-Based Testing

Explanation:

Option A, Risk-Based Testing, focuses on prioritizing testing efforts based on the potential impact and likelihood of defects. While risk-based testing helps teams allocate resources effectively and optimize coverage, it does not automatically generate test cases from predefined models or business rules. Instead, it emphasizes strategic decision-making about where testing effort is most needed.

Option B is correct because Model-Based Testing uses abstract models of system behavior, workflows, or business rules to automatically generate test cases. These models can include state machines, decision tables, or process flows, enabling broad and systematic coverage without manual effort for each individual test. This approach aligns with Agile’s iterative and automated testing philosophy, as it accelerates test creation, reduces human error, and ensures consistency while allowing testers to focus on exploratory and value-driven testing activities.

Option C, Exploratory Testing, is fundamentally human-driven, relying on tester creativity, intuition, and skill to uncover defects. While exploratory testing is crucial for uncovering unexpected behaviors and validating real-world usage scenarios, it is not model-driven and does not produce automated tests from predefined business rules.

Option D, Ad-hoc Testing, is informal, unstructured, and unscripted. It lacks predefined procedures or models and is typically performed to quickly verify functionality or reproduce defects. While useful for flexibility, ad-hoc testing does not provide the systematic and automated generation of test cases that Model-Based Testing offers.

The reasoning for selecting B is that Model-Based Testing allows Agile teams to combine automation with intelligent test generation. It supports iterative development by enabling rapid creation and maintenance of tests aligned with business rules, reducing manual effort, and ensuring coverage of critical functionality. In fast-paced Agile environments, this approach increases efficiency, consistency, and confidence in quality delivery while complementing other testing practices like exploratory and risk-based testing.

Question 43: 

Which Agile practice focuses on building quality into the development process rather than relying on inspection later?

A) Shift-left testing
B) Regression Testing
C) Smoke Testing
D) User Acceptance Testing

Answer:  A) Shift-left testing

Explanation:

Option A, Shift-left testing, is correct because it emphasizes integrating testing early in the development lifecycle. By conducting activities such as requirements validation, unit testing, and continuous feedback early, teams proactively identify and address defects before they escalate. This reduces rework costs, improves product quality, and aligns with Agile principles of iterative development and continuous improvement. Shift-left testing ensures quality is embedded in the process rather than retrofitted after implementation.

Option B, Regression Testing, focuses on verifying that existing functionality remains intact after changes. While important for quality assurance, it is reactive in nature and occurs after code is implemented, making it insufficient as a proactive strategy for embedding quality throughout development.

Option C, Smoke Testing, provides a quick check to ensure the stability of a build. It helps identify critical failures early but does not replace comprehensive early testing or ensure quality is designed into features from the start.

Option D, User Acceptance Testing, validates whether the product meets business requirements and stakeholder expectations. While crucial, it typically occurs late in the development process, meaning defects discovered at this stage may be more costly to address and do not contribute to proactive quality integration.

The reasoning for selecting A is that Agile encourages building quality into every stage of development. Shift-left testing aligns with continuous integration and continuous testing practices, promoting early feedback, faster defect detection, and reduced rework. By focusing on early testing, teams can improve overall product quality and maintain an iterative workflow that supports incremental delivery of value.

Question 44: 

What is the primary goal of risk-based testing in Agile?

A) Testing all features equally
B) Focusing testing efforts on areas with the highest risk of failure
C) Eliminating exploratory testing
D) Replacing automated testing

Answer: B) Focusing testing efforts on areas with the highest risk of failure

Explanation:

Option A, testing all features equally, is inefficient. Not all features carry the same risk or business impact. Testing every feature with equal intensity wastes resources, increases costs, and may result in critical areas being under-tested.

Option B is correct because risk-based testing prioritizes testing activities based on the potential impact and likelihood of failure. Features or components with the highest risk receive the most attention, optimizing the use of limited testing resources. By focusing on high-risk areas, teams can ensure that critical functionality is reliable and defects are mitigated before release.

Option C, eliminating exploratory testing, is incorrect because risk-based testing complements exploratory testing rather than replacing it. Exploratory testing provides coverage for unexpected or emergent behaviors that risk models may not predict.

Option D, replacing automated testing, is also incorrect. Risk-based testing can leverage automation for efficiency but does not substitute for it. Automated tests can be applied strategically to high-risk areas to maximize return on testing investment.

The reasoning for selecting B is that Agile emphasizes efficient value delivery and risk management. By directing testing toward areas with the highest probability of failure or greatest impact on business goals, risk-based testing helps teams improve quality, reduce critical defects, and ensure stakeholder confidence. It balances time, effort, and value, making it a core practice in iterative and adaptive development.

Question 45: 

Which of the following best describes “story points” in Agile?

A) The number of hours a task takes
B) A relative measure of effort or complexity for a user story
C) A count of defects in the system
D) The priority assigned to a user story

Answer: B) A relative measure of effort or complexity for a user story

Explanation:

Option A, the number of hours a task takes, is a common misconception. Story points are intentionally abstract and relative, not tied to exact time estimates. They provide a consistent measure across the team without conflating effort with specific hours, which can vary between individuals and tasks.

Option B is correct. Story points estimate the relative effort, complexity, and uncertainty of a user story. Teams consider factors such as technical complexity, potential risks, dependencies, and unknowns when assigning story points. This approach enables better sprint planning, velocity tracking, and forecasting, supporting Agile’s iterative and adaptive processes.

Option C, a count of defects, is unrelated to story points. While defect tracking is important for quality management, it is separate from estimating the effort required for feature development.

Option D, the priority assigned to a story, is determined by the Product Owner based on business value and stakeholder needs. Story points measure effort, not priority, allowing teams to focus on planning and delivery capacity without conflating effort with value.

The reasoning for selecting B is that story points provide a relative, flexible, and abstract method for estimating work. They facilitate consistent planning, velocity measurement, and iterative delivery, while avoiding the pitfalls of time-based estimation. Story points help teams plan sprints realistically, balance workload, and track progress effectively, supporting Agile principles of adaptive planning and continuous improvement.

Question 46: 

Which of the following describes the primary purpose of an Agile release plan?

A) To dictate detailed implementation tasks for developers
B) To provide a high-level roadmap of deliverables and iterations
C) To replace daily stand-ups
D) To track defects

Answer: B) To provide a high-level roadmap of deliverables and iterations

Explanation:

Option A is incorrect because Agile release plans are not meant to dictate the granular implementation tasks that developers carry out. Detailed tasks are managed at the sprint or iteration level within the sprint backlog. The release plan focuses on providing a broader view of objectives, milestones, and timelines rather than micromanaging day-to-day activities. While detailed planning is essential, Agile promotes adaptability, and prescribing exact tasks in a release plan would reduce flexibility.

Option B is correct. The primary purpose of an Agile release plan is to offer a high-level roadmap that outlines expected deliverables, the sequence of iterations, and key milestones. This allows stakeholders and team members to understand the general trajectory of the product development and facilitates alignment of expectations across business and technical teams. The release plan does not remain static; it is continuously updated to reflect changing requirements, new priorities, or insights gained during iterations. By providing this roadmap, teams can prioritize work effectively, manage stakeholder expectations, and ensure that the product evolves incrementally while remaining focused on delivering value.

Option C is incorrect because release plans do not replace daily stand-ups. Daily stand-ups are short, time-boxed meetings where team members coordinate work, discuss obstacles, and synchronize daily activities. They focus on operational coordination at the team level, whereas release plans operate at a strategic level. The two serve different purposes: one is tactical, and the other is strategic, and they complement each other rather than substitute for one another.

Option D is also incorrect. Tracking defects is typically managed through dedicated tools or defect tracking systems and does not fall under the scope of a release plan. While the release plan may indirectly influence quality planning or highlight areas for testing, its focus is on what will be delivered, when, and in what sequence. Tracking and managing defects is a separate activity to ensure product quality and is not the defining purpose of release planning.

The reasoning for selecting option B is that Agile emphasizes delivering value iteratively and adapting to change. A high-level roadmap allows teams to plan deliverables over multiple iterations while remaining flexible to respond to new feedback. It communicates a shared vision, provides transparency to stakeholders, and ensures that development progresses toward strategic goals without constraining the team with overly detailed prescriptive instructions.

Question 47: 

Which testing technique is most suitable for validating business rules and workflows without requiring full system implementation?

A) Unit Testing
B) Simulation/Mock Testing
C) Performance Testing
D) Regression Testing

Answer: B) Simulation/Mock Testing

Explanation:

Option A, unit testing, is not fully appropriate for this purpose. Unit testing is focused on verifying the correctness of individual code components in isolation. While it is essential for ensuring low-level functionality, it does not address broader workflows or business rules that span multiple system components. Unit testing is valuable but does not simulate interactions between components that may not yet exist or are not integrated.

Option B is correct. Simulation or mock testing uses artificial components to represent parts of the system that are either incomplete or unavailable. This approach allows teams to validate complex business rules and workflows early in the development process, providing feedback without waiting for the entire system to be implemented. By using mocks or stubs, Agile teams can identify defects, clarify requirements, and ensure that workflows behave as expected. This is especially valuable in iterative development environments where components are continuously evolving, enabling testing to occur in parallel with development.

Option C, performance testing, focuses on evaluating system performance under load, stress, or volume conditions. While this testing is crucial for assessing response times, scalability, and stability, it does not inherently validate business rules or functional workflows. Conducting performance tests before implementation of key components would not yield meaningful results, making this option unsuitable for early validation of business logic.

Option D, regression testing, is designed to confirm that previously implemented functionality continues to work as expected after changes. Regression testing presumes that functionality already exists and is integrated, which is not the case when testing incomplete workflows or unimplemented components. It is therefore not applicable for validating business rules without full system implementation.

The reasoning for selecting option B is that simulation or mock testing aligns with Agile principles of early feedback, iterative development, and risk reduction. It allows teams to validate business logic and workflows before full system availability, reducing integration issues later. By providing actionable insights during early iterations, mock testing ensures that both developers and business stakeholders have confidence in system behavior and can adapt requirements efficiently.

Question 48: 

Which of the following best describes a “potentially shippable increment”?

A) Any piece of code written during a sprint
B) A fully tested, integrated, and ready-to-release product increment
C) A test case executed in the sprint
D) A backlog item not yet developed

Answer: B) A fully tested, integrated, and ready-to-release product increment

Explanation:

Option A is incorrect because code alone does not constitute a shippable increment. Code written during a sprint may be incomplete, untested, or not integrated, and therefore cannot reliably deliver value to stakeholders. Shippability requires more than just writing code; it requires functionality to be verified, integrated, and potentially deployable.

Option B is correct. A potentially shippable increment represents a piece of the product that is complete, fully tested, integrated with previous increments, and ready for release if needed. Agile promotes delivering tangible value in each iteration, and ensuring increments are potentially shippable allows for early feedback, stakeholder validation, and continuous improvement. It also reduces risks associated with late integration and ensures the product remains in a releasable state at all times.

Option C is incorrect. While test cases are essential to verifying functionality, executing a test case is not equivalent to delivering a functional, integrated product increment. Testing supports the creation of a shippable increment but is not the increment itself.

Option D is also incorrect. Backlog items that have not yet been developed do not provide value and therefore cannot be considered shippable increments. These items represent planned work, not deliverable outputs.

The reasoning for selecting option B is that Agile emphasizes iterative delivery and rapid feedback. Delivering fully tested, integrated increments ensures stakeholders see measurable progress and allows teams to adapt to feedback quickly. It also upholds Agile principles of quality, collaboration, and responsiveness, making the concept of a “potentially shippable increment” central to Agile development.

Question 49: 

Which of the following is the main benefit of having a cross-functional Agile team?

A) Reduces the need for communication
B) Ensures all skills needed to deliver work are within the team
C) Eliminates the need for Product Owner involvement
D) Focuses only on coding tasks

Answer: B) Ensures all skills needed to deliver work are within the team

Explanation:

Option A is incorrect because cross-functional teams do not reduce communication; in fact, they encourage collaboration among team members with diverse skills. Effective communication is crucial for coordinating tasks, resolving dependencies, and sharing knowledge across roles. Agile relies on high levels of interaction, and cross-functional teams facilitate this by bringing necessary skills together.

Option B is correct. Cross-functional teams are designed to have all the skills needed to complete work within the team. This includes developers, testers, designers, and sometimes analysts. By containing the required capabilities, the team can deliver complete increments independently within a sprint. This promotes self-organization, faster delivery, and reduced reliance on external dependencies, which aligns with Agile principles of empowerment and iterative delivery.

Option C is incorrect because the Product Owner remains essential for prioritization, requirement clarification, and stakeholder communication. Cross-functional teams do not remove the need for a Product Owner; they work closely with them to ensure work aligns with business goals.

Option D is also incorrect. Cross-functional teams handle more than coding; they perform analysis, design, testing, and delivery activities. Limiting focus to coding would undermine the purpose of cross-functionality and prevent the team from delivering complete increments.

The reasoning for selecting option B is that having all necessary skills within the team ensures efficiency, accountability, and rapid delivery of value. Cross-functional teams can operate autonomously, adapt quickly to changes, and maintain high quality without waiting for external resources. This is a key tenet of Agile, emphasizing collaboration and self-organized teams.

Question 50: 

Which of the following is the primary purpose of the Agile principle “individuals and interactions over processes and tools”?

A) To eliminate all processes and tools
B) To value communication and collaboration above rigid processes
C) To reduce documentation entirely
D) To focus only on tools for automation

Answer: B) To value communication and collaboration above rigid processes

Explanation:

Option A is incorrect. Agile does not eliminate processes or tools entirely. Instead, it promotes flexibility, using processes and tools as enablers rather than strict rules. Removing them completely would hinder productivity and governance.

Option B is correct. The principle emphasizes the importance of effective communication, collaboration, and teamwork over strict adherence to predefined processes or reliance on tools. Agile encourages direct interaction, shared understanding, and problem-solving among individuals to ensure that work is guided by collective knowledge and real-time feedback rather than rigid procedures.

Option C is incorrect. While Agile reduces excessive documentation, it does not eliminate documentation entirely. Documentation is kept lightweight and focused on delivering value, but it complements communication rather than replaces it.

Option D is incorrect because tools are secondary to people. Tools facilitate automation, testing, and reporting, but they cannot replace human judgment, collaboration, or knowledge sharing.

The reasoning for selecting option B is that Agile thrives on empowering individuals, fostering communication, and promoting collaboration. Prioritizing interactions over rigid processes ensures that teams can respond flexibly to change, share knowledge effectively, and align work with customer needs. This principle is foundational to Agile’s iterative, adaptive, and human-centered approach.

Question 51: 

Which of the following best describes a sprint goal?

A) A detailed technical plan for the sprint
B) A short, concise objective guiding the sprint work
C) A list of defects to be fixed
D) A roadmap for the entire project

Answer: B) A short, concise objective guiding the sprint work

Explanation:

Option A, a detailed technical plan for the sprint, is often confused with the sprint goal because both are important for sprint execution. However, the technical plan belongs to the sprint backlog rather than the goal itself. The sprint backlog contains the actionable tasks, detailed steps, and technical details the team will use to deliver value, but it does not communicate the overarching objective of the sprint. The sprint goal is meant to guide decisions and priorities rather than act as a prescriptive set of instructions. While a technical plan is essential for organizing work, it does not provide the shared purpose or vision for the team during the sprint.

Option C, a list of defects to be fixed, focuses on maintenance and corrective activities. Although addressing defects may be part of the sprint, such a list does not capture the sprint’s intent or strategic value. A sprint goal is forward-looking and outcome-oriented, highlighting what the team aims to achieve rather than merely cataloging items that need repair. Simply listing defects would not provide clarity about the value delivered to stakeholders or the alignment with product priorities. A sprint goal goes beyond technical details to establish what success looks like in terms of business or user impact.

Option D, a roadmap for the entire project, refers to long-term planning and high-level vision for the product. Roadmaps typically span months or even years and provide guidance on feature sequencing and strategic milestones. In contrast, a sprint goal is specific to a short timebox—usually 1–4 weeks—and gives the team a clear focus for that sprint. While roadmaps help align sprints with broader objectives, they do not communicate the actionable purpose of a single sprint, which is why a roadmap cannot substitute for a sprint goal.

Option B is correct because it encapsulates the essence of the sprint goal: a concise, clear statement of the objective the team aims to achieve during the sprint. The sprint goal provides guidance for decision-making, prioritization, and scope adjustments. It communicates value to stakeholders, fosters alignment among team members, and helps evaluate whether the increment produced meets the intended purpose. By focusing the team on a shared objective, the sprint goal also enables more meaningful discussions during sprint review and retrospective sessions, promoting continuous improvement and value delivery. In Agile practice, having a well-defined sprint goal enhances cohesion, ensures clarity in purpose, and allows teams to adapt as challenges arise during the sprint while keeping the desired outcome in sight.

Question 52: 

In Agile, which activity primarily helps the team improve their processes?

A) Sprint Planning
B) Sprint Retrospective
C) Daily Stand-up
D) Sprint Review

Answer: B) Sprint Retrospective

Explanation:

Option A, Sprint Planning, is focused on determining what work will be accomplished during the upcoming sprint. While planning can indirectly highlight process issues if tasks are unclear or estimation is inconsistent, its primary purpose is setting the sprint backlog, not analyzing or improving team practices. Planning sessions are about execution and prioritization rather than reflection, so they are not the main vehicle for process improvement.

Option C, Daily Stand-up, is a brief synchronization meeting for coordinating daily work, identifying blockers, and sharing progress. Although teams may identify impediments during stand-ups, these meetings are short and primarily operational. Stand-ups do not provide dedicated time for deep discussion of process inefficiencies, root causes, or long-term improvement actions, which makes them insufficient for the systematic improvement of team processes.

Option D, Sprint Review, is oriented toward the product increment and stakeholder feedback. Its purpose is to inspect the output and gather input from users or stakeholders to influence future backlog items. While improvements in product quality may arise from review discussions, the session is not designed for analyzing internal team processes, collaboration patterns, or workflow inefficiencies. Process improvement is incidental rather than the main goal of the sprint review.

Option B is correct because the Sprint Retrospective explicitly focuses on process improvement. During this session, the team reflects on what went well, what did not, and what can be changed in future sprints. This structured reflection allows for identification of inefficiencies, communication gaps, or tooling issues and results in actionable steps to enhance productivity, collaboration, and quality. Retrospectives foster continuous improvement, accountability, and shared ownership of team practices. By iteratively examining processes, the team builds stronger workflows, improves velocity, and promotes a culture of transparency and learning, which aligns perfectly with Agile principles of adaptability and continuous delivery.

Question 53: 

Which Agile testing technique focuses on exploring the system to discover defects without predefined scripts?

A) Regression Testing
B) Exploratory Testing
C) Automated Testing
D) Load Testing

Answer: B) Exploratory Testing

Explanation:

Option A, Regression Testing, is a technique that ensures existing functionality continues to work as expected after changes. While regression testing is important for maintaining stability, it relies on predefined test cases rather than adaptive, unscripted exploration. It is structured and repetitive, focusing on confirming known behavior rather than discovering new defects, which makes it distinct from exploratory testing.

Option C, Automated Testing, involves using scripts and tools to validate behavior or performance. Automation is efficient and repeatable but is limited to scenarios defined in advance. Automated tests are predictable and provide quick feedback but do not allow testers to exercise creativity or respond spontaneously to unexpected behavior, which is a hallmark of exploratory testing.

Option D, Load Testing, evaluates system performance under heavy usage. It is primarily concerned with scalability, response times, and system stability under stress. While valuable, it is not aimed at discovering functional defects or enabling human-driven exploration of features and workflows. Its focus is performance rather than defect discovery in everyday usage scenarios.

Option B is correct because Exploratory Testing emphasizes simultaneous learning, test design, and execution. Testers actively explore the system, leveraging intuition, domain knowledge, and creativity to uncover defects that may not be anticipated by predefined scripts. In Agile contexts, where requirements evolve quickly and time is constrained, exploratory testing is particularly valuable for uncovering hidden issues and providing rapid feedback. It complements automated tests by addressing gaps in scripted coverage and enhancing overall quality, aligning perfectly with Agile’s emphasis on adaptability, collaboration, and continuous learning.

Question 54: 

Which of the following is a primary purpose of the Definition of Done (DoD)?

A) Prioritize backlog items
B) Specify when work is complete and ready for release
C) Document team communication
D) Replace acceptance criteria

Answer: B) Specify when work is complete and ready for release

Explanation:

Option A, prioritizing backlog items, is typically the Product Owner’s responsibility and does not relate to the Definition of Done. While DoD ensures work is ready for delivery, it does not guide which items are more important or should be selected for a sprint. Prioritization and DoD serve different purposes in Agile; one is about order and focus, the other about completion standards.

Option C, documenting team communication, is also unrelated. Effective communication is vital, but DoD does not serve as a communication log or record. It defines completion criteria to ensure transparency and shared understanding but does not capture interpersonal or procedural communication explicitly.

Option D, replacing acceptance criteria, is incorrect because DoD complements acceptance criteria rather than replacing them. Acceptance criteria define conditions for user story fulfillment from a functional perspective, while DoD defines organizational or quality criteria for completeness, including testing, integration, and review. Both work together to ensure product quality.

Option B is correct because the Definition of Done provides a clear, shared understanding among all team members about what constitutes a finished increment. It ensures work meets quality standards and is potentially shippable. By clarifying expectations upfront, DoD reduces ambiguity, aligns team efforts, and promotes consistency. Teams use it as a checklist to verify completeness across development, testing, and documentation, enabling predictable, reliable delivery of high-quality increments. It supports transparency, accountability, and stakeholder confidence, ensuring that what is delivered is truly “done” according to agreed standards.

Question 55: 

Which Agile practice emphasizes integrating code changes frequently and running automated tests to detect issues early?

A) Continuous Integration
B) Regression Testing
C) Exploratory Testing
D) Load Testing

Answer: A) Continuous Integration

Explanation:

Option B, Regression Testing, validates that existing functionality continues to work after changes. While regression tests are often automated and used in CI pipelines, regression testing alone does not inherently involve frequent integration of code or early detection of integration issues. It is reactive rather than proactive in preventing defects from propagating.

Option C, Exploratory Testing, is human-driven and focuses on creative discovery of defects. It does not require frequent integration or automated builds and is primarily concerned with uncovering unknown issues through manual exploration. While it adds value, it is not a process aimed at continuous feedback on integrated code.

Option D, Load Testing, evaluates system behavior under stress. It is important for performance assessment but does not emphasize frequent integration or early detection of functional defects. Load testing is executed periodically, not continuously, and focuses on scalability rather than code correctness or team workflow.

Option A is correct because Continuous Integration is a practice where developers frequently merge code into a shared repository, triggering automated builds and tests. This early and frequent integration identifies issues immediately, reduces integration risks, and ensures that the codebase remains stable. CI encourages small, incremental changes, supporting fast feedback loops and improving overall quality. It is central to Agile principles because it enables teams to deliver potentially shippable increments continuously, aligns with iterative development, and provides confidence that new changes do not break existing functionality. By combining integration with automated testing, CI ensures efficiency, reliability, and early defect detection, which are essential in fast-paced Agile environments.

Question 56: 

Which Agile artifact is a prioritized list of features or user stories for the product?

A) Sprint Backlog
B) Product Backlog
C) Burndown Chart
D) Definition of Done

Answer: B) Product Backlog

Explanation:

Option A, the Sprint Backlog, refers to a subset of work items that the team commits to completing during the current sprint. It includes tasks, user stories, and sub-tasks that have been pulled from the product backlog for implementation. While it provides a short-term plan, it is not a comprehensive list of all product features. It is more tactical in nature, focusing on immediate delivery rather than strategic prioritization of the overall product.

Option B, the Product Backlog, is the correct choice. The product backlog represents the dynamic and prioritized list of everything that might be needed in the product, including features, enhancements, bug fixes, technical work, and knowledge-gathering activities. Each backlog item is ordered based on business value, risk, dependencies, and stakeholder input. The product backlog is continuously refined during backlog grooming sessions to reflect changing priorities, newly discovered requirements, or evolving market conditions. By providing a single source of truth for all work to be delivered, it ensures that the team is always focused on the most valuable items, supporting Agile’s iterative and incremental delivery approach.

Option C, the Burndown Chart, is a visual representation of work remaining versus time during a sprint or release. While it provides a measure of progress and helps teams identify trends in completion, it does not contain requirements or features to be delivered. It serves as a monitoring tool rather than a planning artifact, providing insights into team performance and helping with sprint adjustment but not guiding what to build next.

Option D, the Definition of Done, is a shared agreement that specifies what it means for a backlog item to be considered complete. It establishes quality criteria, testing requirements, and integration expectations. While crucial for ensuring a common understanding of completion, it does not contain or prioritize features or user stories. It complements the backlog by defining the quality standard that all deliverables must meet, rather than guiding the selection or prioritization of work.

The product backlog is correct because it is the only artifact that provides a complete, prioritized list of desired product functionality. It drives transparency, stakeholder collaboration, and iterative development. By continuously grooming and adjusting the backlog, teams can respond to changes, balance value delivery, and ensure that development efforts focus on high-priority items.

Question 57: 

Which Agile technique uses a model of system behavior to automatically generate test cases?

A) Risk-Based Testing
B) Model-Based Testing
C) Exploratory Testing
D) Ad-hoc Testing

Answer: B) Model-Based Testing

Explanation:

Option A, Risk-Based Testing, prioritizes testing efforts according to the risk associated with different features or components. While this approach helps focus resources effectively, it does not automatically generate test cases from system models. Test cases in risk-based testing are typically designed manually based on risk assessments and historical knowledge.

Option B, Model-Based Testing, is correct because it uses abstract models to represent the behavior, workflows, or rules of a system. These models can be state machines, decision tables, or other formal representations. Test cases are automatically derived from these models, ensuring systematic coverage of possible scenarios and reducing human error. Model-based testing is highly effective in Agile because it accelerates test creation, adapts quickly to changing requirements, and helps teams maintain consistency across iterations while supporting early defect detection.

Option C, Exploratory Testing, is a human-driven approach in which testers simultaneously learn about the system, design tests, and execute them without pre-scripted cases. It is valuable for discovering unexpected defects and understanding user behavior but does not involve automated generation of test cases from models.

Option D, Ad-hoc Testing, is informal testing without predefined procedures. Testers rely on intuition and experience to identify defects. While flexible, it lacks systematic coverage and automation and is unsuitable for generating test cases from system models.

The correct choice is model-based testing because it combines formal modeling with automation, enabling systematic, repeatable, and consistent test case generation. It fits Agile’s need for efficiency, rapid feedback, and adaptability in iterative development cycles.

Question 58: 

Which of the following best describes a “potentially shippable increment”?

A) Code written but not tested
B) Fully integrated, tested, and ready for release
C) Backlog item not yet started
D) Test plan document

Answer: B) Fully integrated, tested, and ready for release

Explanation:

Option A, code written but not tested, does not qualify as a potentially shippable increment because it lacks validation and integration. Without testing, it cannot be confidently delivered to users, and defects might remain undetected.

Option B, fully integrated, tested, and ready for release, is correct because it meets the definition of a potentially shippable increment. It represents functionality that satisfies the agreed-upon definition of done, can be demonstrated to stakeholders, and could be released immediately if needed. This approach ensures tangible value is delivered at the end of each sprint and supports Agile principles of iterative delivery, early feedback, and incremental progress.

Option C, a backlog item not yet started, is simply planned work. While important for future sprints, it does not provide any immediate, usable output, so it cannot be considered a shippable increment.

Option D, a test plan document, outlines how testing should be performed but is not deliverable functionality. Documentation alone does not represent user-facing value and cannot be released to end users.

The correct answer emphasizes Agile’s commitment to producing working, validated software frequently, reducing risk, and enabling continuous stakeholder feedback.

Question 59: 

Which Agile practice encourages early involvement of testers and continuous collaboration?

A) Shift-left testing
B) Regression Testing
C) Smoke Testing
D) Ad-hoc Testing

Answer: A) Shift-left testing

Explanation:

Option A, shift-left testing, is correct because it moves testing activities to the early stages of the development lifecycle. Testers participate in requirement analysis, design discussions, and sprint planning, identifying potential defects before implementation. This approach promotes collaboration, early defect detection, and continuous feedback, aligning with Agile principles of quality, transparency, and iterative delivery.

Option B, regression testing, focuses on validating that existing functionality still works after changes. While important, it occurs after development and does not inherently involve early collaboration.

Option C, smoke testing, is a quick verification of major system functions to ensure stability. It occurs after build completion and serves as a sanity check rather than promoting continuous collaboration or early testing.

Option D, ad-hoc testing, is informal testing without planning. It may reveal defects but lacks the structured early involvement and systematic collaboration encouraged by shift-left testing.

The correct answer is shift-left testing, as it directly embeds quality assurance into the development process from the start, enhancing team communication and reducing late-stage defect discovery.

Question 60: 

Which statement best describes story points in Agile?

A) Absolute hours to complete a task
B) Relative measure of effort or complexity
C) Number of defects in a feature
D) Priority level assigned by Product Owner

Answer: B) Relative measure of effort or complexity

Explanation:

Option A, absolute hours to complete a task, is not used in Agile story point estimation because time can vary across team members and contexts. Story points abstract away from exact time to allow consistent relative estimation across stories.

Option B, relative measure of effort or complexity, is correct. Story points provide a means to estimate the effort, complexity, and risk associated with completing a user story. Teams compare stories relative to each other, allowing velocity tracking, sprint planning, and iterative forecasting. By focusing on relative sizing, story points accommodate uncertainty and support flexible, adaptive planning without requiring precise time predictions.

Option C, number of defects in a feature, is unrelated to story point estimation. While defect tracking is important for quality, it does not reflect the relative effort needed to develop a story.

Option D, priority level assigned by the Product Owner, determines the order of work but does not measure effort or complexity. Story points and priority complement each other but are distinct; points measure effort, while priority guides selection for implementation.

The correct answer is story points as a relative measure because they facilitate planning, tracking, and communication, aligning with Agile’s iterative and adaptive approach to delivery.