Question of the Month: How important is test automation to engineers?

I guess it sometimes depends on what are the alternatives. Interns are cheap : )

The most boring weeks of my life as an intern in an R&D lab was just sitting (wearing shirt and tie - we were young but professional!) and turning a dial. The aim was to tune from near-zero all the way up to 30 MHz, slowly (it takes days to do that!) and just listen and write down all the frequencies where there were unexpected sounds. The point being that then the source of the sounds could be identified (it could be a transistor oscillating, or it could be a 16 MHz clock or by-product leaking through, and so on), and reduce as much as possible so they are no longer audible. Solutions could include putting a screening can around parts of circuitry, or rerouting interconnecting cables between boards etc. However, each time a significant change is made, then that knob needs turning from 0 to 30 MHz again : ) just in case any new sounds have appeared, or if old sounds have moved frequency.
Back then, I didn't think of automating, although much of the test equipment did have HPIB, the transceiver did have a remote serial interface so it didn't need someone to turn a knob, and there was an audio meter around with HPIB too, that I could have used. Today if I were doing it, I'd make use of Matlab to do the listening for me.

Another interesting scenario was switching relays on and off thousands of times, as a component selection process, to see which makes of relays could survive (they were going to be deployed in a scenario where they would be switched at high speed to perform antenna tuning.. fast enough that all you hear is a buzz while the circuit does its thing, finding the perfect combination of topology to match the antenna). I don't know if logging counts as automation, I don't know the detail but an engineer alongside me was logging for about a year (with different batteries and charger designs) to prove out his multi-battery charger circuit.

As design engineers, we could pretty much use any technique to automate that we wished, whereas the production engineers tended to use LabView a lot. Some test tools I built included DTMF generators and decoders and I2C master controllable via a PC (I think it was to program a frequency synthesizer, or to simulate button presses).

Later as a software engineer, it was of course a key part of the design process to automate (developer tests, regression, performance tests, run systems for hours on end, perhaps generate load, to check for memory leaks too, etc). Lots of fun : ) I quite liked writing test-case titles (bit more of a pain writing the actual test cases!).

Anyway, regarding the question, I think what you're really driving toward, is essentially asking whether equipment should have interfaces for automation or whether it's OK to just buy equipment without. Maybe I'm wrong, but I'm of the opinion that all test equipment should come with an interface for automation as standard, it doesn't have to cost much. No-one can predict what the equipment will be used for in future, and it gives it a longer life because it can be retasked: having an interface can turn something into a new product.

For instance, a multimeter can quite easily become an audio meter, if it is paired with a sig-gen and a bit of automation. Let the customer/engineer have the opportunity to turn that product into something they need, through the use of interfaces. Otherwise, the manufacturer is only guessing that their build-in display/buttons meets customer needs, locking out control of the bits of functionality within the device often, or forcing down one workflow that isn't fit for purpose. I don't know if that makes sense, maybe I have not explained it as best as I can (it's late : ) . Also, it sucks having test equipment with a poor user interface too.

I guess it sometimes depends on what are the alternatives. Interns are cheap : )

The most boring weeks of my life as an intern in an R&D lab was just sitting (wearing shirt and tie - we were young but professional!) and turning a dial. The aim was to tune from near-zero all the way up to 30 MHz, slowly (it takes days to do that!) and just listen and write down all the frequencies where there were unexpected sounds. The point being that then the source of the sounds could be identified (it could be a transistor oscillating, or it could be a 16 MHz clock or by-product leaking through, and so on), and reduce as much as possible so they are no longer audible. Solutions could include putting a screening can around parts of circuitry, or rerouting interconnecting cables between boards etc. However, each time a significant change is made, then that knob needs turning from 0 to 30 MHz again : ) just in case any new sounds have appeared, or if old sounds have moved frequency.
Back then, I didn't think of automating, although much of the test equipment did have HPIB, the transceiver did have a remote serial interface so it didn't need someone to turn a knob, and there was an audio meter around with HPIB too, that I could have used. Today if I were doing it, I'd make use of Matlab to do the listening for me.

Another interesting scenario was switching relays on and off thousands of times, as a component selection process, to see which makes of relays could survive (they were going to be deployed in a scenario where they would be switched at high speed to perform antenna tuning.. fast enough that all you hear is a buzz while the circuit does its thing, finding the perfect combination of topology to match the antenna). I don't know if logging counts as automation, I don't know the detail but an engineer alongside me was logging for about a year (with different batteries and charger designs) to prove out his multi-battery charger circuit.

As design engineers, we could pretty much use any technique to automate that we wished, whereas the production engineers tended to use LabView a lot. Some test tools I built included DTMF generators and decoders and I2C master controllable via a PC (I think it was to program a frequency synthesizer, or to simulate button presses).

Later as a software engineer, it was of course a key part of the design process to automate (developer tests, regression, performance tests, run systems for hours on end, perhaps generate load, to check for memory leaks too, etc). Lots of fun : ) I quite liked writing test-case titles (bit more of a pain writing the actual test cases!).

Anyway, regarding the question, I think what you're really driving toward, is essentially asking whether equipment should have interfaces for automation or whether it's OK to just buy equipment without. Maybe I'm wrong, but I'm of the opinion that all test equipment should come with an interface for automation as standard, it doesn't have to cost much. No-one can predict what the equipment will be used for in future, and it gives it a longer life because it can be retasked: having an interface can turn something into a new product.

For instance, a multimeter can quite easily become an audio meter, if it is paired with a sig-gen and a bit of automation. Let the customer/engineer have the opportunity to turn that product into something they need, through the use of interfaces. Otherwise, the manufacturer is only guessing that their build-in display/buttons meets customer needs, locking out control of the bits of functionality within the device often, or forcing down one workflow that isn't fit for purpose. I don't know if that makes sense, maybe I have not explained it as best as I can (it's late : ) . Also, it sucks having test equipment with a poor user interface too.