ISTQB CTFL-AT Certified Tester Foundation Level Agile Tester Exam Dumps and Practice Test Questions Set 2 Q21-40

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

Question 21: 

In Agile, which artifact contains a prioritized list of desired product features?

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

Answer: B) Product Backlog

Explanation:

Option A, Sprint Backlog, is a list of tasks that the team selects for completion during a particular sprint. It is essentially a subset of the product backlog, representing what can realistically be accomplished in a short, time-boxed iteration. The sprint backlog is used to guide daily development work and is often adjusted during the sprint as tasks are completed or as new insights emerge. While important for planning and tracking sprint progress, it does not provide a comprehensive view of all desired product features across the entire project, making it insufficient as the main repository of prioritized requirements.

Option B, Product Backlog, is the correct answer. The product backlog is a living artifact that contains all the features, enhancements, bug fixes, technical work, and knowledge acquisition tasks that could be undertaken to deliver a product. Maintained by the Product Owner, it is continuously updated, prioritized, and refined to reflect changing business priorities, stakeholder feedback, and emerging requirements. Each backlog item usually includes a user story, acceptance criteria, estimated effort, and priority, which helps the team focus on delivering high-value features first. This dynamic prioritization ensures that the team’s efforts are aligned with the most important business goals and that the product evolves in a way that maximizes value for stakeholders.

Option C, Definition of Done, outlines the criteria that must be met for a user story or product increment to be considered complete. It ensures quality and consistency but does not provide a list of desired features or guide what should be built next. While it helps the team determine when work is finished, it is a set of conditions for completeness, not a planning or prioritization tool.

Option D, Burndown Chart, is a visual tool used to track progress over time, typically showing the remaining work in a sprint or release. While helpful for monitoring progress and identifying potential delays, it does not communicate what features are desired or prioritize them. It is a tracking and reporting tool rather than a planning artifact.

The reasoning for selecting the product backlog is that it serves as the central source of truth for the product roadmap. It enables the Product Owner and team to plan iteratively, ensuring that development focuses on delivering high-value features first. Continuous refinement and reprioritization allow the team to adapt to changing requirements, maintain transparency, and manage stakeholder expectations effectively, making it the cornerstone of Agile planning and delivery.

Question 22: 

Which Agile testing technique focuses on understanding the system’s behavior while simultaneously designing and executing tests?

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

Answer: B) Exploratory Testing

Explanation:

Option A, Scripted Testing, involves executing predefined test steps and comparing results to expected outcomes. While it is effective for verifying known requirements and ensuring predictable functionality, scripted testing lacks flexibility and does not allow testers to adapt to unexpected system behavior or emerging risks. It is more rigid and less effective in environments where requirements evolve rapidly, as is common in Agile projects.

Option B, Exploratory Testing, is correct. This technique integrates test design, execution, and learning in real-time. Testers explore the system to understand how it behaves, simultaneously identifying defects, testing edge cases, and generating new scenarios. It relies heavily on tester experience, intuition, and creativity, which makes it particularly suitable for Agile environments where rapid iterations and frequent changes require adaptive approaches. Exploratory testing complements scripted tests by revealing issues that might not be anticipated in formal test plans.

Option C, Load Testing, evaluates system performance under expected and peak loads. It measures response times, throughput, and resource usage to ensure the system can handle anticipated traffic. Load testing focuses solely on performance rather than defect discovery or behavior understanding. It is valuable for performance assurance but does not support dynamic test design and exploration.

Option D, Regression Testing, ensures that previously developed functionality continues to work after code changes. While critical for maintaining stability and preventing defects, regression testing is structured and does not inherently involve on-the-fly learning or creative exploration. Its scope is limited to verifying existing functionality rather than discovering new defects.

The reasoning for selecting exploratory testing is that Agile demands adaptive, responsive approaches to testing. By integrating learning and execution, testers can uncover hidden defects, explore complex interactions, and respond to newly identified risks immediately. This technique ensures broader test coverage and enhances product quality while supporting the iterative and incremental nature of Agile development.

Question 23: 

Which of the following describes the primary goal of continuous integration in Agile?

A) To delay code integration until the end of the sprint
B) To frequently integrate code changes and detect conflicts early
C) To eliminate the need for testing
D) To perform only manual testing

Answer: B) To frequently integrate code changes and detect conflicts early

Explanation:

