As Test Engineers, we’re often in our own cocoon, focused on the long list of tasks to complete each day. What if we could get the best insight and advice from Product Engineers and use it to make our tasks easier?
Previously, I started a LinkedIn discussion, asking for the best advice a Product Engineer could give to a Test Engineer. It turned into a lively debate with excellent contributions from experts and non-experts in the field. Today, I will share the most insightful advice with you.
Design and planning (Pre-production)
1. Get involved
Join the design discussion as early as you can. Organise a meeting between the test and product team, or even a chat over coffee. If you’re caught for time, a group email or online chat will help share information
2. Be willing to work with the PE to influence design
As a Test Engineer, you’re likely to pick up on characteristics, trends and anomalies that the design and production teams won’t. This is where a YMS tool or system comes in, to track data and share it with the team. It’s easier to prove your point when you have charts and graphs to back it up. By sharing your expertise, you can influence the design at the start. This increases the chances of smooth production flow, and even reduced test time.
During testing (Post-production)
- Make sure to use the latest DFM, DFT testability techniques
- Use the recommended additional die area allowed for testability
- Look at the most difficult tests and move them to on-chip diagnostics if possible
- Simplify testing, don’t complicate it
- Simplify the load board & design it well to reduce sources of variation in production
- Make documentation easy to find. Save it online so you and your colleagues can access it easily. This includes detailed info about failure modes to help FAB later if needed
- Be cooperative with PE later on, if they need more information or a hands-on approach
- Verify that the data generated is clear and correct. It should be readily available from a database
- When possible, data-logging should be standard STDF
- Use Unique Test Numbers (preferably hardcoded) instead of relying on automated numbering
- Use Distinct Test Names based on some standard
- ID critical tests
- Standardized scaling
- Sensible binning
- Datalog should reflect the exact test conditions for each test
- Log the first failing vector cycle when a functional test fails
- Consider using techniques in wafer sort for eliminating defective chips
- Spend time characterizing and planning the design at the start. Store the data for review at a later stage
- The wafer probe testing should clearly define functional from parametric fails & sequence the tests with this in mind
In conclusion, most of the advice from leading Product to Test Engineers boils to communication, planning and data. Communicate with the design and product teams at the start. Assist in the planning and design phase. Provide data from testing and previous projects to prove your point. These will help each successive project to run even more smoothly.