Extreme testing occurs when we deliberately “torture” both the hardware and software to see what happens under undesirable conditions. Some examples of extreme testing include:

• Random voltages within the allowable voltage boundaries
• Voltage slews
• Deliberately introduced random noise on the data bus
• Extremely high bus loading (over 80% and sometimes over 90%) to see how the embedded software handles message dropping
• Cold and heat because variation in temperature can affect component performance, especially with LCD displays
• Rapid switching of hardware switches
• Slow voltage decay across the voltage boundary (which will sometimes cause a microprocessor “latch up,” wherein the micro ceases to function).

      Extreme testing is another discipline where the test suite greatly benefits from the active imagination of the test engineer. This is where we tap into the creativity that can never be automated. Our list is only a subset of the possibilities. We have applied these types of tests for both hardware and software testing, especially in the embedded environment. In one clear case, we applied extreme cold to some instrumentation and discovered the LCD display did not meet the customer’s requirements. Since this event occurred fairly early in the product development life cycle, we were able to recover by adding a display heater. Yes, we think it unlikely a usable truck cab will be used at -40^o C., but we had a requirement to meet and the test clearly indicated a product weakness.  In another instance, we used a hand drill that produced sparks when turned on and off, right on top of the product to see if the product was immune to EMC transients.

            We have had software managers complain that our tests have been so extreme that the defect would never be seen in the field. That is not the point. The point is that somewhere in that software we have a weakness, and the sooner we eliminate the weakness, the better our code. It doesn’t really matter with software how realistic our test scenario is—it matters that we have found another failure mode, which is analogous to the approach we take with the highly-accelerated life testing (HALT) we use with pure hardware testing.