Option A, delaying code integration until the end of the sprint, is counterproductive to Agile principles. Infrequent integration increases the risk of conflicts, makes defect identification more difficult, and slows feedback, ultimately undermining Agile’s goal of delivering incremental value.

Option B, frequent integration and early conflict detection, is correct. Continuous Integration (CI) encourages developers to merge changes regularly into a shared repository. Automated builds and tests immediately validate the integration, ensuring that errors, conflicts, or regressions are detected early. CI promotes incremental validation, maintains system stability, and supports rapid iteration. This approach aligns with Agile values by providing fast feedback, reducing risk, and enabling the delivery of potentially shippable increments consistently.

Option C, eliminating the need for testing, is incorrect. CI relies heavily on automated testing to validate each integration. Tests are integral to the process because they provide immediate feedback on defects and quality issues. CI does not replace testing but enhances it by enabling frequent, automated verification.

Option D, performing only manual testing, is also incorrect. Manual testing is complementary but not central to CI. Agile teams often rely on automated testing to achieve rapid feedback, while manual testing may be applied for exploratory or usability testing. CI emphasizes automation to maintain velocity and quality in fast-paced development environments.

The reasoning for selecting option B is that CI prevents the accumulation of integration issues, reduces the likelihood of defects propagating into later stages, and enables teams to maintain confidence in delivering functional software at each iteration. By integrating small changes continuously, teams can quickly detect and address problems, align with Agile’s iterative development model, and improve overall efficiency.

Question 24: 

Which Agile principle emphasizes delivering working software frequently and iteratively?

A) Individuals and interactions over processes
B) Customer collaboration over contract negotiation
C) Working software over comprehensive documentation
D) Responding to change over following a plan

Answer: C) Working software over comprehensive documentation

Explanation:

Option A emphasizes the importance of team collaboration and effective communication. While essential, it does not directly address the principle of delivering software frequently or iteratively. Collaboration supports iterative delivery but is not the delivery principle itself.

Option B prioritizes customer collaboration to ensure alignment with requirements and expectations. This principle facilitates adaptive planning and iterative feedback but does not specifically define the frequency or cadence of software delivery.

Option C, working software over comprehensive documentation, is correct. Agile promotes delivering functional software early and frequently in short iterations. The focus is on producing tangible value that stakeholders can use and provide feedback on, rather than extensive documentation that may delay delivery. This principle ensures iterative validation, faster risk mitigation, and continuous improvement based on real user feedback.

Option D focuses on responding to change rather than strictly following a plan. While responding to change is a core Agile mindset, it complements the principle of delivering working software by allowing teams to adapt iterations to new insights rather than dictating the actual delivery frequency.

The reasoning for selecting option C is that Agile emphasizes incremental delivery. Prioritizing working software allows teams to demonstrate progress, receive early feedback, and adjust future work accordingly. Iterative delivery ensures continuous stakeholder engagement, reduces wasted effort, and aligns development with evolving business needs, reinforcing Agile’s iterative, adaptive philosophy.

Question 25: 

What is the primary role of the Scrum Master in Agile?

A) Assign tasks and manage developers
B) Facilitate Scrum processes and remove impediments
C) Define product requirements
D) Write automated tests

Answer: B) Facilitate Scrum processes and remove impediments

Explanation:

Option A, assigning tasks and managing developers, contradicts the self-organizing principle of Scrum. Team members are responsible for deciding how to accomplish their work within the sprint, and centralized task assignment can undermine collaboration, accountability, and motivation.

Option B, facilitating Scrum processes and removing impediments, is correct. The Scrum Master acts as a servant leader, coaching the team on Agile practices, ensuring ceremonies run smoothly, and helping remove obstacles that prevent progress. They guide the team toward continuous improvement, foster collaboration, and protect the team from disruptions, allowing members to focus on delivering value efficiently.

Option C, defining product requirements, is the responsibility of the Product Owner. The Product Owner manages the product backlog, prioritizes features, and communicates stakeholder expectations, ensuring that the team builds the most valuable items first.

Option D, writing automated tests, may be part of the development team’s responsibilities, but it is not a core duty of the Scrum Master. The Scrum Master supports testing indirectly by promoting practices such as CI/CD, test-driven development, and quality improvement but does not perform testing as a primary function.

