Interesting software testing terms and how they got their names

When you work in tech, you get used to hearing weird brand names,  acronyms, and strange terminology. After a while, you don’t even think about how silly you sound saying things like “Ok just ping me on YipYap after you run a report in ScreamGoat so we can sync on the SellBell numbers.” 

Sentences like that have been a part of my work for years now, but working in quality assurance has opened up a whole new set of interesting terms for me. Where do these names come from? I discovered a lot of them have an interesting origin story. 

Canary testing

Today, canary testing is a deployment practice that involves deploying new functionality to only a small subset of users (the canaries) to mitigate the risk of introducing new and potentially problematic changes to users. 

Back in the late 1800s, canary testing involved literal canaries — small birds in the finch family that are native to the Canary Islands, the Azores, and Madeira. Coal miners used canaries because they have a high sensitivity to carbon monoxide and other toxic gasses. Miners kept canaries in the mines so the birds could detect any sign of harmful toxins, giving the miners time to evacuate before they fell ill.  

Don’t worry, the canaries were not left in the mine! The birds were kept in special enclosures that could be sealed and release oxygen from a tank so the canaries could be revived. Of course, this is hardly an ideal life for a canary (or human) so this practice ceased around the 1980s.

Monkey testing

Monkey testing is a software testing technique that involves a tester applying random actions and inputs without any expectations or predefined test cases. The goal is to leverage the randomness to uncover bugs and vulnerabilities that could not be predicted. 

Unlike canary testing, monkey testing did not begin with actual monkeys (although there was one experiment that was later described as “performance art.”) The term “monkey testing” is derived from the infinite monkey theorem, which states:

“a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will almost surely type any given text, including the complete works of William Shakespeare. In fact, the monkey would almost surely type every possible finite text an infinite number of times.”

While the accuracy of this theorem is debatable, the idea behind it translates well to software testing. A literal monkey might not help you uncover errors and vulnerabilities in your software (the experiment-turned-performance showed that they’re more likely to smash your machine or urinate on it) but embracing the randomness of a monkey using a computer can be quite effective. 

Dogfooding

Dogfooding or “eating your own dog food” is the practice of using one’s own products or services. Dogfooding is not specific to QA and software development, but it is very prominently used in the software industry. 

There are a couple of claims about the origins of this term, but most agree that the term “dogfooding” was derived from Alpo dog food ads from the 1970s and 80s. Spokesperson and actor Lorne Greene appeared in several advertisements claiming that he fed Alpo dog food to his own dogs. 

A similar but less verifiable theory is that the president of Kal Kan Pet Food would eat a can of Kal Kan dog food at company meetings. For the sake of anyone who had to attend those meetings, hopefully this isn’t true. 

The origins of “dogfooding” in the software industry are debated as well, with stories from both Apple and Microsoft happening around the same time. 

In 1980, an internal memo from Apple hints at this practice without actually using the term “dogfooding.” At the time, Apple computers were fairly new and not widely used. The memo, sent by then-CEO Michael Scott, insisted that employees cease using typewriters and start using Apple computers:

Then in 1988, Paul Maritz of Microsoft sent an email with the subject line “Eating our own Dogfood,” that encouraged the internal team to increase usage of their product, Microsoft LAN manager. 

Chaos monkeys

To get to the origins of the term “chaos monkeys” (which are not related to monkey testing) we first have to talk about chaos engineering and testing. 

Chaos testing is a technique designed to assess a software system's resilience to unforeseen circumstances or failures. The idea is to move away from assuming zero failures and instead prepare for the inevitable by building fault-tolerance into the product.

Chaos testing is part of chaos engineering, which is a discipline that involves proactive injection of controlled and monitored chaos into a system. Basically, throw a lot at the system all at once to identify weaknesses and vulnerabilities before they cause a complete system failure. 

Chaos engineering and testing came about in 2008 when Netflix suffered a significant database outage and the developers decided to migrate the entire infrastructure to Amazon Web Services (AWS). As part of their efforts to verify the resiliency of the IT infrastructure, Netflix built the Chaos Monkey Tool. The program randomly chooses a server and disables it during normal hours of operation. 

Antonio Garcia Martinez explains the origin of the name in his book, “Chaos Monkeys.”

“In order to understand both the function and the name of the chaos monkey, imagine the following: a chimpanzee rampaging through a data center, one of the air-conditioned warehouses of blinking machines that power everything from Google to Facebook. He yanks cables here, smashes a box there, and generally tears up the place. The software chaos monkey does a virtual version of the same, shutting down random machines and processes at unexpected times. The challenge is to have your particular service — Facebook messaging, Google’s Gmail, your startup’s blog, whatever — survive the monkey’s depredations.”

So while chaos monkeys aren’t a part of monkey testing, the reasoning behind the names are similar. In the software world, monkeys seem to be considered the ultimate agents of chaos and randomness. 

Bugs 

In the software world, bugs refer to errors, flaws, or faults in systems that cause the systems to produce incorrect results or behave in unexpected ways. 

Similar to canary testing, the term “bug” has ties to its namesake — actual insects. Thomas Edison used the term “bug” in various letters while working on the Quadruplex telegraph system. Some stories suggest that he began using the term bug due to issues with cockroaches. One of the telegraph offices was infested with cockroaches and Edison rigged up a wire and battery trap to zap them. Edison eventually defined the term “bug” as “little faults and difficulties.”

Edison may have coined the term but in the tech world, credit for the first literal debugging often goes to a team of computer scientists at Harvard University. In 1947, the team discovered a moth trapped inside of a computer. 

The moth was found in a relay panel, disrupting the electronics of the computer and causing it to malfunction. The above photo shows the moth taped into a notebook, noting that it was the “first actual case of a bug being found.” 

Patch (hotfix)

In software development, patches, also known as hotfixes, are software updates that are quickly prepared and released to production to target a specific bug or vulnerability. 

Originally, patches were pieces of tape used to literally patch up holes on patchboards, which consisted of card stock that stored data through punched holes. When a hole was punched in the incorrect spot, engineers patched it with tape.

By the 1970s, punch cards were obsolete but the use of “patch” persisted. The MIT computer glossary from 1977 defined as patch as:

1. n. A temporary addition to a piece of code, usually as a quick-and-dirty remedy to an existing bug or misfeature. A patch may or may not work, and may or may not eventually be incorporated permanently into the program.

2. v. To insert a patch into a piece of code.

Patches made with physical tape may not exist anymore, but it seems the spirit of them does — the definition calls patches a “quick-and-dirty” remedy, something unplanned and maybe a little messy, like its original namesake, the tape patch. 

Software testing terms are sometimes more literal than you’d expect

While I love a fun origin story simply for the sake of the story, what I really appreciate about many of these software testing terms is that the explanation is partially within the name. Many technical terms are unnecessarily complex (or silly), but even if you’re coming from outside the QA world, you could probably guess that a “bug” is a bad thing (or a “little fault or difficulty" as Edison said) or a “patch” is a messy fix. 

I don’t think I could attribute such logic to the myriad of tool names in the tech world, but that’s a rant for me to bring to my followers on ConnectThis or my next FiggyPudding brainstorm session, I suppose.