A few articles ago, I wrote an article about my visit to the Trenton Computer Festival, and the copy of OpenSUSE that I picked up while I was there. I also mentioned the numerous vendors selling the Ardunio microcontroller boards and the buckets of drool I left after gazing longingly at them.
At this point you may be wondering what a "hardware" article is doing in a blog aimed primarily at the computer/software QA crowd.
Simple. While I was there, I also picked up a, (free!), copy of the magazine Nuts and Volts - a worthy successor to the venerable Popular Electronics I enjoyed in my (much) younger days. Buried deep on page 58 of the March 2012 volume is an article titled "It's All About The Uno32 Hardware". I gave it a quick glance and it got me thinking. . . . . You know, it often IS all about the hardware.
Obviously, if you're testing software applications for an embedded device the underlying hardware becomes critically important. And if you don't know the difference between a 2N2222 transistor and the latest i7 processor, you shouldn't be working there.
But - even in a purely software environment - a knowledge, even a basic one, about the underlying hardware can often be just as important.
A case in point:
My friend Andy works for a company that makes security / access control devices and the software that runs them. And yes, because the software and the specialized hardware it controls are inextricably intertwined, knowing something about which end of the screwdriver to use is obviously important.
However, there was one case where a recent release of their access control software would fail in mysterious and subtle ways - especially when certain controller functions were used. So, he wrote up the bug report and sent the software back to the dev team for the fix. Except that they could not reproduce it. HE could, every stinkin' time, but they could not. And yes, we in the Software QA community know all about how some obscure software module on the developers computer can mask software bugs.
They came and looked at it failing on his machine and left scratching their heads. Especially as this part of the software had been tested before - and passed - and as far as they knew no changes had been made anywhere near that particular part of the code. So they took it apart, line by line, even doing a clean install on another computer, and they could not reproduce it.
So, what was the problem? Andy later discovered that there was a failure, a very subtle failure to be sure but a failure nonetheless, in the computer's power supply that was apparently aggravated by certain particular sequences of software which apparently activated certain pieces of hardware on the motherboard, triggering the failure. Replacing the power supply "fixed" the software bug.
In my own software QA experiences, I have often triggered critical bugs just by monkeying around with the network connections and how they're wired to the various network devices they're connected to. I have also found "bugs" caused by an inadvertent wiring error in a pre-made network cable - such as a particular network pair being wired backwards at one end. I have also had the pleasure of leaving the office of a senior developer - or a manager - with their jaw hanging down after a simple piece of hardware "magic" solved a problem that had been perplexing them for days.
The bottom line? Even in a purely software environment, it can be "all about the hardware", and knowing enough about it to think outside the box can be vitally important.
What say ye?