ISTQB Vocabulary — Software Testing Certification Language

Verification asks "does this match the specification?" — e.g. does the code implement the design document correctly, does the requirements document match the business need as documented. It is frequently done through static testing (reviews, walkthroughs, static analysis) without running the software.

Validation asks "does this actually solve the user's problem?" — even a system built exactly to a flawed specification can pass verification but fail validation if the specification itself didn't capture what users actually need. Validation is typically done through dynamic testing — actually executing the software (e.g. user acceptance testing).

The classic mnemonic: "verification = building the product right; validation = building the right product." A team can perfectly verify a feature against its spec and still discover in validation (UAT) that the feature doesn't solve the user's actual problem — this is a common, well-tested exam scenario.

Retesting (confirmation testing) re-runs the exact test case(s) that originally found the defect, using the same steps and data, to confirm the specific defect no longer occurs.

Regression testing is broader: it re-runs previously passing tests (often a curated regression suite, not every test in existence) to catch any unintended side effects the fix or change may have introduced elsewhere in the system — functionality that was working before and should still be working now.

Why the distinction matters: retesting alone only proves the reported bug is gone; it says nothing about whether the fix broke something else. A change that passes retesting but is never regression tested can silently break unrelated features — a very real and frequently tested exam scenario, and a real production risk. Automated regression suites exist specifically because manually regression testing after every change does not scale.

Severity = how bad the defect is technically/functionally — does it crash the system, corrupt data, or just cause a minor visual glitch? This is usually assessed by testers/QA based on impact.

Priority = how urgently it needs fixing, based on business context — customer impact, release schedule, workaround availability, and how often the affected path is used. This is usually set by the product owner or a triage process, sometimes overriding what severity alone would suggest.

Example that matches the question: a crash (critical severity) occurring only in a legacy admin tool being retired next month and used by one internal employee could reasonably be Low priority — fix it eventually, but don't block the release for it. Conversely, a very minor visual misalignment (low severity) on the primary checkout button right before a major marketing campaign could be High priority.

This is one of the most heavily tested ISTQB distinctions because in real teams, severity and priority are frequently confused or conflated — being precise about which one you mean (and why they can diverge) is a core professional communication skill in bug triage.

Boundary value analysis (BVA) specifically targets the edges of input ranges, because experience shows defects (off-by-one errors especially) cluster at boundaries — e.g. a developer writing age > 18 instead of age >= 18 would incorrectly reject exactly 18. Testing 17, 18, 65, and 66 directly probes for these edge-case bugs.

Equivalence partitioning (EP) is a related but distinct technique: it divides the input domain into partitions (classes) that the system is assumed to treat identically — e.g. "invalid: below 18", "valid: 18–65", "invalid: above 65" — and tests just one representative value from each partition (e.g. 10, 40, 90), on the assumption that if one value in a partition works/fails correctly, the rest of that partition will behave the same way.

In practice, BVA and EP are used together: EP identifies the partitions economically (reducing the number of test cases needed versus exhaustive testing), and BVA then adds targeted tests at the boundaries between those partitions where bugs are statistically more likely. Both are black-box, specification-based techniques — they don't require looking at the code itself.

Entry criteria answer "are we ready to start testing this level/phase?" — testing a build before unit tests even pass, or before it's deployed to the right environment, wastes tester effort finding "bugs" that are really just broken deployment or missing prerequisites (the test basis wasn't even ready).

Exit criteria answer "are we done, and can we confidently say so?" — objective, pre-agreed measures (test coverage percentage, defect density thresholds, no open Critical/High severity defects) avoid the common, subjective, and risky judgement call of stopping testing simply "because time ran out" or "it feels okay now."

These map to the concept of test levels in ISTQB — unit/component testing, integration testing, system testing, and acceptance testing (including UAT) — each of which typically has its own entry and exit criteria, since the objectives and test basis differ at each level (e.g. unit testing verifies individual components against low-level design; acceptance testing validates the whole system against business needs).

Precisely stating entry/exit criteria in a test plan is what allows a tester to say, in a status meeting, "we haven't met exit criteria yet — there are still two open Critical defects" as an objective, defensible statement rather than a subjective opinion about readiness.