Testing, Testing

I enjoy language. So here are a few more bits and phrases I've found useful -- these ones on the subject of testing.

Smoke Test: This is when you turn on the power and see if it smokes and catches fire. If you are really unsure if you configured things right (such as, perhaps you reversed the polarity on the power leads) the more refined trick is to turn it on for just a moment, turn it off before the magic smoke can leak out, then gingerly touch the most sensitive components with a bare finger to see if they are heating up.

A smoke test won't tell if you if the circuit works. But it will tell you if the circuit is broken. But please remember to always mount a scratch monkey!


Sanity Test: more commonly in the form of a sanity check (and I'm sorry to say, but there ain't no sanity clause), this is any sort of trivial throughput check or checksum or order of magnitude calculation; instead of the painstaking check of every line of code or engineering calculation, this is taking the simplest and most obvious check that will reveal that all your elegant math foundered when you multiplied instead of dividing in step 2.

This is why smart DIYers don't spare the blinkenlights. A few LEDs (or a few serial.print comments in a code) can tell you that what you intended certain parts of the circuit to do, they are actually doing.

In sound, a sanity test is done by ignoring all the nice microphones and nifty speaker processors and all of that, and just seeing if you can get a simple CD to play through the house speakers. If you can't, you shouldn't be wasting time setting up delay chains just yet!



Plugs-Out Test: I first ran into this phrase in regards to a terrible accident in space history. But let that not stop us from the idea of removing the umbilicals, and seeing if the device will still run on its own internal battery, without the connection to the ISP, and with the cover of the enclosure screwed down.



Proof-of-Concept: Not usually called a "test," this is similar often misunderstood by those who observe them. The proof-of-concept is done entirely to prove the plausibility of the idea -- it is in no way a test of the actual hardware. Indeed, you substitute, you breadboard, you mock up; whatever you have to do to get the thing to work, even for just a second or two before the tape falls apart.

Solderless breadboards, alligator clips, double-stick tape are your friends here. Simulated signals, simulated outputs. It doesn't matter what it looks like; it matters that it works, even if it only works once.



Coffee Test: This is the test of whether you are awake enough to write code or operate machinery; can you make coffee without doing something mind-bogglingly stupid? I grind the beans, brew hot water in a teapot, and pour it through a gold filter to the mug or flask for the day. This provides plenty of chances to prove I'm not awake yet. Today, I put on the water, cleaned the filter, and ground the beans. I finished just as the water began to boil so I quickly rinsed out the travel mug...then proceeded to carefully fill it with boiling water.

Other times, I've skipped the filter or the coffee entirely. The best day of all, though, was when I was still living in the Haight-Ashbury. I carefully filled a clean mug with milk, then proceeded to add coffee grounds to it. I remember watching the black flecks slowly sink in the full mug of milk and wondering what exactly was wrong with that picture.




 On a more serious note, there are a couple more test concepts that are worth adding.


Test-in-Place:  Especially with RF gear, funny things happen in the actual location where you mean to use the thing.  So it isn't properly tested until it is in the room it will be used in.  Better yet, it should be in rehearsal, or in as close to performance conditions as you can manage.


Acid Test:  This is when you create a worst-case scenario and see if the thing survives it.


Test to Destruction:  Unlike the above, this is when you intentionally fail the unit to find out just what it takes to break it.