Getting beyond test names: Help sustaining engineers debug more quickly

As we deal with many different semiconductor companies, questions surface regularly regarding test numbers and test naming. We’ve discussed test numbers before so will concentrate on test naming here. Included are some insights to help Korean and Chinese sustaining engineers who are not comfortable with the English language make sense quickly of what is going on with a test.

The advantage of good test naming is, of course, faster understanding of test issues later on, leading overall to more timely deliveries to customers. Mistakes can lead to quality issues and delayed understanding of what is really going on with a yield issue. In most cases though, the engineer will be careful and choose a name which is clear and distinguishes it from other similar tests. But there are challenges still.

Character Limitations

Some tester types limit the amount of characters allowed for the test name (8 characters in some cases). This makes distinguishing similar tests more difficult. The tester’s programming software can sometimes allow you to add “conditions” to a test. A condition might be “Vdd=5.0V”. This doesn’t mean that it’s attached to the test name, but at least if the sustaining engineer digs into the raw data, they will see the “condition”.

Additional Challenges

Just because the condition for a test is somewhere in the datalog, it still probably isn’t parsed by the test analysis software, so the raw data has to be downloaded and reviewed each time.

Most analysis software relies on test numbers rather than test names. So comparing the same test across multiple programs is made difficult even if the test names are the same from program to program but the test numbers differ.

Many sustaining engineers in your extended team will not have English as their native language. In that case, the naming may never be completely clear no matter how many characters are available. Also, test systems rarely allow Chinese or Korean keyboard characters to be used in test names.

How a Modern On-Line Data Analysis System Can Help

Your analysis software can really help if it can do the following:

Allow separately stored conditions to be automatically added to the test name for analysis (e.g. so they all appear together in a chart).

Example:
Original Test Name: “HFE”
Analysis Test Name: “HFE_VCE=10V_IC=1ma_TIME=380us”

Allow analysis based on test name instead of test number, so you can analyse a test across multiple programs easily, irrespective of the ordering of tests or the test numbers.

Allow test descriptions and debug information to be added to the analysis database by engineers in their own native language. So any time they analyse the test, they learn from the people most familiar with the test. This will lead to faster debug and faster time-to-market.

Example: Here’s a comment added in Korean to yieldHUB, explaining a test issue. So understanding is no longer constrained by the test name or by the English language.

So when a Korean engineer looks at the performance of this test, they will also see a description of the test and any useful debug information, all in their native Korean. This means no need to read English comments in test programs. The analysis database overcomes all such test program restrictions and limitations.

In Conclusion

Test Naming is important and if not done well can cause delays in production debug and ultimately customer delivery. A modern test data analysis system with the attributes listed above will help clarify the tests further, thus enhancing the collaboration between test development and test sustaining no matter where these teams are based.

The capability of adding far more information about a test, which can cover debug information and a clear description of the tester resources used and the specific conditions, all in the native tongue of the sustaining engineer, will bring that collaboration to a new level.