Test escapee

Posted: Tue Dec 20, 2025 8:54 am Post subject: Test escapee

Is there such thing as test escapee? Can a unit really escaped from being tested?

Guest

The term 'test escapee' usually refers to a reject whose failure mode can not be detected by the existing test program. So it's really more of a test program inadequacy issue than the unit pulling off a Houdini act on the tester. Wink

Guest

Yes, test escapee usually refers to (1) test program inadequacy and (2) mistest or misprocessing such as mixing of reject with the good (human/operator error).

Bakit nga ba nag-stuck yung term na "test escapee" dito sa mga event na ito when in fact it is not?

Joined: 31 Aug 2026 Posts: 16

Test escapee refers to a scenario wherein a "valid" reject on a certain parameter, passed the test of that parameter. Examples for these are:

1. Consider a test that measures the DUT's(device under test) output at a certain resistance load condition. Usually, test programmers uses a relay to connect/disconnect the load to/from the DUT's ouput. Now if a valid reject(with load) part is tested, and assuming that the relay got stuck, meaning that the load was not connected to the output when the output was measured, there's a big chance that this part will passed this test, since it has no load. Resulting to a test escapee scenario.

2. Another example is ineffective(inadequate) guardband generation. Consider a valid reject part but marginal. If this part will be tested at production(tighter limits), there's a chance that this part will fall within the PD limits, if the guardband is inadequate, hence, passing the test, resulting to a test escapee. This the reason why guardband generation is a very critical process. An effective guardband will ensure that:
a. a valid reject will not fall within the production limits, and therefore will screen out(fail) this part.
b. good parts passing the PD limits, will also passed QC limits during QA sampling.

"Test escapee" are sometime mis-interpreted as "test coverage", or vice versa. Note that "test coverage" refers to a valid failure mode of the part, but this failure mode is NOT tested by the existing test program. Hence, this failing part will passed the test program and will be considered good.
_________________
Asmoth72

Posted: Wed Dec 28, 2025 10:54 am Post subject:

This falls on test program inadequacy. The unit underwent test, hence not a "test escapee".

Joined: 31 Aug 2026 Posts: 16

Hi Guest,

I think we(our company) have a different definition on the same term("test escapee").

In our company, we defined test escapee as a case of a valid failing parts passing the ATE test. The part got tested(but passed) on that particular failure mode.

My personal interpretation of test program inadequacy is that it doesn't have sufficient test to cover all the failure modes of the part, eventhough it covers all the datasheet specs, hence the term inadequacy(inadequate, insufficient, not enough). This means the part was NOT tested on that particular failure mode. In my own experience, there are failure modes that were raised by our customers. They experience these failure modes in their applications, which we did not encountered at our end. Hence, we develop a "screen" test to filter out these type of failing parts during ATE test. In our company, this case falls as "test coverage" issue. Meaning, the failure mode was not filtered out by the existing test program since it was NOT tested.
_________________
Asmoth72

Guest

I actually don't use the term test escapee, as I believe there is no such thing. Units can't escape from being tested.

Joined: 31 Aug 2026 Posts: 16

I agree, units can't escape from being tested(unless we have a mixing issue), but there are cases that a valid failing part on a certain parameter can pass the test on that parameter for some reasons(ie. as describe in my two previous examples).
_________________
Asmoth72

Guest

That part was tested hence not a test escapee. Here is a known reject device but you tested or binned it good, does the part hide its failure. NO!

Scenario:
Problem - customer complaint ...
Root cause - test escapee
Corrective - revise/add/modify/enhance/etc. test program

It seems that the root cause and the corrective action are not interconnected. How can you arrive to a good corrective action when you define the root cause incorrectly or poorly.

Joined: 31 Aug 2026 Posts: 16

Pan-gulo,

It appears that you're a bit confuse on the "customer complaint" example I've discussed. Please note that this example was presented for the "test coverage" category(or "test program inadequacy" to some companies), and not "test escapee" as you've mentioned.

I think the scenario would look more clearly as shown below:

Scenario:
Problem - customer complaint on a certain failure mode, that is not catch by the existing program, since this failure mode is not tested by the current test program. This failure mode was encountered by the customer, but not on our side.
Root cause - test coverage, test inadequacy(or whatever more preferrable)
Corrective - revise/add/modify/enhance/etc. test program

I think with this presentation, the root cause and the Corrective action is now interconnected.

As mentioned previously, different semicon companies have different definition on the term "test escapee".
_________________
Asmoth72

Joined: 31 Aug 2026 Posts: 16

For this query,

Joined: 22 Mar 2026 Posts: 1