Verification vs Validation — V&V in Engineering

Verification answers "Are we building the system right?" — checking that the design and implementation conform to specified requirements. Validation answers "Are we building the right system?" — confirming that the final product satisfies the actual customer need. Both are required, and confusing them is a common and costly engineering error.

Why companies use it

·Regulated industries (medical devices, aerospace, automotive) require formal V&V as part of design control and certification
·Separating the two activities prevents the failure mode of a perfectly specified but wrong product reaching the customer
·V&V planning forces teams to think about how they will prove requirements are met before the design is frozen
·The V-model of development, widely used in high-tech engineering, is built on the V&V distinction

What hiring managers look for

·Confusing verification and validation is a classic junior engineer mistake — knowing the difference signals maturity
·The ability to write a DVP&R (Design Verification Plan and Report) or system test plan shows practical V&V skill
·Engineers who understand that validation requires actual customers or customer representatives, not just internal sign-off, are rare and valued
·V&V experience in regulated industries (IEC 62304, FDA 21 CFR, DO-178C) is a significant differentiator

Typical interview questions

What is the difference between verification and validation? Give a concrete example of each.

At what stage in the V-model do you plan your verification activities, and why is early planning important?

A requirement says "the system shall operate between -20°C and +70°C". Describe a verification test for this requirement.

How do you validate that a product meets a user need when the user need is qualitative ("easy to use")?

What is the link between requirements traceability and verification planning?

Common mistakes

·Running verification against internal specifications that do not accurately reflect user needs — passing verification but failing validation
·Writing test plans after the design is complete — V&V planning should begin during requirements definition
·Treating simulation results as validation — simulation verifies the model, not the physical product
·Using the same team that built the product to validate it — independent validation is required in regulated industries and improves objectivity in all contexts
·Closing verification before all requirements have been traced to at least one test — un-tested requirements are unverified requirements

Real engineering example

A sensor manufacturer verified their temperature sensor against their internal calibration specification and passed all tests. When the product reached the customer, it failed to meet accuracy requirements in the customer's system because the customer's thermal environment caused self-heating effects not anticipated in the verification tests. A validation test in the customer's actual operating configuration would have caught this. The distinction: they built the sensor right (verification passed) but did not build the right sensor for the application (validation failed).

Topics covered

verificationvalidationV&VV-modelDVP&Rsystems engineeringtesting

Related interview guides

Systems Engineer →Test Validation Engineer →Functional Safety Engineer →Mechatronics Engineer →Embedded Software Engineer →