Design Validation Testing, often abbreviated as DVT, is an important part of productization. Put simply, DVT is what is done to prove that the product meets its requirements as manifested trough its specifications. This includes validating that the product meets functional and parametric requirements, including mechanical, hardware, software, environmental and regulatory. Many products also have industry and / or end user specific requirements.
Like many aspects of productization, there are a number of common misconceptions about DVT, which in general tend to over simplify and ignore the importance.
Misconception #1: Verification = Validation
Perhaps due in part to the unfortunate similarity of first letter and suffix, many engineers and managers tend to confuse the two concepts, which leads to the hey I already verified the design; I’m done issue. Verification is the act of looking at the design implementation and verifying step by step that the requirements will be met. In practice this is done ongoing as part of the design process and most verification is done before a product design is finalized. Verification includes testing engineering prototypes, typically as part of the design iteration process. Validation on the other hand starts when the design is complete (which means verification is also complete), the product is tooled and configured like it would be used by customers. Validation needs to be done at least semi-independently from design to avoid both an appearance of conflict of interest (see item # 4 below) but also to provide fresh eyes that can catch bugs long overlooked by those used to seeing them.
Misconception #2: DVT is just regulatory and environmental testing
Many engineers and organizations equate DVT with regulatory–FCC, CE mark, UL, etc– and environmental testing–temperature testing, vibration, drop test, etc. This is not surprising as these are indeed the two areas that tend to get subcontracted out–most companies do not have these skills in house. But validation in fact includes testing and validating all requirements. Often this means testing the product not only in nominal lab conditions but in simulated worst case real world conditions, which then overlaps back in with environmental. But worst case could also mean “the customer pushes two buttons at once” or other much more complex exceptions.
Misconception #3: DVT eats up to much schedule
This follows from the naive as soon as the design is done I should be in production mindset that in general is the bane of productization. The tactical situation here is that tooling is often a long pole in the schedule and companies have a habit of wanting to get into production as soon as parts come off the tool. Of course with closer scrutiny this misconception falls apart as at the very least the legal requirements inherent in regulatory testing tend to trip this one up. In practice it is in fact rare that DVT is the true long-pole if planned and executed properly. Clever productization professionals will craft a DVT plan that gets a head start pre tool finalization on parts of the design that are not impacted by mechanicals; conduct pre screens on all regulatory requirements prior to submission; and devise with management a risk vs reward schedule that allows for release to limited production at an intermediate milestone.
Misconception #4: The design team can do their own DVT, contracting out regulatory and environmental as needed
While in some organizations the design team do in fact have the detailed knowledge and skills needed to also do DVT, this is rare. Furthermore market forces have long since forced most third party regulatory and environmental labs to focus on bulk testing at the expense of advising on what to test. So often tests are needlessly repeated because the designers did not know exactly how to specify a test. Lastly, from a governance POV, since DVT is a “check” it is rarely wise to let the proverbial foxes guard the hen-house.
More to come–I’m working on a set of white papers on each aspect of productization, including DVT