Hacker News Reader

Comment by andyferris | Hacker News Reader

I always thought a smoke test related to “where there is smoke there is fire”. Like “where there is an API response, there must be a functioning API server”.

Is that wrong? I am of course aware you can use smoke to track an air current, but is that the meaning of the phrase?

View on HN

> In Lessons Learned in Software Testing, Cem Kaner, James Bach, and Brett Pettichord provided the origin of the term: "The phrase smoke test comes from electronic hardware testing. You plug in a new board and turn on the power. If you see smoke coming from the board, turn off the power. You don't have to do any more testing."

Source: https://en.m.wikipedia.org/wiki/Smoke_testing_(software)

As my EE professor used to say, the problem is that once the magic smoke gets released, it’s super difficult to put back in.

Yeah, in EE there is a joke that the devices run on smoke. Once it's released it won't run anymore :)

I also always liked the joke about "every diode can be a light emitting diode at least once"

Or a space heater. That's when the smoke doesn't come out but the device still does not work and is hot.

From Wikipedia:

In Lessons Learned in Software Testing, Cem Kaner, James Bach, and Brett Pettichord provided the origin of the term: "The phrase smoke test comes from electronic hardware testing. You plug in a new board and turn on the power. If you see smoke coming from the board, turn off the power. You don't have to do any more testing."

https://en.wikipedia.org/wiki/Smoke_testing_(software)

The expression probably was first used in plumbing in referring to tests for the detection of cracks, leaks or breaks in closed systems of pipes.[1] Pre-dating the term itself, smoke tests were performed to detect leaks in wooden sailing vessels at least as early as 1836. After making a slow fire in the bottom of the hold, Richard Henry Dana writes, "Wherever smoke was seen coming out we calked and pasted and, so far as we could, make the ship smoke tight." - https://en.wikipedia.org/wiki/Smoke_testing_(mechanical)

( I used to moderate a s/w testing forum and one of the most common questions was "what is the difference between smoke and sanity testing" as this seemed to be used as an interview question...)

The way I've heard it used is thus:

In a complex system you are attempting to simplify (or deprecate components of), and where you cannot find an owner or stakeholder over some component system -- unplug the component and wait for errors or user complaints. Thus you will find out who is affected by the component and who likely stakeholders should be.

For example, old graybeards like myself will almost all have a story of finding some lost Sun or Irix server sitting under a pile of gear in an old closet, happily turned on with nobody current employed who knows anything about it.

What does it do? What's the user/password? How did it get there? all lost to the sands of time.

Turning it off will let you know if you can retire it or if somebody emerges with a problem then they can own it.

There are only certain classes of systems this works for. If the system generates infrequent alerts, for example, the stakeholder won't know there's an issue until they independently discover that they missed an alert. That said, I've resorted to this approach before, and it works.

And then you suddenly torpedoed security notifications for the whole company. Nobody noticed for a year that updates were not applied. The rest of the story writes itself.

At my company, we call this a scream test

And then you accidentally crashed the whole business, for months, also known as a career limiting move. The stuff The Daily WTF published for failed companies.

Which is why only independent contractors can safely pull it off, and even then not always.

The correct test is targeted error injection. Make the thing a bit flaky see who complains or notices. Fan favorite is explicitly laggy or busted routers in the path for networked hardware. It's still not without risks, crappy old glue or scripts tend to fail catastrophically. So as usual, backups and spares. Documentation before messing with the thing...

Generally also found that it is safer to send excess garbage downstream from the putative server than induce outages. Spam gets quick results. Assumes of course you know what it is supposed to send... Or that garbage sent from there will get noticed.

The last thing is an actual smoke test.

I thought it came from hardware, where an erroneous component placement would lead to releasing the magic smoke.

Smoke test is an ancient engineering phrase to describe the first time you turn something on after building/fixing it.

If it starts smoking, something is wrong.

It's been in the Jargon File since the late 80s and was popular in military/defense contracting prior to that.

You actually got me curious about this because it's a term I've been using for 40 years, and the earliest reference I've been able to find is in an internal memo about the development of a computer system, circa 1952:

> What all this adds up to is, that if Mike Stobin and Willis Ware who have been dealing with the ventilation engineers can come through with the ventilating equipment in time, it is very likely that we can have a smoke test of the arithmetic unit on the JOHNNIAC main frame in October [of 1952].

>The goal of the test will be to connect the A [accumulator register] and MQ for end-around shifting (7.5 order)15 and let the machine shift a set of digits all day while we hammer on the frame and wiggle wires. Applications for wire wigglers are now open.

https://www.rand.org/content/dam/rand/pubs/corporate_pubs/20...

Well shit I haven't used/heard the term "wire wiggler" in decades time to up my rizz with some outdated slang.

It is almost certainly a WWII slang term that spread to universities post-war.

Everyone use to smoke, it was something you didn't need equipment for.

If you have no idea behind which wall a pipe terminates or don't know which of 30 pipes runs to [say] the back room you blow some smoke into it (or a lot) One would mostly use it because it is really fast. Non smoking solutions take considerably longer. One might put a pull string in the tube, if you need to wire it anyway that wouldn't take much extra time but ideally you start pushing the spring into the tube on the side closest to the sharp corners. If there are many pipes on that side you would start pushing on the other and might get stuck. If the curves are really smooth the spring could drop out of the tube. You could need an extra set of hands (more expensive). With the smoke test you could push the spring in from the other end.

If there are wires in the tubes you can tie them together and use an ohm meter to find the right tube. You might have to walk up the stairs 10 times.

Non of it is much like software development.

A local exterminator does smoke tests for the integrity of the plumbing stack: pump smoke in the outside drain, and see whether it all goes out through the roof vents, or some escapes within a house. That's how they found where rats were getting into our basement--a plumber had removed a vent pipe and had not secured the end.

Tangential: at my first company out of uni we worked on software that ran in cars. I had never heard the term "smoke test" during my studies, and for quite a while I thought we were running tests (diagnostics) to check if the car was smoking.

I got so sick of having to explain what smoke tests were that I just don't use the term anymore.

In software, they tend to happen at deploy time, whether to an internal environment or production. I just call them "deploy tests" now.

Reply on news.ycombinator.com