ISTQB Foundation common mistakes
ISTQB Foundation · Understand the traps and how to avoid them.
When a scenario describes a programmer mistyping a formula and the program later producing a wrong invoice total, the candidate labels the mistyping itself as the 'failure' (or labels the wrong invoice total as the 'defect').
Everyday English treats mistake, bug and failure as synonyms, and exams deliberately describe all three in one scenario so the candidate has to place each event in the right link of the chain.
What to do instead
Memorise the chain error -> defect -> failure and label every scenario by asking 'who/what is at fault and was anything executed?'. A human action is an error; the resulting flaw in a work product is a defect; the observable deviation from expected behaviour during execution is a failure. Practise by rewriting one-sentence bug reports into the three-part chain.
Selecting an answer that says a thoroughly tested system is proven to have no remaining defects, or that exhaustive testing is feasible if testers are given enough time, because the option sounds like the 'safe, thorough' choice.
The distractors are written to reward conscientious-sounding answers, while the seven testing principles require the opposite conclusion (testing shows the presence of defects, exhaustive testing is impossible, testing is context dependent).
What to do instead
Learn the seven principles as short slogans and, for every question, ask which principle is being tested before reading the options. Treat any option containing 'proves', 'guarantees', 'zero defects' or 'test everything' as a flag to re-check.
In a question about reviewing a requirements document against a checklist versus running the built product with real users, the candidate swaps verification and validation labels.
Both words mean 'checking' in ordinary speech, and the exam rarely uses the exact phrasing from the syllabus, instead describing the activity indirectly.
What to do instead
Anchor each term to one question: verification asks 'are we building the product right?' (specifications, reviews, static work, no execution) and validation asks 'are we building the right product?' (user needs, acceptance testing, executable behaviour). Before answering, decide whether the activity compares against a specification or against user needs.
A question describes testing the interactions and interfaces between two finished components, and the candidate answers 'system testing' or 'acceptance testing' instead of component integration testing.
The levels look like a simple ladder of size, so candidates map 'bigger than a component' to the next level up without checking the stated objective of the level.
What to do instead
Build a two-column table for each level (component, component integration, system, system integration, acceptance) listing its objective, typical test basis and typical responsible party. Interface and interaction testing belongs to integration levels, whichever pair of units is involved; end-to-end behaviour against requirements belongs to system testing.
When asked which activities happen in an iterative or incremental lifecycle, the candidate states that regression testing at all levels is mandatory in every iteration, or that in the V-model testing only starts after coding is complete.
Candidates generalise from one model they know, and 'V-model' visually suggests a single late testing phase, while 'iteration' suggests repeating everything fully each time.
What to do instead
Learn each lifecycle by its distinguishing feature rather than its diagram: the V-model pairs each development level with a corresponding test level and requires early test design, while iterative lifecycles allow different test levels to be entered, exited and re-entered per iteration with regression scoped to the risk of change. Answer using the characteristic named in the question stem.
Answering that static testing cannot find defects in requirements or design documents because no code exists to run, or that static analysis is a type of formal review performed by people.
Candidates equate testing with execution, and the word 'analysis' feels like a human judgement activity, so the tool-based and human-based branches get merged.
What to do instead
Hold one dividing line: static testing involves no execution of the software under test and splits into reviews (human) and static analysis (tool-based, typically on code and models). Then check the question stem for 'tool', 'compiler', 'coding standard' versus 'meeting', 'checklist', 'reviewers' to pick the branch.
Mixing up review roles and formality: naming the author as the person who leads a formal inspection, giving the moderator the job of recording findings, or ranking a walkthrough as more formal than a technical review.
The role names are familiar job titles in real workplaces but have precise definitions in the syllabus, and the four review types differ mainly by degree of formality rather than by obvious features.
What to do instead
Memorise formality order (informal review, walkthrough, technical review, inspection) and a one-line role map: manager decides what and when, moderator leads and plans, author fixes, scribe records, reviewers examine. For a question, first identify who is 'leading' (moderator in inspections) and who is 'recording' (scribe).
Given a valid input range, the candidate writes only tests for the boundaries themselves (for example 1 and 100 for the range 1-100) and omits the values immediately either side, then gives a boundary value analysis count that is wrong.
Boundary value analysis is taught with the phrase 'test the boundaries', so candidates stop at the edge values, and the 2-value versus 3-value variants are rarely distinguished in everyday discussion.
What to do instead
Always write out the partition tables first, then derive boundaries, including invalid boundaries: for 1-100 use 0, 1, 100, 101 (2-value) or 0, 1, 2, 99, 100, 101 (3-value). Read the stem to see which variant is implied and state the count explicitly, remembering each boundary belongs to a specific partition.
Computing white-box coverage as the number of passing tests divided by total tests, or claiming 100% statement coverage implies 100% decision coverage.
Percentages are read as 'success rate', and the one-way relationship between decision and statement coverage is counter-intuitive because decision coverage sounds strictly stronger in the wrong direction.
What to do instead
Fix the formula in mind: coverage = exercised items / total items of that type (statements or decisions). Then commit the implication to memory as '100% decision coverage guarantees 100% statement coverage, but not the reverse', because a decision can be exercised without its statements differing in outcome. Re-derive it on a small two-branch example before answering.
In risk-based testing questions the candidate ranks a risk by likelihood alone, or treats product risk and project risk as the same thing, so the chosen test priority and depth are wrong.
Risk is used loosely in everyday speech, and both product and project risks appear in the same syllabus chapter, so candidates assume any risk mentioned is about defects in the software.
What to do instead
Always apply risk level = likelihood x impact, and classify first: product risks concern quality characteristics of the software (a defect may harm users), project risks concern the management of the project (schedule, staffing, suppliers). Then map the top risks to earlier and deeper testing, and state that risk analysis and control are revisited as the project changes.
Choosing an answer that says a test automation or test management tool removes the need for testers' judgement, guarantees better software quality, or that the tool with the lowest licence cost is always the right selection.
Vendor messaging and everyday experience make tools sound like solutions to quality problems, and the syllabus's emphasis on tool support benefits makes the 'more automation is better' option attractive.
What to do instead
Learn the standard caveats: tools support but do not replace human judgement, they carry their own risks (unrealistic expectations, vendor lock-in, effort to maintain scripts, underestimating the learning curve), and tool selection is a structured evaluation of needs, constraints and a pilot, not a price comparison. Reject any option containing 'replaces', 'guarantees' or 'always'.