The reasoning for selecting option B is that the Scrum Master’s role centers on enabling the team’s effectiveness rather than directly controlling work or dictating product decisions. By facilitating Scrum processes, coaching, and removing impediments, the Scrum Master ensures that the team can work efficiently, maintain high quality, and adhere to Agile principles, supporting iterative and incremental delivery.

Question 26: 

In Agile, which of the following best describes a sprint review?

A) Planning work for the next sprint
B) Demonstrating completed work and gathering stakeholder feedback
C) Discussing team performance and improvements
D) Conducting automated regression testing

Answer: B) Demonstrating completed work and gathering stakeholder feedback

Explanation:

Option A suggests that planning work for the next sprint occurs during a sprint review. However, this is inaccurate because sprint planning is a distinct event that happens at the beginning of a sprint. During sprint planning, the team selects items from the product backlog to include in the upcoming sprint and defines the tasks necessary to complete them. This activity is forward-looking and focuses on commitment rather than evaluation of completed work. While sprint planning and sprint review are both integral to Agile, their purposes differ substantially, which is why this option is not correct.

Option B is correct because the sprint review is explicitly designed for the team to demonstrate completed work to stakeholders and gather feedback. This meeting ensures that the product increment meets expectations and allows for discussions regarding adjustments to the product backlog based on real-world feedback. Stakeholders provide input that can influence priorities, scope, and features in upcoming sprints. The collaborative nature of the sprint review emphasizes transparency, adaptation, and alignment with the customer’s needs, which is a core principle of Agile. It is a working session rather than a formal inspection, which helps in iterative improvement.

Option C refers to discussing team performance and improvements. This description aligns with the sprint retrospective rather than the sprint review. During retrospectives, the team reflects on the previous sprint to identify what went well, what didn’t, and how processes can be improved. The focus is on internal team dynamics, efficiency, and learning rather than on presenting product functionality to stakeholders. While important in Agile, this focus on process improvement does not define the sprint review.

Option D mentions conducting automated regression testing. While testing may occur during or after development, regression testing is not the primary purpose of a sprint review. Regression testing ensures that changes have not broken existing functionality, but it is a technical activity focused on validation rather than collaboration with stakeholders. The sprint review, in contrast, emphasizes demonstration, feedback, and future planning.

The reasoning for selecting B is that the sprint review’s main goal is to validate completed work with stakeholders, gather their feedback, and make informed adjustments to the product backlog. By showcasing potentially shippable increments and discussing priorities, the team maintains alignment with customer needs, maximizes business value, and supports Agile’s iterative and incremental delivery model.

Question 27: 

Which of the following best describes Acceptance Test-Driven Development (ATDD)?

A) Writing tests after development to verify features
B) Collaborative definition of acceptance tests before coding begins
C) Conducting performance testing only
D) Eliminating exploratory testing

Answer: B) Collaborative definition of acceptance tests before coding begins

Explanation:

Option A suggests writing tests after development is completed, which represents a traditional approach to testing. This approach often delays feedback and can result in missed requirements or misunderstandings. ATDD, however, aims to prevent such issues by creating tests before coding starts. Writing tests after the fact does not enable the early collaboration or shared understanding that ATDD promotes.

Option B is correct because ATDD involves close collaboration among developers, testers, and business stakeholders to define acceptance tests before coding begins. These tests serve as the source of truth for what constitutes correct functionality and ensure that everyone has a shared understanding of the requirements. By defining acceptance criteria upfront, teams can reduce ambiguity, prevent defects early, and align development with the desired behavior from the outset. This practice supports iterative development and continuous improvement.

Option C incorrectly assumes ATDD is about performance testing only. While acceptance tests can include non-functional aspects, the primary goal of ATDD is to verify functional requirements collaboratively. Limiting ATDD to performance testing would ignore its broader objective of aligning development with business expectations.

Option D suggests that ATDD eliminates exploratory testing, which is not true. Exploratory testing remains a valuable practice in Agile, especially for uncovering defects not anticipated in acceptance tests. ATDD complements exploratory testing rather than replacing it, providing a structured baseline against which exploratory activities can focus on risk areas.

The reasoning for selecting B is that ATDD enhances collaboration, reduces rework, and ensures a shared understanding of requirements. By defining acceptance tests before coding, teams improve quality, clarify expectations, and maintain alignment with Agile principles of incremental delivery and stakeholder engagement.

Question 28: 

Which testing approach is most suitable for validating non-functional requirements in Agile?

