# Verification vs validation in software testing

> Verification checks you built it right; validation checks you built the right thing. Standards definitions, a table, and why agent code breaks the old split.

Source: https://qa.tech/blog/verification-vs-validation · Published: 2026-10-12

---
Verification asks whether you built the product right. Validation asks whether you built the right product. Barry Boehm put it that way in 1979, and most teams still use his two questions to tell them apart.

**The short version:** verification checks a piece of work against its specification: reviews, static analysis, unit and integration tests, anything that compares an output to a written requirement. Validation checks the finished product against what the user needed: running it, end to end, in something like its real environment, and asking whether it does the job. Testing belongs to both. What has changed in 2026 is who writes the code. When an agent builds the feature and its tests from the same reading of the ticket, the unit tests verify the agent's understanding, and validation against the running product is the layer most pipelines still run by hand.

## Verification vs validation: the definitions

IEEE 1012 defines verification as "the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase," and validation as the process of providing evidence that the software products "solve the right problem, and satisfy intended use and user needs" ([SEBoK](https://sebokwiki.org/wiki/Verification_(glossary)), [SEBoK](https://sebokwiki.org/wiki/Validation_(glossary))). ISO/IEC/IEEE 15288 is shorter: verification confirms "the system was built right," validation confirms "the right system was built."

ISO 9000:2015 is the wording most testers learned, and the ISTQB glossary uses the same sentences ([NIST CSRC](https://csrc.nist.gov/glossary/term/verification), [ISTQB](https://glossary.istqb.org/en_US/term/verification)). Verification: "Confirmation, through the provision of objective evidence, that specified requirements have been fulfilled." [Validation](https://csrc.nist.gov/glossary/term/validation): the same sentence with "the requirements for a specific intended use or application" in place of "specified requirements." That one substitution, specified requirements versus intended use, is the whole distinction.

The FDA's [General Principles of Software Validation](https://www.fda.gov/media/73141/download), the 2002 guidance medical-software teams still cite, says verification "provides objective evidence that the design outputs of a particular phase of the software development life cycle meet all of the specified requirements for that phase," and validation is confirmation "that software specifications conform to user needs and intended uses."

Boehm's two questions are the version people remember. Verification: are we building the product right? Validation: are we building the right product? The origin is his 1979 Euro IFIP paper on verifying and validating requirements and design specifications ([Spillner and Linz, reference list](https://www.oreilly.com/library/view/software-testing-foundations/9781681988559/Text/appendicec.xhtml)); the 1981 book *Software Engineering Economics* ([Wikipedia](https://en.wikipedia.org/wiki/Verification_and_validation)) and a 1984 *IEEE Software* article ([Wikipedia](https://en.wikipedia.org/wiki/Software_verification_and_validation)) are the citations most people use.

## Side by side

| | Verification | Validation |
|---|---|---|
| **Question** | Did we build it right? | Did we build the right thing? |
| **Compared against** | The specification, design or requirements for that phase | User needs and intended use |
| **Typical activities** | Code review, static analysis, type checks, unit tests, integration and contract tests, design reviews, traceability | End-to-end tests of user journeys, acceptance testing, exploratory testing, beta and field use |
| **Needs a running product?** | Often not; much of it is on artifacts | Yes, or something close to it |
| **Can be done by the author?** | Mostly, though standards prefer independence | Weakly; the author's understanding is what is under test |
| **Catches** | Deviations from the spec, defects in the work | Specs that were wrong, gaps between spec and need, behaviour that only shows up assembled |
| **Where it lives in the V-model** | Commonly taught as the left side, phase by phase | Commonly taught as the right side, assembled upward |

## Examples from a normal pipeline

A pull request lands. The linter runs: verification. Types compile: verification. The unit tests the author wrote pass: verification, against the author's reading of the ticket. A reviewer reads the diff against the design doc: verification. Then someone opens the preview build and tries to do the thing the ticket was for. That's validation, and in most pipelines it's the only validation, and it's a person.

The regulated industries wrote this down because they had to. In DO-178C, the airborne software standard, "Testing forms a part – but not the whole – of verification," which also covers reviews of plans and design artifacts and analysis where testing is inconclusive, and some objectives must be met "with independence," meaning the verifiers did not develop the software ([Rapita](https://www.rapitasystems.com/node/528)). NASA goes further and runs independent verification and validation as an organisation that is "technically, managerially, and financially independent" of the development organisation ([NASA](https://swehb.nasa.gov/x/_AAdAg)).

The clause that carries over to agent pipelines is independence: whoever built the thing does not get to confirm it works.

## What changes when an agent writes the code

Ninety percent of developers now use AI at work, with a median of two hours a day, and 30% of them report little or no trust in the code it produces ([DORA 2025](https://blog.google/technology/developers/dora-report-2025/)). In the [Stack Overflow 2026 survey](https://survey.stackoverflow.co/2026/ai), 48% say they trust AI "when they can easily validate the answers." Validation is the condition developers themselves put on trusting the output. The question is who does it, on a change set the human did not write.

**The unit tests are now the agent's.** In a human pipeline the author wrote both the code and the tests, and we accepted that because a reviewer independently read both. In an agent pipeline the agent writes both from one reading of the ticket, and nobody reads both any more.

**Passing the spec is not the same as meeting the intent.** Birgitta Böckeler, writing on [martinfowler.com](https://www.martinfowler.com/articles/harness-engineering.html) in April 2026, puts the boundary on it: "Correctness is outside any sensor's remit if the human didn't clearly specify what they wanted in the first place." An agent-written test suite that passes tells you the code matches the agent's model of the spec. It doesn't tell you the agent's model matched yours. We have had this happen in our own pipeline, with a never-do constraint in both the RFC and the spec; the full account is in [spec-driven verification](https://qa.tech/blog/spec-driven-development-verification). The agent's tests cannot check whether the agent read the spec correctly.

**The loop is open.** [Vilhelm von Ehrenheim](https://www.linkedin.com/in/vilhelm-von-ehrenheim/), our co-founder and Chief AI Officer, describes the default agentic pipeline: "You put intent in, the agent produces code, and it lands in your code base. Forward arrows only. There is nothing coming back." Validation is the arrow back. Without it the only signal that the right product was built is the agent saying it's done.

Teams running agent fleets feel this as review load before they can name it: review is verification, and in most of them the validation half has no owner at all. The numbers are in [agent evals vs testing](https://qa.tech/blog/agent-evals-vs-testing).

## Validation against the running product

[Daniel Mauno Pettersson](https://www.linkedin.com/in/danielmaunopettersson/), our co-founder and CEO, on why the test cannot come from the code: "If you don't trust the change in the first place, you really have to trust the change in the test. To actually test what you were intended for, the intended change." If the code is suspect, the test has to come from the intent, and from someone who did not write the code.

That is a validation test in the standards' sense, with one update: it can be automated now. An agent that did not write the code can read the ticket or the PR description, open the preview build, attempt what a user would attempt, and report what it observed. Our own product team describes the difference between that and a script with the dashboard example: a Playwright script that checks you reach `/dashboard` after login passes while every metric on the dashboard is broken, "because what you wrote is, I want to verify the user is at /dashboard." A goal written as the user's outcome catches that where a URL assertion doesn't.

The report is also different from a unit test's. A validation verdict has to be able to say it could not reach a conclusion. Daniel sees the deterministic-script instinct everywhere: "Everybody, they do the bare minimum, which is kind of running this, creating this deterministic task, which gives you some sense of security." A validation verdict needs a third state for the run that could not reach the flow at all, and it should say so instead of going green.

## Running both in an agentic pipeline

The working model is four layers, which we lay out in [how to verify the work of coding agents](https://qa.tech/blog/how-to-verify-coding-agent-work): static checks, the tests the agent wrote, review agents, and the behaviour of the running product. The first three are verification. Only the fourth is validation, and it is the one most pipelines run by hand or not at all.

On QA.tech the fourth layer is a change review on the pull request. It will not tell you the code is clean, and when it cannot reach the flow it says so instead of passing it. What it covers is the standards' two conditions for validation: the verifier did not write the code, and the verdict comes with evidence. It takes the PR description and linked ticket as the statement of intended use, exercises the preview build against them and posts pass, fail or unable to verify on the PR ([docs](https://docs.qa.tech/pr-testing/overview)); you can make that verdict a merge gate ([GitHub App docs](https://docs.qa.tech/configuration/github-app)). In our own vocabulary we call this layer verification, because it checks the change against the intent on the running product; in the standards' vocabulary that is validation.

If you're not ready to automate it, at least name it. Put a validation step on the PR template that says what a user should be able to do after the merge, and make somebody other than the agent try it. The [large regression suite](https://qa.tech/blog/large-regression-suite-is-a-liability) you may be tempted to build instead is verification of yesterday's spec; validation is about the change in front of you.

## FAQ

**What is the difference between verification and validation in software testing?**
Verification checks a work product against its specification: did we build it right? Validation checks the finished product against the user's need: did we build the right thing? Verification can be done on artifacts; validation needs the product, or something close to it, running.

**Is testing verification or validation?**
Both. Unit, integration and contract tests verify code against a spec. End-to-end tests of user journeys, acceptance tests and exploratory testing validate the product against intended use. DO-178C, as Rapita's guidance puts it, treats testing as one part of verification alongside reviews and analysis.

**What is V&V?**
Verification and validation, treated as one discipline. In regulated software (FDA guidance, DO-178C) V&V is a documented process with evidence; IV&V, independent V&V, is the same work done by a team independent of the developers, which NASA runs as a separate programme.

**Who said "building the product right" versus "building the right product"?**
Barry Boehm, in a 1979 paper on verifying and validating requirements and design specifications, restated in *Software Engineering Economics* (1981) and in *IEEE Software* (1984).

**Does verification come before validation?**
Usually, and the V-model is commonly taught that way: verification on the left, phase by phase against the spec, validation on the right as the system is assembled. In practice they interleave, and in an agentic pipeline validation belongs on every pull request.

**Are tests written by a coding agent verification or validation?**
Verification, against the agent's own reading of the ticket. They cannot validate, because what validation checks is the agent's own understanding of the ticket, and that understanding produced the tests. Validation needs a check the agent did not write, against the running product.