That day, my boss asked what DVT had tested, and I broke into a cold sweat
That afternoon, the production line suddenly stopped. Not a minor issue, but the entire line. My boss rushed over, face ashen, and directly asked me: "What exactly did we test in DVT for that batch of goods? How could something like this happen?" My heart sank, because regarding that batch's DVT report, I only remembered it 'passed,' but the details had long since vanished from my memory. My boss saw my blank expression and added: "If you don't even understand how to plan DVT, how can you be an engineer?" Damn, I wanted to find a hole to crawl into right there. This story tells us that planning for verification testing is truly not just about 'having tested,' but about 'testing to the point.'
Where's the problem? It's not 'testing,' it's 'random testing.'
Many times, when we conduct DVT (Design Verification Test), EVT (Engineering Verification Test), or even PVT (Production Verification Test), we merely pull out the items from the specification and run through them once. Once completed and passed, we feel everything is fine. But frankly, if that's all there is to it, product failures are inevitable. Why? Because you might not have considered real-world usage scenarios, or you simply haven't identified the critical reliability risk points. You are merely conducting 'testing,' not 'verification.' They differ by one character, but their meanings are vastly different.
Therefore, the key to planning verification tests is not how many items you've tested, but how many risk points you've correctly identified and tested.
How to actually do it? Find your "devil."
To plan for reliability verification testing, I recommend the following:
- First, inventory all 'potential' failure points: Product structure, materials, circuit design, software functions, and even packaging methods. List all of these, then ask yourself: "Under what circumstances might this area cause issues?" For example, for a newly designed power module, I would consider if it would fail in high-temperature, low-temperature, or high-humidity environments? Would there be drift during prolonged operation?
- Identify key Failure Modes: This is an extension of the first step. Imagine, if this product actually fails, how would it fail? Would it burn out? Disconnect? Malfunction? For example, if you're working on a mobile phone chip, failure modes might include frequency instability at high temperatures, or elevated power consumption after prolonged use.
- Define Test Conditions and Standards: This is the most crucial step. You cannot simply say "test until it breaks." You must set a clear standard. For instance, we once had a product that required continuous operation for 1000 hours in an 85°C high-temperature environment, with a Cpk of 1.33 or higher. If it only achieved a Cpk of 1.08, even if it didn't fail, it would indicate insufficient process capability stability. I would directly reject it and start over, rather than just checking 'if it failed.' Alternatively, we might specify that after vibration testing, the product's DPMO (Defects Per Million Opportunities) must not exceed 6210 ppm, which means a 6210 in a million chance of error. This reveals the product's robustness more effectively than a simple Pass/Fail.
In other words, you need to be like a detective, uncovering the "devils" within the product, and then designing a "trap" to catch them.
The most common pitfall: "Others tested it, so we should too."
I've truly seen too many engineers take competitors' product verification reports, or simply hear that a certain client particularly emphasizes a specific test, and then adopt it wholesale. What's the result? A lot of time and money spent testing a bunch of non-critical items, while failing to test the areas where problems genuinely occur.
Honestly, every product has its unique risks. Blindly following trends is less effective than spending time thoroughly analyzing your own product. Once, when we developed a new optical module, we ran tests based on the old product's test items. After shipment, customers complained that the lenses would fog up in high-humidity environments. Upon review, we discovered that the old product didn't have high-humidity applications, so no related tests were planned, but the new product did. This is a classic case of "others tested it, so we should too," while forgetting to consider the specific characteristics of our own product.
This pitfall, frankly, is laziness. Laziness to analyze, laziness to think.
One thing you can do today
Re-examine your most recent verification plan and ask yourself: "What is this test designed to prove?"