ISTQB-AGILE ISTQB Agile Practice Questions

The manifesto states that while there is value in the items on the right (like comprehensive documentation), Agile values the items on the left (working software) more. It does not mean documentation has no value or should be eliminated. Agile teams should create just enough documentation that is valuable and necessary for the project's success.

Agile testers need a blend of skills. Strong collaboration is essential for the whole-team approach. Technical automation skills are crucial for managing regression and enabling fast feedback. A critical mindset is fundamental to the testing discipline itself, helping to uncover risks and assumptions. Working in isolation and creating comprehensive upfront documentation are contrary to Agile principles.

One of the core principles of Scrum is that the sprint goal should be protected to allow the team to focus. However, Agile also values responding to change. The best practice is to negotiate with the Product Owner. If the new item is critically important, the team can agree to add it by removing an equivalent amount of other work from the sprint. This respects the team's capacity and maintains a sustainable pace while still being flexible to business needs.

The Agile Testing Quadrants place non-functional tests that critique the product, such as performance, load, stress, and security testing, into Quadrant 4. These tests are technology-facing (as they often require specialized tools and technical knowledge) and are used to evaluate and critique the product against specific quality attributes.

The two models are complementary heuristics. The Testing Quadrants help teams think about the types of tests they need (e.g., business-facing vs. technology-facing, supporting vs. critiquing) to achieve a comprehensive test strategy. The Test Pyramid guides the implementation of that strategy, specifically for automation, by suggesting the relative number of tests at each level (many unit tests, fewer service tests, very few UI tests) to optimize for speed, cost, and stability.

The most productive contribution is data-driven and focuses on process improvement. By analyzing the characteristics of the failed user stories, the tester provides concrete evidence that can lead to a specific, actionable improvement in the planning process. Blaming is counterproductive. Suggesting a velocity reduction is a symptom, not a root cause. Insisting on more testing time without identifying the root cause is not a collaborative solution.

The primary goal of the on-commit CI loop is to provide extremely fast feedback to developers. Therefore, only the quickest checks should be included. Static code analysis and fast-running unit/component tests fit this requirement. Full end-to-end UI tests and performance tests are typically too slow and are run less frequently (e.g., nightly). Manual exploratory testing is not part of an automated CI pipeline.

A well-formed acceptance criterion is specific, testable, and often follows a format like Given-When-Then. It describes an observable outcome from a user's perspective. Option D clearly defines the context, action, and expected result, making it unambiguous and easy to verify. The other options are too vague ('work correctly'), incomplete, or describe an internal quality metric (code coverage) rather than user-facing behavior.

The 'Definition of Done' is a shared understanding of what it means for work to be complete. According to the whole-team approach, the DoD is created and agreed upon by the entire team, including developers, testers, and the product owner, not dictated by a single group.

The role of an Agile tester includes coaching the team on quality. The most collaborative and effective approach is to facilitate a team-level solution. Proposing a new working agreement during a retrospective empowers the team to solve its own problem and reinforces the principle of collective ownership of quality and process. Reporting or creating unilateral rules goes against Agile principles of self-organizing teams.