# What is the difference between verification and validation?

Verification checks software against its specification, while validation checks it against users' needs, and neither is defined by whether the code runs.

Last updated September 29, 2026, 8 min read

## Learning objectives

After reading this article you will be able to:

-   Define verification and validation
-   Explain why standards bodies define them differently
-   Compare where each happens in a project

## Related content

-   [How to test AI-generated code](https://specstory.com/learning/verification/ai-generated-code-testing)
-   [What is the difference between reading code and running code?](https://specstory.com/learning/verification/reading-vs-running-code)
-   [What is runtime verification?](https://specstory.com/learning/verification/runtime-verification)
-   [Why do coding agents say "done" when the code doesn't work?](https://specstory.com/learning/verification/coding-agent-done-claims)

## What is the difference between verification and validation?

Verification checks whether software matches its [specification](https://specstory.com/learning/glossary#software-specification), and validation checks whether it meets the needs of the people who use it. Together they are called verification and validation (V&V). Verification asks whether the team built it right. Validation asks whether the team built the right thing. Software can pass one check and fail the other.

The two differ in the reference each check uses, not in whether the code runs. A review that runs nothing and a test that runs the code can each serve either purpose.

The gap between them opens when the specification leaves part of the need out. Software can then pass every verification check and still fail its users. The same gap can open in [AI-generated code](https://specstory.com/learning/verification/ai-generated-code-testing), because a [coding agent](https://specstory.com/learning/ai-coding/coding-agent) builds from a prompt that may state only part of the need.

## What is verification?

The International Software Testing Qualifications Board (ISTQB) [defines verification](https://glossary.istqb.org/en_US/term/verification) as the process of confirming that a work product fulfills its specification. The ISO 9000 definition, which [NIST's glossary quotes](https://csrc.nist.gov/glossary/term/verification), adds that the confirmation rests on objective evidence.

Verification can use any method that compares a product with its specification:

-   **Review.** A person reads the code or a design and compares it with the specification. [Code review](https://specstory.com/learning/code-review/code-review) of a pull request is one common case.
-   **Static analysis.** A [static analysis](https://specstory.com/learning/code-review/static-analysis) tool examines the source without running it, e.g. a type checker that compares each call with its declared types.
-   **Tests.** A test runs the code and compares its output with a value taken from the specification. Tests that run code are one form of [dynamic analysis](https://specstory.com/learning/code-review/static-vs-dynamic-analysis).
-   **Mathematical checks.** [Formal verification](https://specstory.com/learning/glossary#formal-verification) uses mathematics to show that a program or model meets its specification, instead of testing sample inputs.

A passing verification shows that the software matches the specification on the points it checked. It shows nothing about whether the specification was right.

## What is validation?

The ISTQB [defines validation](https://glossary.istqb.org/en_US/term/validation) as confirmation by examination that a work product matches a stakeholder's needs, e.g. a customer's. The ISO 9000 definition, in [the NIST glossary](https://csrc.nist.gov/glossary/term/validation), ties it to the requirements for a specific intended use.

Validation methods start from the user's side:

-   **Requirement review.** The team reads the specification back to the people who asked for the software, before any code exists. This kind of validation runs nothing.
-   **Acceptance testing.** [Acceptance testing](https://specstory.com/learning/testing/acceptance-testing) checks whether the finished software meets its acceptance criteria and its users' needs. Users or the person who asked often take part.
-   **Workflow runs.** Someone runs the software the way a user would, from start to finish, and judges the outcome against the goal of the task.

[Software testing](https://specstory.com/learning/testing/software-testing) serves both purposes. The ISTQB Foundation syllabus says that testing involves verification and also involves validation.

Diagram: What verification and validation compare against

Verification looks back from the software to the specification. Validation looks back to the needs, and a team can validate the specification itself before any code exists.

## When should a team verify or validate?

Here is an illustrative example. A developer at Acme Co., which sells furniture online, asks a coding agent to "Let customers edit their delivery address during checkout." The team checks it at five points:

1.  **Before the build.** The developer writes the spec "The customer can change the delivery address at checkout," and reads it back to the product owner, which validates the spec without running code.
2.  **During the build.** The agent's unit test sets the address to "12 Elm Street" and checks that `order.address` equals it. This verification passes.
3.  **At review.** A reviewer compares the diff with the spec, verifying the change without running it.
4.  **Before release.** A tester runs the checkout as a customer would, with 2 items in the cart. The address saved, but the cart emptied. The software met its spec but not the need, so validation fails.
5.  **After the fix.** The team adds "Changing the address keeps the cart" to the spec, with a test for it. Verification now checks the cart too.

Verification fits each change, because the spec says what to compare. Here, validation fits the spec and the release, where a person judges the need. The step 1 review missed the cart rule, which nobody had stated. This example is simplified. A real project would also validate with customers before a wide release.

## What changes when a coding agent writes the code?

A coding agent's "done" is at most a verification claim. The agent checks its code against its own version of the request, often with tests it wrote in the same session. It may also write the plan or spec it works from. When that version leaves part of the need out, the code, the tests, and the plan share the gap, and the tests pass.

Validation needs a reference the agent did not write, which is the need of the person who asked. [Spec-driven development](https://specstory.com/learning/ai-coding/spec-driven-development) gives a team one when a person reads and approves the specification before the agent starts. Later checks then verify against a spec that was validated first.

A run of the finished software through a user's task can also validate the change, when the person who asked sets what counts as a pass. Some developers call that run [runtime verification](https://specstory.com/learning/verification/runtime-verification), using "verification" in the wider sense described below. Its [test oracle](https://specstory.com/learning/test-quality/test-oracle) then comes from the person, not from the agent.

## Why do standards define them differently?

Each body wrote its definitions for its own kind of work, and the main sources differ in these ways:

-   **ISTQB and IEEE 1012.** Both tie validation to users' needs. ISTQB ties verification to the specification, and the IEEE 1012 standard for verification and validation ties it to the requirements of each development activity.
-   **ISO 9000.** The quality management vocabulary makes a similar split for any product, not only software, and asks for objective evidence in both.
-   **INCOSE.** The systems engineering definitions that NIST quotes match the wording of the older IEEE 610.12 glossary, which ties verification to development phases. Verification there checks whether each phase's output meets the conditions set at the phase's start. Validation checks whether a system satisfies specified requirements, which is close to ISTQB's verification.
-   **National security.** A definition of [independent verification and validation](https://csrc.nist.gov/glossary/term/independent_verification_and_validation) from the Committee on National Security Systems uses "verify" for checking that requirements are correctly defined. It uses "validate" for checking that the system implements them. The committee's own entries for each word follow the usual split.
-   **Tool vendors.** Some vendors use "verification" only for checks that read code and "validation" for checks that run it. Neither ISTQB nor ISO 9000 defines the words by method.

Before relying on either word in a document, check which reference it names. This learning center uses "verification" in a wider sense, for any check that produces evidence about software, including running it. That sense covers both columns of the table below.

## How do verification and validation compare?

Verification and validation differ on these attributes:

| Attribute | Verification | Validation |
| --- | --- | --- |
| Question | Did the team build it right? | Did the team build the right thing? |
| Reference | The specification | Users' needs and the intended use |
| Typical methods | Reviews and tests against the spec | Acceptance tests and requirement reviews |
| Who usually takes part | Developers, testers, and reviewers | Users, or testers acting as users |
| Runs the code | Not required | Not required |
| When it happens | Throughout the build, on each change | At the spec, and whenever users try a build, e.g. before release |
| What a pass shows | The software matches the spec on the checked points | The software meets the need in the checked cases |
| What it misses | A wrong or incomplete spec | Defects that the checked tasks never reach |

When the specification states the need in full, a pass against one reference is also a pass against the other. For either check, reading can miss what the software does when it runs, and [running code](https://specstory.com/learning/verification/reading-vs-running-code) shows only the paths a run reaches.

## FAQs

### Is testing verification or validation?

Testing is verification or validation depending on its reference. A test that compares output with the specification verifies the software, and an acceptance test built from a user's task validates it. The ISTQB Foundation syllabus says that testing involves both.

### Does verification include running the code?

Verification includes running the code when a test compares a running program with its specification. Reviews and static analysis verify without running anything. The ISTQB definition ties verification to its reference, the specification, and not to whether the code runs.

### Which comes first, verification or validation?

Verification and validation do not follow a fixed order. Validation usually comes first for the specification, when the team reads it back to the people who asked. Verification then runs throughout the build, and validation returns before release.

### Is code review verification?

Code review is verification when the reviewer compares the change with its specification. A review becomes validation when it judges the work against what users need, e.g. a review of the spec with the people who asked. Neither kind of review runs the software, so neither observes how it behaves.

---

Source: [Verification vs. validation in software testing | SpecStory](https://specstory.com/learning/verification/verification-vs-validation)