A) Unit Testing
B) Exploratory Testing
C) Performance and Security Testing
D) Regression Testing

Answer: C) Performance and Security Testing

Explanation:

Option A, unit testing, focuses on verifying that individual components or functions work correctly. While it is a critical part of Agile development, it does not address non-functional requirements such as performance, scalability, or security. Unit testing ensures functional correctness but does not evaluate the system under real-world operational conditions, so it cannot validate non-functional expectations.

Option B, exploratory testing, is a valuable practice for discovering defects through unscripted testing and creative problem-solving. However, it is primarily aimed at functional behavior and defect detection, not systematic validation of non-functional criteria. Exploratory testing may incidentally uncover performance or security issues but is not designed to rigorously evaluate these aspects.

Option C is correct. Performance and security testing are specifically intended to validate non-functional requirements. Performance testing assesses responsiveness, throughput, and system behavior under load, while security testing evaluates resilience against attacks and compliance with security standards. These tests ensure that the software can handle expected workloads and protect user data, which is essential for delivering reliable, trustworthy software in Agile environments.

Option D, regression testing, ensures that previously implemented functionality continues to work after changes. While it maintains overall product quality, it does not directly validate non-functional requirements such as performance or security. Regression tests are primarily concerned with functional correctness rather than evaluating system robustness or resilience.

The reasoning for selecting C is that non-functional requirements are critical for real-world success and user satisfaction. Agile development emphasizes delivering fully functional, high-quality increments quickly. Performance and security testing provide confidence that these increments meet the required standards, ensuring that the system is reliable, scalable, and secure.

Question 29: 

Which Agile artifact shows the remaining work in a sprint over time?

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

Answer: B) Burndown Chart

Explanation:

Option A, the product backlog, is a prioritized list of all desired product features, enhancements, and fixes. It reflects the overall scope of the product rather than the progress of work within a sprint. While it is essential for planning, it does not provide a visual representation of remaining work during a sprint.

Option B is correct. A burndown chart is a graphical representation of remaining work over time, showing completed tasks versus pending tasks. It enables the team and stakeholders to monitor progress, identify potential delays, and make informed decisions about adjustments. This visualization fosters transparency and helps maintain the rhythm of iterative delivery, which is central to Agile methodology.

Option C, the definition of done, outlines the criteria that must be satisfied for a task or increment to be considered complete. While it sets quality standards and ensures consistency, it does not indicate the remaining work or progress within a sprint.

Option D, the sprint backlog, lists tasks selected for a sprint and is used for planning and tracking work. However, it is not inherently a visual tool that shows trends or progress over time, which is the key function of a burndown chart.

The reasoning for selecting B is that the burndown chart provides immediate visibility into sprint progress. By tracking remaining work against time, teams can identify issues early, take corrective action, and ensure that iterations deliver value incrementally and predictably.

Question 30: 

Which of the following best describes the concept of “shift-left” testing in Agile?

A) Testing is conducted only at the end of development
B) Testing starts early and continues throughout development
C) Testing replaces coding activities
D) Only automated testing is performed

Answer: B) Testing starts early and continues throughout development

Explanation:

Option A suggests testing only occurs at the end of development, which is contrary to the shift-left principle. This late testing approach often leads to delayed feedback, higher costs for defect fixes, and reduced agility in responding to change.

Option B is correct. Shift-left testing emphasizes starting testing activities as early as the planning and design stages and continuing through development. Early involvement of testers allows for defect prevention, early validation of requirements, and continuous feedback. By integrating testing throughout the iteration, teams can identify issues quickly, reduce risk, and ensure that the product increment meets quality expectations.

Option C implies that testing replaces coding, which is a misconception. Testing complements development rather than substitutes it. Both coding and testing are necessary and collaborative activities in Agile.

Option D suggests that only automated testing is performed in shift-left, which is not required. While automation supports early and continuous testing, manual testing also plays an important role in validating complex scenarios and exploratory testing.

The reasoning for selecting B is that early and continuous testing aligns with Agile principles of iterative development, collaboration, and delivering high-quality increments. Shift-left practices improve defect detection efficiency, reduce costs, and ensure software meets user expectations consistently throughout the project lifecycle.

Question 31: 

Which of the following is true about user stories in Agile?

A) They are detailed technical specifications
B) They describe functionality from the user’s perspective
C) They are written exclusively by developers
D) They replace test cases entirely

