Electronics testing – Happy versus Unhappy testing

I wish I would have come across this terminology earlier when I was teaching electronics designing. It would have been so much easier to categorise the different electronics testing cases and meaning of each test for the students.

Terminology

Happy and Unhappy terms are widely used in software testing. They can be converted in use for electronics designing. You will find the true meaning of these terms in software side for example from: Why You Should Define Both Happy & Unhappy Paths (cucumber.io)  But I am introducing them in electronics design & testing perspective.  

Happy test case refers to the situation when the device is tested against its intended use. For example, you are testing that device is working perfectly with specified voltage range.

Unhappy test case is the experiment where the device is tested against non-functional or unspecified use case that might happen on the field. For example, with over or under voltage from supply. What will happen?

Figure 1. Example of happy, unhappy, predefined unhappy test paths

That comes to the topic of performance criteria: What is accepted behaviour of the device?

For EMC the book System Level ESD Co-Design | Wiley has introduced hard and soft failures. Hard failure refers to the case when something breaks down and you need to take the device to repairmen. Soft failure refers to the situation that recovers by rebooting, removing the cause of failure or some other simple user action. It is up to project management to decide if the test finding is a feature or failure. As an example, is the need for manual reboot of device acceptable or not?

Thinking of the unhappy test cases and performance criteria early in design process will help to create a robust device without need for re-designing. Close co-operation to sales and customers is needed to understand the hidden requirements and to define proper performance criteria’s.

Simulations as part of happy / unhappy electronics testing

Virtual computer-based simulations are one way to analyse the risks of unhappy cases. In design phase it is very common to run even critical unhappy case analysis without destroying prototypes. Simulations also visualize phenomenon that might be difficult to measure. For example, the SIPI simulations can be done to analyse fast digital signals that are hidden inside the board and cannot be measured. SI-analyses are critical to understand the signal interface quality and PI analyses are important to understand that there is enough power to all the component on the board i.e.  power distribution on the board. With 3D field simulations the high frequency fields can be visualized for antenna or EMC design work.

Figure 2. Virtual modelling with computer visualize the radio fields and you gain more than pass/fail information

Example of finding unhappy test case

Many years back, I had a home computer with external printer. If I switched off the computer and printer was powered, the speaker of PC was creating a noise. The printer interface signal was leaking a small power through the ESD protection diode to 5V power line of the PC. There was enough power to almost wake-up the processor, but not enough to really wake it up. That was causing the noise when the processor was in wake-up oscillation (power-up…not enough power…power-up…not enough power…power-up…etc.). I tested similar case in my active product design on that time and I found out accessory combination creating the similar situation. I.e., I created an unhappy test case “what happens if device is off and accessory X is powered up”. With that test I avoid field failures and customer returns. Fix for my design was to improve the reset circuit to prevent start-up oscillation.

Pre-defined unhappy cases

If you think about the electronics regulations (EMC, RED, etc.), they are actually a pre-defined & standardized unhappy test case. It is good to remember that there might be additional unhappy cases that are defined nowhere and it is up to designers and project team to figure them out. You cannot figure out all of them, but think as many as you can and consult your peers and product management for other aspects.

Example of antenna’s unhappy case

In antenna designing we have seen plenty of cases where the antenna is designed for the free space use. But when the device is used in wrist or assembled next to the metal causing poor performance. That is the reason I usually start asking: “what is the use case and use environment” to figure out possible unhappy cases we need to be prepared on the design round. A simple unhappy test for mobile phones was to put them on top of metallic kitchen sink. Will it affect to phone behavior?

It was a simple unhappy case to identify internal noise coupling experiment. It could happen that antenna energy is reflected from the metal and coupling to the rest of the electronics causing an unwanted behavior of the device. The noise could couple also from rest of the electronics to the antenna. It will affect for the radio performance. That is tested with TIS (Total Isotropic Sensitivity) and BER (Bit Error Rate) analysis, where the receiving quality is monitored from the active device.

Figure 3. Example of manual experiments to identify interoperability unhappy cases you have not thought of earlier.

Interoperability

These internal noise coupling issues I call Interoperability, referring to the device capability to function with itself with all the features on. The interoperability challenges could be something else than TX power related also. There have been effects of SMPS regulators disturbing audio signals, etc. As you can figure out the software could have an effect to the interoperability issues, because it is controlling all the device activities. Software decides which electronics blocks are active at the same time. In that sense the software and hardware unhappy cases are overlapping and they need to be planned together.

Over the years I have seen several cases where software has created a risk of hard failure. As on example there was a design where software was controlling totem pole set-up of transistors individually. In that implementation it was possible that software is connecting both transistors active at the same time causing a short circuit situation. That was fixed by adding electronics circuit preventing that happening. The unhappy test case for electronics was “what if software control activates both transistors at the same time by accident”

Why use Experts?

It is worth of the money to use experienced designers on design houses because they have plenty of silence knowledge and experience of unhappy electronics test cases that are not written down in any standards or requirements.

Special thanks to @Heli Kurkinen to introduction of the Happy and Unhappy software testing to me.