ISTQB CTAL-TA common mistakes
ISTQB CTAL-TA · Understand the traps and how to avoid them.
Asked to describe risk-based testing on a multi-release project, the candidate lists 'identify risks, rate them, write the plan' and stops; they never mention re-assessing risk during test monitoring and control, nor feeding new defect and incident data back into the risk ratings.
Risk analysis is revised as a planning-phase sequence to be memorised, so candidates reproduce the order of steps without internalising that risk is continuously monitored and the test approach re-prioritised as information changes.
What to do instead
For every risk-based question add a second pass: state who reviews the risks, how often, and which triggers (new defects, scope change, environment delay, late requirement change) force a re-rating and a change of test schedule or coverage. If the answer has no 're-evaluate' element on a long project, it is incomplete.
They classify a late test environment, staff turnover or an unstable test tool as a product risk, and then argue it should drive deeper coverage of a quality characteristic; conversely they file 'weak authentication' as a project risk because it endangers project success.
Product and project risks sit in the same register and share the language of likelihood and impact, so the boundary is easy to skim in revision and easy to blur when answering quickly.
What to do instead
Apply the test 'is the thing at risk the quality of the product, or the project's ability to deliver it?' Product risks drive test design (which characteristics, which technique, how much coverage, level of independence); project risks drive test planning and control (estimates, staffing, contingency, monitoring). Decide which one it is before writing anything.
For an input documented as '1 to 100 inclusive' they give 1, 50 and 100 and stop; or they add 0 and 101 on one side only; or they generate boundary values for a partition such as colour = {red, green, blue}.
Boundary value analysis is remembered as 'test the edges' rather than 'for each ordered partition test both boundaries and their nearest neighbours, valid and invalid'. Under time pressure the invalid side is the first thing dropped.
What to do instead
Use the six-value routine consciously: min-1, min, min+1, max-1, max, max+1, and label each value effective or ineffective. Before generating values, confirm the partition is ordered; if it is not, equivalence partitioning or a decision table is the correct technique.
Shown an order lifecycle (pending -> paid -> shipped -> cancelled) they answer with a decision table; shown a screen with five independent validation rules they answer with state transition testing; and where they do choose state transitions they cover only the happy path, omitting invalid transitions and attempts to fire events in the wrong state.
All black-box techniques get revised as one block, and the discriminating trigger words (combinations of conditions versus sequence of events) are never practised. Invalid transitions feel like error guessing rather than a formal part of the technique.
What to do instead
Memorise one trigger per technique: combinations of conditions producing rules -> decision table; event-driven lifecycle/status model -> state transition (all states, all valid transitions plus invalid ones); business flow -> use case; ranges and lists -> equivalence partitioning and boundary value analysis. On scenario questions, write the trigger phrase you detected before selecting the technique.
They place capacity under reliability, installability and replaceability under compatibility, testability under functional suitability, or task completion time under performance efficiency; a question about a system's ability to keep working while a component is updated is answered with 'portability' when adaptability is meant.
ISO 25010 is memorised as a flat word list rather than a tree, and several subcharacteristics sound plausible under more than one parent (capacity, time behaviour, adaptability, testability).
What to do instead
Redraw the characteristic/subcharacteristic tree from memory until placement is automatic, and answer by working down from the concern named in the question: does it do the right thing (functional suitability), does it do it fast and with few resources (performance efficiency: time behaviour, resource utilisation, capacity), does it keep working and recover (reliability), can it exchange information and share an environment (compatibility), can it be changed and tested (maintainability), and so on.
For any quality characteristic other than functional correctness they answer with the same recipe: 'derive test cases with equivalence partitioning and boundary value analysis'. They also accept vague goals such as 'the system should be fast' without turning them into measurable targets, and they do not say how the result will be observed or measured.
Technique revision is dominated by functional black-box methods, and candidates who have not tested non-functional characteristics professionally have no concrete model of load profiles, soak tests, failure injection or penetration approaches to draw on.
What to do instead
Attach a method and a measurement to each characteristic: performance efficiency -> load/stress/spike with defined response-time and throughput targets; reliability -> soak, failure injection, recovery and availability measurement; usability -> effectiveness, efficiency and satisfaction measured with representative users and tasks; security -> threat-driven and penetration-oriented approaches; portability and compatibility -> configuration and co-existence matrices. Always state the measurable acceptance criterion and how evidence is collected.
They describe a walkthrough as led by a trained moderator with formal entry and exit criteria and logged defects, or they give the moderator the job of deciding whether the document is ready for review and let the manager chair an inspection.
Review types differ mainly in degree of formality, which is a continuum rather than a checklist, and the role names overlap with ordinary meeting roles, so the distinctions collapse under exam pressure.
What to do instead
Fix one signature per type: informal = no defined process or roles; walkthrough = author leads, aim is learning and consensus; technical review = documented peer review by technically qualified reviewers with a chair/recorder; inspection = most formal, moderated, entry and exit criteria, individual preparation followed by a logging meeting. For roles: manager sponsors, allocates resources and decides; review leader plans and runs the review process (and in an inspection is normally the moderator); moderator chairs meetings; scribe records.
Asked which review approach to use, they answer 'checklist-based review' or 'scenario-based review' as if these were review types, and they describe ad hoc reviewing as a formal type with entry criteria and recorded findings.
The syllabus separates review types (process, roles, formality) from review techniques (how an individual reviewer reads the document), and both sets use similar adjectives, so answers swap the two categories.
What to do instead
Keep two separate boxes and check the noun in the question: types = informal, walkthrough, technical review, inspection; techniques = ad hoc, checklist-based, scenario-based, role-based/perspective-based. A technique question asks 'how do reviewers examine the document?'; a type question asks 'what process, formality and which roles apply?'
A crash in a rarely used report is graded low severity 'because nobody uses it', while a mistranslated label on the home page is graded high severity 'because everyone sees it'; in practice the severity and priority columns end up holding the same value.
Many workplace defect tools effectively use one field, and severity and priority are used as synonyms in everyday speech, so the candidate answers from habit rather than from the definitions.
What to do instead
Write the two definitions out before classifying: severity = impact on the system and stakeholders if the defect is encountered (crash, data loss, wrong calculation, security exposure); priority = the order in which it will be fixed (business value, visibility, workaround, contractual commitments). Then justify each field with its own sentence and check they are independently defensible.
They credit the test analyst with defining test policy or strategy, setting the test budget, or approving exit from a test level; or they remove the analyst from defect management entirely, saying defects are the test manager's responsibility.
Experienced candidates answer from their own job title, and in small organisations one person performs both roles, so the syllabus split between test manager and test analyst is blurred by personal experience.
What to do instead
Memorise the split as 'the manager owns the plan and the decision, the analyst owns the analysis and the evidence'. Analyst contributions in these areas: participating in product risk analysis, defining test conditions and cases, executing and recording results, raising, tracking and driving defect reports to closure, contributing to reviews, and reporting progress data. Approving exit criteria, setting budgets and selecting the overall strategy sit with the test manager.