Answer: B) They describe functionality from the user’s perspective

Explanation:

Option A suggests that user stories are detailed technical specifications. This is not accurate because Agile emphasizes simplicity and iterative delivery. User stories are meant to capture requirements in a lightweight and understandable format, avoiding deep technical design details. Detailed technical documentation, if needed, is developed separately, often as part of design discussions or architecture documents. User stories focus on the “what” from the perspective of the user rather than the “how” of implementation, which allows teams to remain flexible and adapt requirements based on feedback.

Option B correctly states that user stories describe functionality from the user’s perspective. This is the core purpose of a user story in Agile: to articulate value from the perspective of the person who will use the product. Each story typically follows a format such as “As a [user], I want [function] so that [benefit].” By keeping the focus on user needs, user stories help teams prioritize work, clarify requirements, and create a shared understanding between business stakeholders and the development team. They also serve as the basis for defining acceptance criteria, which then guide testing efforts.

Option C proposes that user stories are written exclusively by developers. This is incorrect because Agile promotes collaboration across roles. While developers may contribute technical insights to help refine a story, the primary responsibility for creating user stories usually falls to the Product Owner. Stakeholders, testers, and sometimes even developers provide input, but no single role has exclusive authority. This collaborative approach ensures that user stories reflect real business value and remain understandable to all team members.

Option D states that user stories replace test cases entirely, which is also incorrect. User stories and test cases serve complementary roles. Acceptance criteria associated with a user story are often used to derive test cases, but they do not eliminate the need for structured testing. Testers still design detailed test cases, exploratory tests, and regression suites based on those criteria to ensure quality. Agile emphasizes both continuous feedback and iterative testing rather than relying solely on the story itself to guarantee correctness.

The reasoning for selecting option B is that Agile methodology prioritizes delivering customer value efficiently while maintaining flexibility. By framing requirements from the user’s perspective, teams create a clear and shared understanding of what the product must achieve. This clarity drives development, testing, and prioritization, supporting iterative cycles of feedback and improvement. User stories are concise, adaptable, and stakeholder-focused, making them central to Agile practice. They do not dictate implementation details or replace formal testing, but they guide the team to deliver functional value that aligns with user expectations.

Question 32: 

Which Agile practice involves two developers working together at one workstation?

A) Code Review
B) Pair Programming
C) Exploratory Testing
D) Regression Testing

Answer: B) Pair Programming

Explanation:

Option A describes code review, which is typically an asynchronous process where one developer examines another’s completed code to find defects and suggest improvements. While code review contributes to quality, it does not involve simultaneous collaboration at a single workstation. The reviewing process happens after code is written and therefore lacks the continuous, real-time feedback that Agile encourages through pair programming.

Option B, pair programming, is the correct answer. This practice involves two developers working together at one workstation, with one typing the code (the “driver”) while the other reviews each line in real time (the “navigator”). This continuous collaboration ensures that mistakes are caught immediately, promotes shared understanding of code design, and spreads knowledge across the team. Pair programming also facilitates mentoring, encourages adherence to coding standards, and helps maintain higher quality software. It embodies Agile principles of collaboration, collective ownership, and iterative feedback.

Option C, exploratory testing, refers to an approach in which testers simultaneously design and execute tests in an adaptive, unscripted manner to uncover defects. While exploratory testing encourages creativity and critical thinking, it is not a collaborative coding activity, nor does it involve the synchronous pairing of developers. It is more focused on testing functionality than on implementing code collaboratively.

Option D, regression testing, focuses on verifying that previously implemented functionality still works correctly after changes. Regression testing can be automated or manual and does not inherently involve two developers working together at one workstation. It is primarily a validation process rather than a collaborative development practice.

The reasoning for selecting option B is that pair programming directly addresses Agile values of collaboration, knowledge sharing, and immediate feedback. By pairing developers, teams reduce the likelihood of defects, improve code quality, and foster a culture of mentorship. Unlike code reviews or regression testing, it is an active, synchronous activity, making it a cornerstone of Agile engineering practices that promotes both skill development and software reliability.

Question 33: 

Which of the following is a key benefit of automated regression testing in Agile?

A) Replaces the need for manual exploratory testing
B) Provides fast, repeatable validation of existing functionality
C) Eliminates the need for user acceptance testing
D) Reduces collaboration among team members

