Free ISTQB ISTQB-Agile-Public Practice Exam with Questions & Answers

Equivalence partitioning is a black box test design technique suitable for verifying the accuracy of user stories like the one described. It involves dividing input data of a software unit into partitions of equivalent data from which test cases can be derived. For a user story involving tax percentage calculation based on income, Equivalence Partitioning allows the creation of test cases for different income ranges (low, medium, high) to ensure that the system accurately calculates tax percentages for each partition, thus covering various scenarios within the application's functionality.

The acceptance criteria for a sprint focused on improving the performance of a system, like the one described for Sprint 5, typically include ensuring that the system meets specific performance benchmarks and that the functionality implemented in previous sprints continues to work as expected. Therefore, the most relevant acceptance criteria for such a sprint would be:

• iii) "100% of the existing regression test suite has passed." This criterion ensures that the new performance enhancements have not adversely affected the existing functionalities of the system. It's a common practice in agile projects to maintain the integrity and quality of the system by running regression tests. This is supported by the notion that continuous testing and quality assurance are integral components of agile methodologies, ensuring that each increment of the project maintains and improves the quality of the product (Source: Agile Project Management methodologies).
• iv) "System is responding in less than 3 seconds, 90% of the time." This criterion directly addresses the goal of the sprint, which is to increase the performance of the system. Setting a specific target for response times is a quantifiable and testable way to measure the improvement in performance. This aligns with agile principles, which emphasize delivering valuable, working software and encourage adaptive planning and continuous improvement. Performance targets like these help the team focus on delivering specific, valuable improvements to the system (Source: Principles behind the Agile Manifesto).

Options i) and v) are less relevant to the specific focus of Sprint 5, which is on performance improvement, and more about user roles and software compatibility, which are not directly tied to the performance objectives of the sprint. Therefore, options iii) and iv) constitute the most appropriate acceptance criteria for Sprint 5, focusing on ensuring that the system's performance meets the set benchmarks without compromising existing functionalities.

In Agile projects, test automation plays a crucial role in maintaining high quality and accommodating the rapid pace of iterative development. Statement ii highlights the difficulty of ensuring high quality without test automation, given Agile's frequent changes and fast iterations. Test automation facilitates continuous testing, allowing teams to quickly identify and address issues. Statement iii, regarding automated acceptance tests being part of continuous integration, underscores the Agile practice of integrating and testing changes regularly to ensure that the product evolves correctly with each iteration. This practice aligns with the principles of Agile methodologies that advocate for sustainable development, continuous attention to technical excellence, and good design to enhance agility.

The 3C concept in Agile development refers to Card, Conversation, and Confirmation. This concept emphasizes the collaborative and iterative nature of defining user stories and their acceptance criteria in Agile projects. In the context of the provided user story, "As a customer, I want to subscribe to the mailing list so that I can receive the latest deal in an email," option A is correct. The conversation should include the acceptance criteria discussion, which is an integral part of the 3C concept.

The Card represents the user story itself, which is a brief statement describing a feature or requirement from the user's perspective. The Conversation involves discussions between the development team and the product owner (or other stakeholders) to clarify the details and ensure a mutual understanding of the user story. This conversation is crucial for exploring the user story's implications, discussing potential implementation approaches, and agreeing on the acceptance criteria that define when the story is considered complete and satisfactory.

Confirmation involves agreeing on and documenting the acceptance criteria that emerge from the conversation. These criteria serve as a checklist to ensure that the implemented feature meets the user's needs and expectations as defined in the user story.

Option A is the verified answer because it accurately reflects the importance of including acceptance criteria discussions in the conversation phase of the 3C concept. This practice aligns with Agile principles by ensuring clarity, shared understanding, and a focus on delivering value to the customer.

The acceptance test criteria for the user story should ensure that the system can effectively evaluate loan requests based on the specified conditions. Criteria i) and ii) allow the customer assistant to access and verify customer account history and repayment behaviors, which are essential for assessing loan eligibility as per the user story. Criteria iv) and v) enable the bank manager to review and make decisions on loan requests, aligning with the user story's stipulation that the bank manager is responsible for loan approvals. These criteria ensure the system supports both the customer assistant's preparatory role and the bank manager's decision-making role in the loan approval process.

In Agile projects, the integration of development and testing activities involves close collaboration between developers and testers, but it does not typically involve testers replacing developers in writing unit test automation scripts. Agile methodologies, such as Scrum and XP (Extreme Programming), encourage developers to write their own unit tests as part of the Test-Driven Development (TDD) process. Testers often focus on higher-level testing activities, such as acceptance testing and exploratory testing, and may work alongside developers to enhance test coverage and effectiveness. The incorrect statement about testers replacing developers in writing unit test automation scripts contradicts the Agile principle of developers being responsible for the quality of their code, which includes writing and maintaining unit tests​​.