ISTQB CT-AT common mistakes
ISTQB CT-AT · Understand the traps and how to avoid them.
When asked which agile practice applies at a given point, candidates answer with a testing activity (e.g., 'run regression tests') instead of the agile ceremony or practice the question targets (e.g., 'retrospective', 'daily stand-up', 'backlog refinement').
The syllabus frames agile techniques as whole-team practices, but testers tend to translate every question into a test activity, so the answer sounds plausible yet misses the practice being tested.
What to do instead
For each agile practice in the syllabus (iterations, stand-ups, retrospectives, backlog refinement, user stories, acceptance criteria, ATDD, TDD, continuous integration), write one line stating what it is for and who participates. Before answering, ask 'is the question about a practice or a test activity?' and pick the practice when the stem names a ceremony or artefact.
Candidates confuse test-driven development with acceptance-test-driven development: they describe TDD as starting from a customer-facing acceptance test, or ATDD as starting from a unit test written by the developer.
Both are 'test first' approaches and share the red-green-refactor rhythm, so the distinction blurs unless the level (unit vs. acceptance) and the author (developer vs. whole team with business) are memorised.
What to do instead
Anchor the pair on two axes: level (TDD at unit/component level, ATDD at acceptance level) and authorship (TDD by developers, ATDD by the whole team including business). Rehearse one concrete example of each and check any answer against both axes.
When a risk-based testing question appears in an agile context, candidates apply a heavyweight, document-driven risk analysis and ignore that in agile the product risk analysis informs iteration planning and the choice of tests within an iteration.
Risk-based testing is learned first in plan-driven contexts; candidates carry that template over and miss the agile framing where risk drives story selection and test depth continuously.
What to do instead
Learn risk-based testing twice: once as a project-level plan input, once as an iteration-level input for selecting stories and prioritising tests. On any agile stem, state explicitly which level the risk analysis serves before choosing an answer.
Candidates classify a given test as black-box or white-box by the tool used or by who runs it, rather than by the information the test uses to derive test conditions.
In agile teams the same person writes unit and acceptance tests, and the same framework runs both, so the organisational cue is misleading and the classification cue (specification vs. structure) is overlooked.
What to do instead
Classify by source of information only: specification, requirements, or user stories give black-box techniques; code, architecture, or structure give white-box techniques. Practise sorting ten short test descriptions using only that rule.
Candidates treat the test automation pyramid as a rule about tool count or as 'more unit tests is always better', and cannot justify the distribution in terms of feedback speed, cost of change, and confidence.
The pyramid is often memorised as a shape rather than as an economic argument, so questions that probe the reasoning behind the distribution or its exceptions (e.g., many service-level tests) are answered by shape-matching.
What to do instead
Learn the rationale for each layer: unit tests are fast and cheap to maintain, service/API tests balance speed and confidence, UI tests are slow and brittle. Then learn the recognised exceptions (e.g., a thick service layer, or a context where UI tests are the only feasible route) and justify answers with the rationale, not the drawing.
Candidates design an automation approach that automates everything, including one-off exploratory checks and tests whose expected results are unstable, instead of applying a suitability judgement.
Automation is presented positively, so candidates equate good practice with maximum coverage and forget the criteria for what should not be automated.
What to do instead
Memorise a short suitability checklist: repeated execution, stable and unambiguous expected results, feasible and economic to automate, and low likelihood of frequent change. Apply it to each candidate test in the stem and reject options that automate exploratory or highly volatile checks.
Candidates conflate continuous integration, continuous delivery, and continuous deployment, describing deployment to production as a necessary part of continuous delivery.
The three terms are adjacent in the syllabus and share the same pipeline vocabulary, and the difference between delivery (always deployable, release decision may be manual) and deployment (every change goes to production automatically) is a single word that is easily lost.
What to do instead
Write the three definitions side by side and memorise the single distinguishing clause for each: CI = frequent integration with automated build and test; CD-delivery = always in a releasable state, release decision may be human; CD-deployment = every passing change goes to production without a human gate. Test yourself by classifying short scenarios.
Candidates answer pipeline questions as if testing happens only after deployment, or place the wrong test types at the wrong pipeline stage, instead of describing tests at each stage with fast feedback first.
Traditional test levels are associated with phases, and candidates map phases onto the pipeline in order without considering that the pipeline runs checks at commit, build, and pre-release stages with increasing cost.
What to do instead
Build a stage map: commit stage (fast unit and static checks), build/integration stage (component, API, integration), pre-release stage (system, acceptance, non-functional, and where appropriate performance and security), and post-deployment monitoring. For each stage, note the test types and the feedback time budget, then answer by locating the test in that map.
Candidates treat test environments and test data as an afterthought, answering that production-like data can simply be copied, or that environments can be provisioned manually per release, rather than addressing data privacy, repeatability, and infrastructure as code.
Environment and data management are less glamorous than pipeline design, so they are under-studied, and copying production data feels realistic even though it conflicts with privacy and repeatability requirements.
What to do instead
Learn three points and use them in answers: environments should be provisioned reproducibly (infrastructure as code, containerisation) and be representative of production; test data should be generated or masked, not raw production copies, to satisfy privacy rules; data and environment state must be reset so runs are repeatable. Check any option against these three.
On technical-testing questions, candidates describe what a technique or tool is for but cannot state a concrete technical testing skill or activity in an agile team, such as reviewing code changes, analysing logs and monitoring in production, or assessing non-functional characteristics early.
The technical testing skills area is broad and the syllabus treats it at the level of capabilities rather than procedures, so candidates memorise labels and fail questions that ask for the specific activity a technical tester performs.
What to do instead
For each technical area named in the syllabus (e.g., static analysis, code review participation, non-functional testing, production monitoring and log analysis, tooling and CI support), write one sentence describing the concrete activity a tester performs in an agile team and one sentence on the value it adds. Answer by naming the activity, not the label.