What's the difference between data Validation and Verification? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

My recollection from a past employer is that they distinguished between the two as follows:

• Validation is the process of checking that the data is appropriate in a very basic sense; for example that data in a date field can be 开发者_运维知识库converted to a date, or that characters in a number field can be converted to a number of the appropriate type;
• Verification is the process of checking the typed data against some other 'business' rules that you impose on your interface - for example that the Date Of Birth field indicates an applicant within a certain age range.

These memories do not tie in with the Wikipedia article on the subject, nor a BBC BiteSize Revision article.

So what is the consensus: Do people care what methods and processes are called when I am checking Xml inputs for example?

What am I doing when I:

1. Check that a date field contains characters that are convertible to a C# DateTime;
2. Check that the DateTime is in an appropriate date range to be stored in SQL Server;
3. Check that the Date Of Birth indicates a customer over 18 but under 65?

---

In my vocabulary, validation is checking whether the format of the data is correct, IE if a you're actually dealing with a correctly formatted date string . Verification is checking whether the date you got is actually the date you were expecting.

---

Ok, so I'll take this as an open invitation to musing...

I think the difference is very much like compile-time vs. runtime errors. Just like the compiler is able to tell that two variables a,b are of type double, and thus the expression a/b is valid, it is only during runtime a DivideByZeroException may be raised if b turns out to be 0.

So to complete the analogy, one can validate that a string looks like a credit card number ('compile time'), but can only verify that it corresponds to a valid card only if one tries to charge the credit card ('runtime') with an amount

Duh. So I guess I understand it pretty much like you old company does.

---

in terms of programming it makes no difference what you call it (validation or verification) but where you put the logic is important. usually all three rules you mentioned are known to be validations with first two points corresponding to UI validation and last point to business rule validation. we usually validate UI fields using dataannotations in our controller and Business rule validation is performed within business layer. But the bottom line from software point of view is; don't do an operation (save, edit) unless data is good (you call it valid or verified).