In critique of ISTQB

The Loop

The ISTQB glossary, the dominant vocabulary standard in professional software testing, defines its core terms as follows:

  test            — a set of test cases
  test case       — developed based on test conditions
  test condition  — a testable aspect of a Component or System

"Component" is also defined in the same glossary:

  component       — a part of a System that can be tested in isolation

"Tested in isolation" — "tested" is the word the chain is supposed to construct. Following "Component" leads to the same dead end from a different direction.

Pull the thread one more level: "testable aspect" is not defined. A well-formed vocabulary must eventually reach a primitive — a term clear enough to need no definition of its own. ISTQB's chain reaches these dead ends and stops there, without acknowledgment. The chain does not loop. It ends in air.

This is not a minor editorial oversight. It is a structural problem at the base of a vocabulary that thousands of practitioners use daily and that certifies professionals across the industry.

ISTQB also lists three synonyms for test condition: test situation, test requirement, test idea.

These are not synonyms. They are four distinct concepts that the glossary collapsed into one term without acknowledging the compression:

  test idea        — an informal, pre-formalized seed ("I wonder if
                     the hinge gets stiff after repeated use")
  test requirement — the specification fragment that motivates the
                     test ("the hinge SHALL hold position when released")
  test situation   — the context in which the aspect is observed
                     ("lamp mounted vertically, room temperature,
                     after 100 cycles")
  test condition   — the formalized, specific claim to be evaluated into {true, false}
                     ("hinge rotates between 0°–180° without resistance")

These four live at different stages and dimensions of the same process. Calling them synonyms does not unify them. It buries the distinctions that a practitioner actually needs.

The Lamp

Consider a desk lamp with an adjustable hinge.

The lamp is the system under test. The hinge is an aspect of it — a particular part, considered from a specific viewpoint, implying neither completeness nor isolation. The hinge's range of motion, its resistance, its ability to hold position: these are testable aspects, because for each one an expected behavior can be stated and an actual behavior can be observed.

A testable aspect is therefore not mysterious. It is an aspect for which a specification can be written and an observation can be made — the two conditions that make evaluation possible.

What ISTQB calls a "test condition" is, in the lamp example: "the hinge holds its position when released at 90°." That is a specific, formalized claim about a testable aspect, derived from a requirement, evaluated within a defined situation. It contains all four of the glossary's collapsed synonyms — as distinct components, not as the same thing.

The Boolean Mask

The deeper problem surfaces when we ask: what is a condition, formally?

A first attempt: a function that maps input parameters to a Boolean output — true or false — or to undefined when evaluation is impossible.

The undefined case is already non-trivial. It formally distinguishes "the test failed" from "the test could not be evaluated" — which maps to what ISTQB calls a "blocked" result, without ever explaining why blocked is structurally different from failed. The function definition explains it: undefined is not false. The function did not return a verdict. It did not run to completion.

But the Boolean output itself is a mask.

Consider what conditions actually return in practice:

  f(hinge_angle, applied_force)  → "smooth" | "stiff" | "broken" | undefined
  f(lamp_brightness)             → 0..255 | undefined
  f(outside_temperature)         → -55.0°C | undefined (sensor drift active)
  f(system_state)                → "EMERGENCY" | "NORMAL" | "WARN" | undefined

None of these are Boolean by nature. The Boolean appears only as the result of a comparison: actual output measured against specification. The comparison is Boolean. The condition is not.

The full definition:

  A condition is a function that maps input parameters to an output
  of arbitrary type — or to undefined when evaluation is impossible.

"Testable" means: the output type is defined, observable, and comparable against a specification written in the same type. A spec for a classification condition is not "> 5". It is "∈ {smooth, stiff}" or a tolerance on a continuous value. The comparison operator is type-dependent.

The Boolean gate was always a lossy compression of this reality. Testing theory was built on the compressed version, inherited from logic gate abstraction, where the world had already been simplified to fit the gate — not the other way around. ISTQB then formalized that inheritance without marking it as a design choice.

The condition was never a judge. It was always a machine that may produce a verdict, or a classification, or a measurement, or nothing. We called it a "condition" because the Boolean case was the one we could reason about cleanly. The habit became the definition. The definition became the standard.

The Grounded Chain

Starting from mathematical primitives, the full vocabulary rebuilds without circularity:

  aspect           = a particular part or feature of something,
                     considered from a specific viewpoint —
                     implying neither completeness nor isolation

  condition        = f(inputs) → T | undefined
                     where T is arbitrary type: Boolean, enum,
                     continuous value, classification, distribution

  component        = a bounded, independently addressable unit of a system

  testable aspect  = an aspect of a component or system for which
                     such f can be defined, observed, and compared

  test idea        = an informal seed: a suspicion that a particular
                     f is worth evaluating

  test requirement = a claim that f must return a specified value
                     or fall within a specified range

  test situation   = the input domain and environment over which
                     f is evaluated

  test condition   = a specific f, bound to a system and situation,
                     with a stated expected output type and value

  test case        = one execution of f: inputs + expected output
                     + actual output + verdict

  test             = a set of test cases sharing a common objective

Every term derives from the one below it. No term is defined by a term above it. The chain has a bottom.

Placed directly against the ISTQB glossary:

Where the top-level terms look similar, the difference is the chain below them. ISTQB's has no bottom.

Implication

This is not an argument against ISTQB as a practical framework. The vocabulary works well enough because practitioners already carry the grounded meaning in their heads. The glossary confirms shared intuition rather than constructing it. For a practitioner certificate, that is sufficient.

The problem is that when something breaks — a test result is ambiguous, a condition cannot be evaluated, a classification does not fit the Boolean template — there is no foundation to return to. The glossary offers no footing below the level of habit.

A grounded vocabulary does not make testing harder. It makes the hard cases legible. The undefined output, the non-Boolean condition, the distinction between a blocked result and a failed one: these are not edge cases. They are the normal texture of real systems.

The lamp has a hinge. The hinge has a state. The state is observable. The observation is comparable. That is the whole story. Everything else is ceremony.