Recurrent TPS development issues or ascertaining the excellence of an automated unit test

Abstract

Although Test Program Set (TPS) development is a science; it can be construed as an ART if a precise software environment and exacting test program development practices are utilized. Also, the ability to build an effective and precise software development environment for TPS development is not an off-the-wall bunch of guesswork routines. This can only be accomplished by true test engineers who work in the test and diagnosis environment and understand the various requirements to develop a group of measurements that cover all of the aspects of a TPS. An advocate of true test technology, who wants a complete and comprehensive fault coverage of a Unit Under Test (UUT), will not be satisfied with mundane TPSs that are not capable of scoping out UUT failures is a precise, timely and factual manner. To scope out UUT problems requires practicing many factors which focus on TPS quality, robust software tools, powerful test hardware and the inclusion of state-of-the-art hardware with interactive diagnostics. Major TPS weaknesses continue to be diagnostics, manual probing, real life trends, time to repair, cross-referencing, weak test equipment, test time, etc. About 70% of the TPS development effort can go to diagnostics. Accurately estimated enhanced diagnostics can result in a substantial life-cycle cost savings. In fact, during TPS development and TPS support, fault localization should be the first step and always the most critical step. Ideally, there should be no more than 3–4 probes to (no probing is best) and fault isolate to 2 or less components with very high accuracy. UUT accessibility and thru-put complicate the TPS design and the UUT repairer. Complicated state transition sequences and edge changes can be a setback when trying to control the UUT circuits. We should always focus on what's really happening at some internal circuit element. The time to repair can be hindered by Fan Out, No-Fault-Found (NFF), Intermittents, UUT Source and sink circuits, noise with the Automatic Test equipment (ATE) or in the Interface Test Adapter (ITA), component weakness, miss-matched replacement parts, poor connections (solder / pins), component variations, etc. All elements are critical and time to repair can go into days and even weeks. There are clues to TPS weaknesses that dictate re-examination and reconsideration. These clues can include things like glitches, limits, % detect, test time, impedance, instrument selection, signal routing, ITA design, diagnostic issues, excessive code or software routines, ambiguity groups, signal degradation from various sources, signal amplification, signal reduction, lack of test requirements or data, improper grounding, noise, etc. TPS weaknesses need attention and improvement when they are observed. Support costs tend to compound when weaknesses are not corrected ASAP. This paper will cover many aspects associated with a TPS that fulfills the customer's needs and expectations and this includes the ATE and a focus on diagnostic issues.