ISTQB K2 Practice Questions

Verification vs versus Validation

Verification asks whether the product was built to the specification; validation asks whether the specified product was the right one to build.

How to tell them apart: Both are checked against something written down, so the specification is not the tell. Ask whose satisfaction settles it - conformance to the stated requirement is verification, fitness for the user's actual need is validation. Acceptance testing focuses on validation.

Root Cause → leads to Error → leads to Defect → leads to Failure

A root cause is what led a person to make an error, the error leaves a defect in a work product, and the defect may cause a failure when the software runs.

How to tell them apart: Walk the chain and find where the question sits. Only a failure is something you can observe happening; a defect sits in an artefact whether or not anyone runs it; the root cause is what, if removed, would stop the error recurring. The chain is closed at neither end: some defects never cause a failure, and a failure can also come from environmental conditions such as radiation, with no error behind it.

Testing vs versus Debugging

Dynamic testing shows that a failure occurred; debugging is the development activity that then finds the defect causing it, analyses it, and removes it.

How to tell them apart: The defect is debugging's output, not its input - do not confuse it with root cause analysis, which looks further back at why the error was made. Static testing finds defects directly, with no failure and nothing to debug, so 'a failure was observed' is not part of the definition of testing.

Test Objective vs versus Test Condition

A test objective is why you are testing at all; a test condition is a specific aspect of the test object that a test could be built to exercise.

How to tell them apart: Objectives are stated once for a level or a project and are about purpose - building confidence, finding defects, meeting criteria. Conditions are enumerated during test analysis and are countable. If the question asks what test analysis produced, it wants conditions.

Confirmation Testing vs versus Regression Testing

Confirmation testing re-runs what failed to prove the fix worked; regression testing re-runs what passed to prove the change broke nothing else.

How to tell them apart: Look at what the question says was tested, not why. Retesting the fixed thing is confirmation; testing everything around it is regression. Confirmation testing always follows a defect fix, but regression testing follows any change at all, including an enhancement.

Test Level vs versus Test Type

A test level says when in the lifecycle testing happens; a test type says which quality characteristic it is aimed at.

How to tell them apart: These are two independent axes, not a hierarchy - any type can be applied at any level. CTFL v4.0 has five levels: component, component integration, system, system integration and acceptance testing, so v3.1's four-level list is a distractor. Of the four test types, functional and non-functional name a quality characteristic, while black-box and white-box name a derivation basis instead.

Black-box Testing vs versus White-box Testing vs versus Experience-based Testing

Black-box testing derives tests from the specified behaviour without reference to the internal structure; white-box testing derives them from that structure; experience-based testing draws on the tester's knowledge and intuition rather than either.

How to tell them apart: The deciding detail is what the tests were derived from, not who ran them or at which level. Deriving from a requirement is black-box even when a developer does it at component level. Experience-based is the family left when neither the specification nor the structure gives you the test, and the syllabus treats it as complementary to the other two rather than a substitute for them.

Work this distinction in full →

Alpha Testing vs versus Beta Testing

Alpha testing is performed at the developing organisation's site by people from outside the development organisation; beta testing is performed by potential or existing users at their own location.

How to tell them apart: The deciding detail is where the testing happens and whose site it is - not how finished the product is, and not whether defects are still being found.

Static Testing vs versus Dynamic Testing

Static testing examines a work product without executing it; dynamic testing requires the software to be run.

How to tell them apart: The sharper contrast is what each one finds: static testing finds defects directly, while dynamic testing causes failures from which the defect is then inferred. Static includes static analysis tools, not only human reviews.

Walkthrough vs versus Technical Review vs versus Inspection

A walkthrough is led by the author and used to evaluate quality and build understanding; a technical review is led by a moderator and aims at consensus or a decision on a technical problem; an inspection is the most formal type and aims at finding the maximum number of anomalies.

How to tell them apart: Do not separate these by who leads - a technical review and an inspection are both moderator-led. Separate them by objective and formality. Only an inspection follows the complete generic review process, collects metrics, and forbids the author from acting as review leader or scribe.

Statement Testing vs versus Branch Testing

Statement testing exercises the executable statements in the code; branch testing exercises the branches - the transfers of control between nodes, which in CTFL v4.0 means unconditional ones as well as decision outcomes.

How to tell them apart: Branch coverage subsumes statement coverage: 100% branch coverage guarantees 100% statement coverage, but not the reverse. One test through an if with no else can run every statement while leaving a branch untaken. Beware the v3.1 answer that equates a branch with a decision outcome only.

Work this distinction in full →

Project Risk vs versus Product Risk

A project risk threatens the delivery of the project; a product risk threatens the quality of the thing delivered.

How to tell them apart: Ask what suffers if the risk occurs. A late supplier or an absent tester is a project risk. Software that miscalculates or leaks data is a product risk.

Entry Criteria vs versus Exit Criteria

Entry criteria are the preconditions for sensibly starting an activity; exit criteria are what must be achieved before it can be declared complete.

How to tell them apart: Read the direction of the gate. Readiness, environments and available test data are entry criteria. Coverage achieved and defects outstanding are exit criteria.