Answer: B) Provides fast, repeatable validation of existing functionality

Explanation:

Option A suggests that automated regression testing replaces manual exploratory testing. This is not true, because exploratory testing is still necessary for discovering defects that automated scripts might not cover. Exploratory testing complements automation by identifying unknown risks, usability issues, or edge cases that are difficult to predict in advance. Automation and manual testing work together rather than substituting for each other.

Option B correctly identifies a key benefit of automated regression testing. Automation allows teams to quickly rerun tests across multiple iterations, providing confidence that existing functionality remains intact after changes. This speed and repeatability support continuous integration and continuous delivery practices, enabling Agile teams to iterate rapidly without compromising quality. Automated regression testing ensures stability and early defect detection while freeing testers to focus on higher-value testing activities.

Option C proposes that automated regression eliminates the need for user acceptance testing, which is incorrect. Stakeholder validation through user acceptance testing remains crucial to confirm that the software meets business requirements and delivers value. Regression testing validates correctness at a technical level but cannot replace the subjective assessment of usability, compliance, or business alignment that UAT provides.

Option D claims that automated regression reduces collaboration, which is misleading. Automation is a tool that improves efficiency, but Agile relies on ongoing communication and collaboration among developers, testers, and product owners. Automation enhances team productivity rather than reducing interaction, as teams still need to discuss test failures, adjust priorities, and refine acceptance criteria.

The reasoning for selecting option B is that automated regression testing provides a repeatable, reliable method to verify that functionality remains intact while accommodating frequent changes. By running regression tests continuously, Agile teams can detect regressions early, maintain confidence in the system, and support iterative development. This practice complements exploratory testing and UAT rather than replacing them, making it a cornerstone of Agile quality assurance practices that balance speed, reliability, and stakeholder satisfaction.

Question 34: 

Which of the following best describes the purpose of a sprint backlog?

A) To show all product requirements for the entire project
B) To list tasks committed by the team for the current sprint
C) To define the project budget
D) To record defects found during testing

Answer: B) To list tasks committed by the team for the current sprint

Explanation:

Option A describes a product backlog rather than a sprint backlog. A product backlog contains all desired features, enhancements, and fixes for the entire project. While the product backlog is dynamic and prioritized, it does not detail what the team has committed to accomplish in a specific sprint. Confusing the product backlog with a sprint backlog can lead to misunderstandings about scope and priorities.

Option B correctly identifies the purpose of the sprint backlog. It is a subset of the product backlog, containing items that the team commits to completing within the sprint. The sprint backlog includes detailed tasks, progress tracking, and any impediments the team may encounter. It is updated daily during stand-ups to reflect progress and help the team remain transparent and accountable. This focus ensures that the team has a clear understanding of sprint goals and can adapt if priorities shift.

Option C, defining the project budget, is unrelated to a sprint backlog. Budgeting is managed at a higher project management level and is not part of Agile’s sprint-level task tracking. Sprint backlogs focus on work items, not financials.

Option D suggests that sprint backlogs record defects, which is incorrect. While defects may be included as tasks if they are addressed during a sprint, defect tracking itself is handled separately, often using bug tracking tools or integrated Agile boards. The backlog’s primary purpose is to guide the team’s work, not serve as a defect log.

The reasoning for selecting option B is that the sprint backlog embodies Agile principles of transparency, accountability, and adaptive planning. By tracking the work committed for a sprint, teams can self-organize, prioritize effectively, and deliver incremental value. It is a living document, updated daily to reflect real-time progress, impediments, and completed tasks, providing the team and stakeholders with visibility into the current sprint’s achievements and challenges.

Question 35: 

Which of the following describes the purpose of exploratory testing charters?

A) Define long, detailed test scripts
B) Guide focused exploratory testing without specifying exact steps
C) Replace automated tests entirely
D) Prioritize product backlog items

Answer: B) Guide focused exploratory testing without specifying exact steps

Explanation:

Option A, defining long, detailed test scripts, is inaccurate. Exploratory testing charters are intentionally concise to provide flexibility. They do not prescribe exact steps but instead outline objectives or areas of focus for a testing session. This brevity allows testers to adapt their approach based on discoveries during testing.

Option B is correct. Charters provide a goal or mission for exploratory testing, offering direction while allowing freedom to explore functionality, identify defects, and assess risks in real time. This aligns with Agile principles of adaptability and continuous feedback. Charters encourage creative thinking, enabling testers to uncover issues that structured tests might miss, while still maintaining focus on high-priority areas.

