ISTQB CTAL-TTA common mistakes
ISTQB CTAL-TTA · Understand the traps and how to avoid them.
Treating risk-based testing as a single risk ranking exercise done once at test planning, then freezing the priority order for the rest of the project.
Candidates carry over the Foundation-level habit of building one risk matrix and stop there. CTAL-TTA expects risk to drive test design depth, technique selection, and effort allocation continuously, and to be re-assessed when new information arrives (defect clusters, changed requirements, new technical risk). The exam rewards candidates who link risk level to specific white-box coverage targets and automation decisions, not just a sorted list.
What to do instead
Practise writing risk entries that explicitly state the chosen test approach: for each high-risk item name the technique, the coverage criterion, and the automation stance. Then rehearse the re-assessment trigger: describe what evidence would cause you to re-rank a risk and how that changes the planned coverage. When answering scenario questions, always ask 'what does this risk level change in my test design?' before choosing an option.
Confusing product risk with project risk when asked which risks should drive test intensity.
Both appear in risk discussions, and candidates often select answers that prioritise schedule or budget risk as a reason to test more deeply. In risk-based testing the depth of testing is driven by product risk (likelihood and impact of a defect in a quality characteristic), while project risk affects planning, staffing, and contingency. Options that mix the two read plausibly but are wrong.
What to do instead
Before answering, classify each risk in the stem: does it concern the behaviour of the delivered system or the ability to deliver it? Only product risks justify raising coverage criteria or adding techniques. Write a short table of five example risks and label each product or project, then note what each would change in the test plan.
placeholder
placeholder
What to do instead
placeholder
Selecting a white-box technique by habit rather than by the structure the question asks about.
Candidates learn statement and decision coverage first and apply them to every scenario, including ones describing interactions between modules or data flow. CTAL-TTA questions often describe a control flow graph, a data flow anomaly, or a state-dependent code path where the appropriate technique is different, and the familiar answer is a distractor.
What to do instead
Build a decision guide from the stimulus words: 'every statement' points to statement coverage, 'every outcome of every decision' to decision coverage, 'every combination of condition outcomes' to condition or multiple condition coverage, 'definition reaches a use' to data flow testing, 'transition between states of the code' to state-based white-box design. Practise mapping ten short code descriptions to techniques before attempting full questions.
Computing coverage percentages from a code fragment without first identifying the decisions and decision outcomes correctly, then reporting a number that cannot be achieved.
Candidates count lines instead of decision outcomes, miss implicit decisions such as loop conditions and short-circuit operators, or forget that a compound condition counts once for decision coverage but multiple times for condition coverage. The arithmetic then looks right but the denominator is wrong, which is exactly what the distractors exploit.
What to do instead
Adopt a fixed procedure: annotate every decision point including loops and the second operand of short-circuit operators, list the outcomes, then count. Work through fragments with compound conditions and compute statement, decision, condition, and multiple condition coverage side by side so the different denominators become intuitive. Verify that 100 percent decision coverage implies 100 percent statement coverage but not the reverse.
Designing test cases that reach a coverage target on paper but are not feasible because of infeasible paths or unreachable code.
Textbook examples assume every path can be exercised. Real code contains defensive branches, mutually exclusive conditions, and dead code, so a claimed 100 percent target may be impossible. Candidates who ignore feasibility pick answer options claiming full coverage where the correct answer acknowledges an unreachable path or a coverage limit.
What to do instead
When a question shows a graph or code with contradictory conditions, check feasibility before computing coverage. State explicitly that the unreachable path cannot be covered and that the achievable maximum is lower. In scenario answers, prefer options that report the infeasible path and recommend either removing dead code or documenting the justified exception rather than claiming the target was met.
Treating static analysis and dynamic analysis as interchangeable, or recommending a static tool to find a defect that only manifests at runtime.
Both are 'analysis' and both can be automated, so candidates default to whichever tool name they remember. The exam tests the boundary: static analysis examines code or models without execution and finds issues such as unreachable code, undeclared variables, coding standard violations, and some security weaknesses; dynamic analysis requires execution and finds issues such as memory leaks, pointer misuse under load, and runtime performance problems.
What to do instead
Memorise the boundary as a two-column list and rehearse it with concrete defect types. For each defect in a question, ask 'can this be seen without running the code?' If yes, static; if it needs execution, dynamic. Also note that static analysis can be applied to requirements and design documents, not just source code, which is a frequent discriminator in answer options.
Assuming a static analysis tool with many rules enabled is automatically the right recommendation, ignoring false positives and configuration.
Candidates equate more rules with better quality. In practice an unconfigured tool produces high false positive rates, teams stop reading the output, and real defects are missed. Questions about introducing static analysis into a project reward answers that mention tailoring rule sets, baselining existing findings, and integrating the tool into the build so only new violations block the pipeline.
What to do instead
Prepare a short argument for incremental adoption: select rules aligned to the coding standard and risk profile, establish a baseline, fail the build only on new high-severity findings, and review the rule set periodically against the false positive rate. Use this argument to eliminate options that propose enabling every rule at once or running the tool only before release.
placeholder
placeholder
What to do instead
placeholder
placeholder
placeholder
What to do instead
placeholder
placeholder
placeholder
What to do instead
placeholder
placeholder
placeholder
What to do instead
placeholder