CTFL-AT Foundation Agile Tester Practice Questions

The Agile Manifesto is a foundational document that outlines a mindset through four core values and twelve supporting principles. It describes 'what' to value but not 'how' to achieve it. Methodologies like Scrum, Kanban, and XP are specific frameworks or sets of practices that provide a structure for putting the Manifesto's values and principles into action.

The content of the statement will depend on the types of transactions that occurred. Equivalence partitioning is ideal for this scenario. The tester could define partitions such as: a statement with only credit transactions, only debit transactions, a mix of both, a statement with zero transactions, and a statement with special transaction types (e.g., refunds, fees). By testing one representative example from each partition, the tester can efficiently gain confidence in the accuracy of the PDF's content.

In Agile, a blocker for one team member is a blocker for the whole team. The priority is to maintain the flow of work. The best approach is for the team to 'swarm' the problem, with relevant members (developers, testers, ops) collaborating to resolve the impediment as quickly as possible. Picking up new work before the current work is 'done' leads to an accumulation of work-in-progress and hides bottlenecks.

The tester's unique perspective allows them to identify ambiguities and gaps in requirements. By collaborating with the Product Owner during backlog refinement, the tester's main goal is to help shape the user story and its acceptance criteria to be specific, measurable, and verifiable. This ensures the entire team has a shared understanding of what needs to be built and how its success will be measured.

In a typical CI/CD pipeline, after the code is compiled and unit tests pass (Step 1), the next logical automated step is to run integration tests. These tests verify that the newly changed components work correctly with other parts of the system, often at the API or service level. This happens before deployment to a full staging environment for end-to-end tests.

The core issue is the unsustainable manual regression effort, which is a common problem as an Agile project grows. Automating the regression suite and integrating it into a CI pipeline provides rapid feedback without consuming valuable sprint time. This directly addresses the root cause, freeing up testers to focus on new features and exploratory testing. Extending sprints or adding hardening sprints are anti-patterns that delay feedback. Risk-based testing is a good practice but doesn't solve the underlying scalability problem of manual regression.

The primary purpose of planning poker is not just to produce a number, but to foster conversation and create a shared understanding of the work involved. A large divergence in estimates indicates a significant difference in understanding the complexity, risks, or effort. Having the high and low estimators explain their rationale is the standard practice to uncover hidden assumptions (e.g., testers may be considering complex data validation and regulatory compliance testing that others overlooked).

A test charter's primary purpose is to provide a clear mission or goal, guiding the exploration without overly constraining it.

The charter should define the scope of the session, indicating which features or areas are in-scope for exploration.

This is true. The Agile Test Pyramid model advocates for having a large base of fast, reliable unit tests, a smaller middle layer of service/API/integration tests, and a very small top layer of slow, brittle end-to-end GUI tests. Therefore, service layer tests should be more numerous than GUI tests.

The 'T' in the INVEST acronym stands for 'Testable'. This principle dictates that a user story must be written with enough clarity and detail, including specific acceptance criteria, so that it's possible to determine whether the implementation is complete and correct. If you can't test it, you don't know when you're 'done'.