I have asked before and created a lot of controversy so I tried to collect some data and ask similar question again. E.g. V&V where all testing is only validation: http://www.buzzle.com/editorials/4-5-2005-68117.asp According to ISO 12207, testing is done in validation:

  1. •Prepare Test Requirements,Cases and Specifications
  2. •Conduct the Tests

In verification, it mentiones.

The code implements proper event sequence, consistent interfaces, correct data and control flow, completeness, appropriate allocation timing and sizing budgets, and error definition, isolation, and recovery. and The software components and units of each software item have been completely and correctly integrated into the software item

Not sure how to verify without testing but it is not there as a technique.

From IEEE:

Verification: The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. [IEEE-STD-610].
Validation: The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements. [IEEE-STD-610]

At the end of development phase? That would mean UAT..

So the question is, what testing (unit, integration, system, uat) will be considered verification or validation? I do not understand why some say dynamic verification is testing, while others that only validation.

An example: I am testing an application. System requirements say there are two fields with max. lenght of 64 characters and Save button. Use case say: User will fill in first and last name and save. When checking the fields and Save button presence, I would say its verification. When I follow the use case, its validation. So its both together, done on the system as a whole.


3 Answers 3


ISO 12207 has a rather non-standard (and very fuzzy!) distinction between verification and validation. In most circles, verification answers the question "did we build it right?" (does our product meet the requirements?), while validation means "was this the right thing to build" (do we have the right set of requirements?). ISO 12207 mentions requirements verification. How do you verify requirements, particularly the top level requirements? You don't. You validate them.

The product on which I spend the bulk of my time used to distinguish verification from validation. Problems with this distinction popped up on an annoyingly frequent basis. The distinction was clear to me, but my interpretation wasn't universally agreed upon. Is this a validation test or a verification test? Who cares? Why are we having this stupid fight? A rose by any other name smells just as sweet. The ultimate goal is to answer the question "Is it right?"

Our resolution to this ongoing imbroglio was to get rid of that distinction between verification and validation. We think of verification & validation as one word which together answer the question "Is it right?" We don't split V&V into arbitrary parts. What we split into parts is how we go about answering that singular question. Whether you're looking at our top level document or a detailed model document such as how we model gravity, chapter 5 is titled "Inspections, Tests, and Metrics". The old title, "Verification and Validation": It's gone. We don't split verification from validation. We instead split things into inspections, tests, and metrics. The chapter has typically has four sections, inspections, tests, traceability (typically automated), and metrics (also typically automated). Aside: Traceability analysis is just a specialized (but very important) kind of inspection. It's elevated as a separate section because of it's importance. We wrangled a tiny bit as to whether to call the chapter "Inspections, Tests, Traceability, and Metrics". The answer was no. No more religious wars over names. Traceability is a kind of inspection; the title still fits.

Things that answer the question "is it right" without actually using the product goes under the heading of "inspections". Requirements analysis, traceability analyses, analyses that demonstrate that the simplifying assumptions made by the model are acceptable for the model's intended use: They're all inspections because we didn't use the product. Traceability, while an inspection, has a home of its own. Using the product to answer that question go under the rubric of "tests". Everything from unit tests to tests against some artificial setup with a known analytic solution to integrated tests where we're comparing the results from the product to real data collected from some previously flown vehicle: They're all tests. Along the way we collect lots of metrics, many of them automated. Different levels of documents have different kinds of boring but important numbers. SLOC count, complexity, code coverage, number of waivers granted, number of issues in the CM system. Those boring but important numbers go under the rubric of "metrics".

Our developers and testers love this change because now it's crystal clear where things go. Project management loves this change because its consistent and because it removes all that silly wrangling over nomenclature. Our CMMI overlords love it because we're still answering the right question ("Is it right") and because we have a well defined process for getting there. Bean counters love it because we're giving them lots of beans that they are very easy to find and very easy to count.


Validation ensures that the product actually meets the user's needs, and that the specifications were correct in the first place, while verification is ensuring that the product has been built according to the requirements and design specifications.

enter image description here

what testing (unit, integration, system, uat) will be considered verification or validation?

Unit, Integration, and System testing are verification. UAT is validation.

  • 1
    +1 short and to the point. I would like to mention that things are somewhat clouded by practices like agile development which attempt to make validation happen earlier.
    – Daniel B
    Commented Oct 10, 2012 at 7:19
  • If it was that easy, why there is so much controversy? Look e.g. at the study here: idt.mdh.se/cbse-book/extended-reports/05_Extended_Report.pdf. It implies that if you test complete product against use cases, its validation, which is what testers do in e.g. SIT.
    – John V
    Commented Oct 10, 2012 at 7:19
  • @user970696 if by "controversy" you mean "disagreement over when / where you should do what", that's just the nature of things. There's no best approach to software development, with various approaches constantly being tested and evolved, and being applicable to different circumstances to varying degrees. And that's just the theory part. In practice, it's the same, with an added dose of chaos. In this case, I think it's just that there are examples which don't fit into those definitions you mentioned very nicely.
    – Daniel B
    Commented Oct 10, 2012 at 7:39
  • 1
    @user970696, verification evaluated requirements, plans, specification, documents, and code. Validation on the other hand, evaluates the product itself. The inputs of verification are checklists, issues lists, walkthroughs, reviews etc. The input of validation is the actual testing of an actual product. The outputs of verification are a set of accepted plans, specifications, and requirements documents. The output of validation, on the other hand, is a working product.
    – theD
    Commented Oct 10, 2012 at 7:43
  • @Shuvo Naser Thanks. However, you do not mention any output/input to verification related to unit, system or int testing. And in that comment you mention that input of validation is the actual testing of an actual product, also that is only for UAT, right? Reading last line of your answer, where you said just UAT is a validation.
    – John V
    Commented Oct 10, 2012 at 8:40

So the question is, what testing (unit, integration, system, uat) will be considered verification or validation?

Generally, speaking on high level your example and explanation sounds good.

In your example: verification is about making sure that "there are two fields with max. length of 64 characters and Save button." If some elements are missing according to requirement, then it does not pass verification. It is also a first step.

"validation is" - more about input and behavior of given required elements. In your case, it is validation of max. and min. input length, special character allowance, and any other related business rules.

All this is done on unit testing first and propagated to next stages if there are some related business-data flow.

  • thanks. However, isnt validation more about the purpose? E.g. "user needs to enter data in two fields and save". Allowance of chars, its min. and max lenght..I would say its verification..?
    – John V
    Commented Oct 10, 2012 at 12:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.