Comment by rook_line_sinkr a day ago
I got told to use these words back in uni
verification - Are we building the software right?
validation - Are we building the right software?
makes many a thing easier to talk about at work
I like to talk about goals and not requirements.
What is your product goal? Both for the customer (solving a problem) and for the company(solve a marketing need, make money)?
Can you proof that you are meeting both? Then you are validating your goals successfully.
Most of the time products are missing defined goals, so lots of people have no idea what the fuck they are developing and everyone ends up with their own idea of the product.
Usually there's a separate document that has the requirements, and from that document you have a "software detailed design" which has the specifications for how to build the software such that it upholds the requirements. Subtle but important difference.
There is an important and distinct pair of definitions used by a possibly smaller but significant number of people:
Verification: formal theoretical proof
Validation: Empirical test based approach
Just by reading the headlines I immediately suspected the topic of Verification vs Validation would be involved. I still cannot comprehend why it is still such a gap in many software projects I have worked in. Everyone knows about testing but barely a few understand or want to understand why Validation is equally important.
While this is a good general rule of thumb, this terminology has nothing to do with how these terms are formally defined.
Verification first and foremost concerns design and development stage, a formal definition would be something like "outputs of design and development step meet specified requirements for that step". For example, you could verify that a formal specification for a module actually implements imposed requirements. Especially in software this can get murky as you cover different phases with different tests/suites, e.g. unit, integration, e2e implicitly test different stages, yet are often part of the same testing run.
Validation first and foremost concerns the whole system/product and fitness for market availability.
For example you would verify that e.g. for a motor vehicle ABS functions correctly, airbags deploy in a crash and frame meets passenger safety requirements in a crash, and you would still not be able to sell such vehicle. You would validate the vehicle as a whole with corresponding regulatory body to get vehicle deemed fit for market.
TLDR: Verification is getting passing grade in a lab test, validation is submitting all relevant lab test protocols to get CE certified.
If it's hard to remember which is which, maybe they should be different words.
Like "Customer validation" and "Verification against the spec"
Like "sympathy" and "empathy". I finally heard a mnemonic but if I need a mnemonic maybe it's a sign that the words are just too hard to understand
I just don't bother to shorten it...
- Did we correctly understand and build what the customer asked for
- Did the customer actually ask for what would solve the problem they are trying to solve
The second one is very important to ask early on, and _not_ asking it can cause a lot of wasted time. When I'm in a position to comment on whether I think someone fits the requirements of a senior developer, whether or not they ask that question plays directly into it.
Etymology to the rescue. "Valid" and "value" share a root, and so do "verify" and "verity." You validate something to see if it has value, meaning it works and is fit for purpose. You verify it to check that it is true and meets its specifications. Does that help? :)
Yep... Along with this
Verification aligns with a specification. E.g. verify if what was implemented matches what was specified.
Validation aligns with a requirement. E.g. verify if what was implemented solves the actual problem.