Option C suggests charters replace automated tests, which is incorrect. Automation and exploratory testing complement each other. Automated tests handle repetitive, predictable scenarios, while exploratory testing allows humans to investigate unexpected behaviors, edge cases, or usability issues that automation cannot anticipate. Both approaches work together to maintain software quality.

Option D, prioritizing backlog items, is not the purpose of exploratory charters. Backlog prioritization is driven by the Product Owner based on business value, risk, and stakeholder input. Charters are specific to testing sessions and do not influence backlog ordering.

The reasoning for selecting option B is that exploratory testing charters provide structured guidance without restricting testers’ creativity. They ensure testing is focused on important areas while preserving flexibility, supporting Agile values of collaboration, rapid feedback, and adaptive planning. By defining clear goals without detailing every step, charters help testers uncover critical defects efficiently and effectively, complementing other testing strategies like automation and scripted tests.

Question 36: 

In Agile, what is the primary purpose of test automation frameworks?

A) To remove the need for all manual testing
B) To support efficient and maintainable automated tests
C) To generate product requirements
D) To document sprint performance

Answer: B) To support efficient and maintainable automated tests

Explanation:

Option A suggests that automation frameworks remove the need for all manual testing. While automation can significantly reduce repetitive testing efforts, it cannot replace the critical thinking, exploratory testing, and judgment that human testers provide. Manual testing remains essential for validating user experience, edge cases, and scenarios that are not easily captured by automated scripts. Therefore, claiming automation eliminates all manual testing is an overstatement and does not reflect practical Agile testing practices.

Option B is the correct choice because automation frameworks provide a structured and consistent approach to building and executing automated tests. These frameworks offer reusable components, guidelines for writing tests, and support for efficient execution across different environments. By standardizing automation practices, frameworks enhance maintainability, reduce duplication of effort, and make regression testing more reliable. In Agile, where iterative development and rapid feedback are essential, these benefits are critical. A well-designed framework ensures that automated tests can evolve alongside the codebase without excessive maintenance overhead.

Option C implies that test automation frameworks can generate product requirements. This is inaccurate because requirements are defined through collaboration among product owners, stakeholders, and the development team. While automation frameworks help validate that the software meets requirements, they do not create those requirements. Their role is to implement testing in a systematic way, not to decide what functionality the product should have.

Option D states that frameworks document sprint performance. While automation results can provide metrics about test execution, coverage, and failures, documenting sprint performance encompasses broader activities, such as reviewing completed work, team velocity, and progress toward objectives. Frameworks primarily support testing activities and cannot fully replace performance documentation or sprint reporting processes.

The reasoning for selecting option B lies in understanding the core purpose of frameworks in Agile. They are designed to provide efficiency, repeatability, and maintainability in automated testing, supporting Agile principles of continuous integration and frequent delivery. Frameworks allow teams to run tests quickly, consistently, and accurately, which helps detect regressions, verify new features, and improve confidence in the software. In short, their role is enabling effective automation rather than eliminating manual testing or managing documentation.

Question 37: 

Which of the following best describes the principle of “fail fast” in Agile?

A) Delaying defect detection until the end of a sprint
B) Identifying and addressing defects as early as possible
C) Ignoring minor defects during development
D) Focusing solely on performance testing

Answer: B) Identifying and addressing defects as early as possible

Explanation:

Option A suggests delaying defect detection until the end of a sprint. This approach contradicts Agile principles, which emphasize early and continuous feedback. Waiting until the end increases the risk of defects propagating through the system, making them more costly and time-consuming to fix. Agile encourages frequent integration and testing, so postponing defect identification undermines both quality and responsiveness.

Option B is correct because “fail fast” refers to recognizing issues at the earliest possible stage of development. By identifying defects early, teams can address them quickly, preventing them from escalating into larger problems. This principle reduces rework, improves software quality, and supports iterative development. Early detection also fosters a culture of transparency and collaboration, where feedback is received continuously, and improvement is ongoing.

Option C, ignoring minor defects, is counterproductive. Even small defects can accumulate over iterations and affect user experience or system stability. Agile promotes continuous attention to quality, so overlooking minor issues would violate core principles of delivering working software incrementally.

