Test Coverage webcast generates interesting responses
The polling questions posed during ASSET’s webcast, “How to maximize test coverage,” generated the following responses. Arden Bjerkeli explains the significance of the answers and comments on some of the surprises.
Question: Do you use a fault model? If so, which one?
Responses:
| PCOLA/SOQ |
20.2% |
| MPS |
0% |
| PPVS |
2% |
| Other |
15.2% |
| None |
62.6% |
Arden Bjerkeli:
The large number of respondents who said they have not deployed a fault model tool (62 percent) really doesn’t surprise me, but the number who said they are using the PCOLA/SOQ fault model (20 percent) is a pleasant surprise that I wasn’t expecting. (For a discussion of the PCOLA/SOQ fault model in a recent Connect article, “Fitting in by Standing Out: A Closer Look at Assembly Test”, click here.) It appears that most test engineers and test managers are not trying, for whatever reason, to roll all of their test coverage information into one comprehensive analysis. That may mean that they believe they are getting a good enough intuitive feel for their test coverage by looking at the separate test coverage reports they can get from the various systems they’re using, like in-circuit test, boundary-scan, automated optical inspection and others. But it may also mean that they don’t know about the existing fault models, or that they have given up on any one fault model becoming a standard.
Back seven or eight years ago, when I was managing test programs at Compaq Computer Corporation, we didn’t know how to get one comprehensive test coverage number. We didn’t have fault models like PCOLA/SOQ or any other for that matter. We struggled with this question and we never could come up with a number that told us we were getting a certain percentage coverage of all possible manufacturing defects. The response to this question tells me the situation has improved somewhat but not by a whole lot. It may be that users and tool vendors need to work together to alert the standards bodies, like IEEE and others, to the need for one industry standard fault model. I certainly would like to hear from users if they agree.
Click here to send an email to Arden on this topic.
Question: Do you use a tool to help determine your test strategies?
Responses:
| Teradyne’s D2B Strategist |
3.8% |
| Agilent’s Coverage Analyst/AwareTest |
13.2% |
| Aster’s Testway |
3.8% |
| Other |
24.5% |
| None |
54.7% |
Arden Bjerkeli:
We see from the responses to this question that most test managers don’t use any test strategy tool. This may indicate that they believe that the tools are not effective, that they believe the tools are biased toward a specific vendor, or that they are just not aware of the tools.
The fact that 24.5 percent of the responses were “Other” either indicates that we needed more choices in the list we provided or that many of the tools in use are home-grown.
Perhaps another issue that this response points up is the need for an industry-standard fault model around which test strategy tools and other sorts of tools can be developed. So, maybe if we had a standard fault model or even a de facto fault model, we might see test strategy tools implemented more widely.
I would love to hear more from you, our users, about how you determine test strategies and what features and factors would lead to better acceptance of test strategy tools.
Click here if you’d like to send Arden an email on this topic.
Question: Does your test strategy ever exclude functional test because structural test is considered adequate?
Responses:
Arden Bjerkeli:
I was somewhat surprised by the number of respondents who indicated that they sometimes did not include functional test in their test strategy. My uninformed opinion was that most test engineers and test managers would be risk-adverse when it comes to eliminating any test strategy that might be able to find more faults. The 25 percent who said they sometimes excluded functional test means one of two things to me. First, these engineers have a high degree of confidence that they are getting enough test coverage with structural test methods. Or two, the high cost of developing functional test is making them willing to take on what may be added risk by dropping functional test. Overall though, I think the response to this question indicates that the test industry is gaining more and more confidence in structural test technologies, which includes boundary scan, ICT, AOI and AXI.
It might be interesting to hear how the readers of Connect would answer the converse of this question. That is, do you ever choose to exclude structural test from your test strategy because you feel that functional test provides adequate coverage?
Click here if you’d like to send Arden an email on this topic.
Question: Does your test strategy planning include meetings between inspection and test engineers to discuss coverage holes and overlaps?
Responses:
Arden Bjerkeli:
The 50/50 response to this question indicates to me an encouraging trend, but I still wish the percentage was higher in favor of joint test strategy development involving both inspection and test. It is encouraging though, because as recently as the mid 1990s when I was at Compaq Computer, we were just then starting to pull these two groups together so that we could begin to talk about achieving better test coverage. What we discovered then, and I suspect this may still be the case today in many companies, was that the two groups had a difficult time talking because they didn’t have a shared vocabulary to help them understand each other’s objectives. I am hopeful that the response to this question indicates that progress is being made along these lines. Unfortunately, I think the high percentage of companies that don’t have these two groups planning test coverage together indicates that they probably don’t have a fault model that’s accepted and used by the entire company. It might also indicate that there’s a need in the market for a tool that would help various groups develop a test strategy to meet all of their needs.
Click here if you’d like to comment on the issues raised in this response. |