CAT common mistakes
CAT · Understand the traps and how to avoid them.
Treating 'agile testing' as a single test level or phase and describing it as a stage that follows development, rather than as a whole-team, continuous activity woven through every iteration.
Candidates carry over waterfall mental models from foundation-level study, where testing is a phase with entry/exit criteria, and reuse that vocabulary when asked how testing works in agile.
What to do instead
Reframe: in agile, testing activities (test design, automation, exploratory testing, review) occur continuously and are owned by the whole team, not a separate phase. Practice writing one sentence per iteration day describing which testing activity happens there, and check no sentence implies 'testing starts after coding'.
Confusing the four values and twelve principles of the Agile Manifesto with the specific agile testing principles, and answering questions about 'agile testing principles' by quoting manifesto values such as 'working software over comprehensive documentation'.
The manifesto is widely memorized and semantically adjacent, so it feels like a safe answer; the exam's agile testing principles (e.g., testing is not a phase, early and frequent feedback, whole-team responsibility, continuous improvement) are less familiar.
What to do instead
Build a two-column sheet: manifesto values/principles on the left, agile testing principles on the right, and for each testing principle write one concrete team behaviour that demonstrates it. When a question says 'testing principle', answer from the right column only.
Assuming the agile tester's role is limited to executing tests and logging defects, and failing to recognize responsibilities such as facilitating test automation strategy, coaching the team on quality, participating in release planning, and helping business stakeholders express acceptance criteria.
Job titles and older role descriptions frame the tester as a gatekeeper after development; candidates default to that familiar script instead of the collaborative, embedded role described in agile practice.
What to do instead
Write a one-page role charter listing activities across the iteration (planning, design collaboration, automation, exploratory testing, retrospectives, stakeholder communication) and for each, name who else on the team is involved. Answer role questions by choosing the option that spreads quality responsibility across the team rather than concentrating it in the tester.
Describing acceptance criteria and acceptance test-driven development as things produced only after development is complete, instead of as collaboration artifacts that drive development and define 'done'.
The word 'acceptance' suggests final sign-off, so candidates map it to the end of the lifecycle; the collaborative, specification-by-example nature of ATDD is easy to miss.
What to do instead
Learn the ATDD cycle as a sequence: discuss concrete examples with business, distill acceptance criteria, automate the tests, then develop to pass them. Be able to state who writes acceptance criteria (business plus team, with tester input) and when (before or during development of the story).
Treating the testing quadrants as a maturity model or a strict sequence (Q1 then Q2 then Q3 then Q4), or as a way to assign work only to testers, rather than as a classification of test types by purpose and audience.
Quadrant diagrams look like ordered stages, and candidates memorize labels without understanding that the quadrants guide coverage and team collaboration.
What to do instead
For each quadrant, write the purpose (support the team vs. critique the product) and audience (technology-facing vs. business-facing), then give two example test types per quadrant and say who typically does them. Explicitly note that quadrants are not sequential and that some tests may sit at boundaries.
Memorizing test-driven development as 'write tests, then code' without distinguishing the red-green-refactor cycle, the unit level at which TDD operates, and how it differs from ATDD and from simply writing tests after code.
The slogan is memorable but shallow; exam questions probe the ordering, the refactor step, and the relationship between TDD and emergent design.
What to do instead
Practice describing one full TDD cycle in four or five sentences, including the failing test, minimal code to pass, refactoring with tests green, and repetition. Then write a comparison table with rows for TDD, ATDD, and behavior-driven development covering level, primary author, and main purpose.
Giving a single generic definition of 'done' and ignoring that agile teams use several levels (story done, iteration done, release done) with different criteria, and that acceptance criteria and regression status feed into them.
Candidates learn one definition-of-done statement and reuse it everywhere, missing that release-level done typically adds non-functional, documentation, and deployment criteria.
What to do instead
Write three short definitions of done (story, iteration, release) and mark which criteria are shared and which are added at each level. Be ready to explain how automated acceptance and regression tests provide the evidence that a level of done has been met.
Answering risk-based testing questions in agile by describing a one-off risk analysis at project start, rather than continuous, lightweight risk assessment at iteration and story level that shapes test depth and automation priority.
Classic risk-based testing is taught as an upfront planning activity; candidates do not translate it to the cadence of short iterations and backlog refinement.
What to do instead
Describe a concrete loop: during refinement and planning, identify product and project risks per story, use them to decide test depth, exploratory charters, and what to automate first, then revisit risks each iteration and in retrospectives. Be able to give an example where a high-risk story gets more exploratory testing and earlier automation than a low-risk one.
Treating agile test automation as 'automate everything' and ignoring the test automation pyramid, the economics of maintenance, and the role of exploratory testing for what automation cannot cover.
Automation is often framed as a coverage target; candidates overlook that brittle UI-heavy suites create technical debt and slow feedback, which the exam tests through questions on automation strategy and return on investment.
What to do instead
Learn the pyramid shape and the reason for it: many fast unit-level checks, fewer service-level tests, few end-to-end UI tests. For a sample feature, decide what to automate at which level, what to leave to exploratory testing, and how the suite will be maintained as the product changes.
Ignoring the human and process side of agile testing: retrospectives as a real improvement mechanism, the tester's role in continuous improvement, and how metrics and feedback loops are used without turning them into individual performance measures.
Technical topics feel more examinable, so candidates under-prepare for questions on team dynamics, retrospective outcomes, and appropriate use of metrics, then pick plausible-sounding but wrong answers.
What to do instead
Prepare three short scenarios: a retrospective that produced no change, a team using defect counts to rank testers, and a team ignoring production feedback. For each, write what a tester should do and which principle it illustrates. Emphasize team-level, trend-based use of information and small, owned improvement actions.