In reply to gbaudhuin.

In most uses of 'actual' validation, it is paired with a verification phase. It is a dual process, usually seen as "verification & validation".

Let's consider eg the verification & validation of a pudding recipe (which is a program for converting ingredients into a define outcome or product, under specified manipulations).

Eggs: check. Milk: check. Flour: check. We have now verified the correct ingredients.

Oven preheated 350 degrees F: check. Ingredients combined in the given order: check. We have now verified the proper preconditions for program execution.

To perform the validation phase, cook the verified ingredients: execute the program. Did the program-execution result in pudding? 'The proof is in the pudding'. Do not use children to judge (or test) the pudding: use your in-laws, preferable your mother-in-law. If it's pudding, the recipe is validated.

To validate code, it must be executed. You can't know if it produces the intended pudding, unless you run it.

Verification is static. In an airplane version of pudding, we verify that the plane is 'ready' or 'prepared' to fly using a preflight checklist (while parked static on the tarmac). The case of an aircraft clarifies that the proof (or validation) is dynamic: it is in the flying. The preflight is the verification, in an airworthiness V&V.

The WordPress Themes Guidelines appear to be a preflight checklist. The ThemeCheck plugin appears to be an automated tool, for conducting the static preflight or (pre-execution) verification component of a two-phase theme verification & validation.

And then, verification & validation itself is but one phase in various multiphase processes that aim to establish eg code quality, and security, among other states & metrics.