Option D focuses on performance testing only, which is a narrow interpretation. Fail fast applies broadly to all types of defects—functional, integration, usability, and performance. It is about timely detection across the board rather than concentrating solely on one testing aspect.

The reasoning for selecting B highlights that early identification of defects enables rapid feedback, supports corrective action, and reduces risk. It aligns with Agile values of adaptability and continuous improvement. Detecting problems early prevents bottlenecks, ensures quality, and maintains the pace of iterative delivery, which is the essence of failing fast.

Question 38: 

Which testing technique in Agile focuses on collaboration between testers, developers, and business stakeholders to define acceptance criteria?

A) ATDD
B) Load Testing
C) Regression Testing
D) Ad-hoc Testing

Answer:  A) ATDD

Explanation:

Option A, Acceptance Test-Driven Development (ATDD), is correct. ATDD emphasizes collaboration among developers, testers, and business stakeholders before coding begins to define acceptance criteria. This ensures everyone has a shared understanding of what constitutes a successful feature. By writing acceptance tests upfront, teams can guide development and testing efforts while reducing misunderstandings and ambiguity.

Option B, Load Testing, focuses on evaluating system performance under high demand but does not inherently involve collaboration for defining acceptance criteria. It is a specialized form of testing for performance and scalability rather than validating requirements collaboratively.

Option C, Regression Testing, involves re-running previous tests to ensure new changes do not break existing functionality. While critical for quality assurance, it does not facilitate collaboration on acceptance criteria nor guide initial development.

Option D, Ad-hoc Testing, is informal and exploratory. It relies on tester intuition and experience rather than structured collaboration or predefined acceptance criteria. While it can uncover defects, it is not designed to foster shared understanding between technical and business teams.

The reasoning for selecting A is that ATDD directly promotes alignment across the Agile team, ensuring requirements are captured in a testable format before development begins. This early collaboration reduces rework, clarifies expectations, and ensures the team delivers features that meet stakeholder needs.

Question 39: 

Which of the following best explains the term “increment” in Agile?

A) A single line of code
B) A functional, potentially shippable piece of the product
C) A document describing requirements
D) A test report

Answer: B) A functional, potentially shippable piece of the product

Explanation:

Option A, a single line of code, is too granular. Agile increments must deliver meaningful functionality that can be validated and potentially used by stakeholders. A single line of code alone does not meet this criterion.

Option B is correct because increments are functional, potentially shippable pieces of the product delivered at the end of each iteration. Each increment adds value, allowing stakeholders to provide feedback, which guides subsequent development. It embodies Agile’s iterative approach, emphasizing working software over documentation.

Option C, a document describing requirements, is an input for development, not an increment. While necessary for planning, it does not provide functional value by itself.

Option D, a test report, informs stakeholders about verification results but does not constitute a deliverable increment. It supports quality assurance but is not a tangible product feature.

The reasoning for selecting B is that increments enable continuous delivery and feedback. They demonstrate tangible progress and ensure that each sprint produces value that stakeholders can review. This aligns with Agile principles of iterative development and early validation.

Question 40: 

Which of the following is a benefit of test-driven development (TDD) in Agile?

A) Writing tests after coding to validate features
B) Early defect detection and improved design quality
C) Eliminates the need for exploratory testing
D) Focuses solely on performance testing

Answer: B) Early defect detection and improved design quality

Explanation:

Option A is incorrect because TDD requires writing tests before coding begins. Writing tests afterward does not capture the same benefits of guiding design and ensuring test coverage from the outset.

Option B is correct because TDD encourages developers to define expected behavior through tests before implementation. This practice promotes early detection of defects, as code is continuously validated against the tests. Additionally, it supports improved design quality by encouraging modular, testable, and maintainable code. The cycle of writing a test, coding, and refactoring ensures robust software architecture.

Option C is misleading. TDD complements exploratory testing but does not eliminate it. Exploratory testing remains valuable for uncovering unexpected behaviors, usability issues, and edge cases that automated tests may miss.

Option D is incorrect because TDD is not focused solely on performance. Its primary purpose is verifying functional correctness and improving code design. While performance considerations can be included, they are not the central benefit.

The reasoning for selecting B is that TDD aligns with Agile principles of early feedback, continuous improvement, and high-quality delivery. By writing tests first, teams detect defects early, reduce rework, and ensure a clean design, enhancing both code maintainability and overall system reliability.