From locomotives to agents: a short history of software testing

When Swiss railways finished a new bridge in the 1880s, they proved it the direct way: park locomotives on it and watch. If it held, the public could cross. The whole discipline of QA is in that picture. Prove it holds before the public arrives.

The word came first, too. Edison was complaining about the “bugs” in his inventions back in 1878. Software inherited the word, then made it literal.

On September 9, 1947, Harvard's Mark II started misbehaving. The operators traced the fault to Relay 70, Panel F: a dead moth between the contacts. They taped it into the logbook and wrote: “First actual case of bug being found.”

Grace Hopper told the story so well for forty years that it became hers, though the technicians on shift found the moth and wrote the line. It is testing in miniature: the system fails, somebody hunts down the physical truth, and the evidence gets kept.

In 1988, Gelperin and Hetzel mapped this history into eras in Communications of the ACM. The first barely counts as testing. Into the mid-1950s, you ran your code, it broke, you fixed it. Testing was debugging.

The real checking was human: rooms of computers at NACA and JPL verifying flight math by hand, because a missed digit could lose an aircraft. As early as 1949, Turing was asking the modern question: how do you check that a large routine is right?

In 1957 Charles Baker drew the line that created the field: debugging makes the program run, testing makes sure it is right. A year later Gerald Weinberg formed the first dedicated test team, supporting Project Mercury.

In 1968 NATO named the software crisis. Royce's 1970 paper made testing a formal phase of development. The first testing conference met at Chapel Hill in 1972, and its papers became the first testing book. The era's goal: demonstrate the software meets its requirements.

Demonstration had a flaw: if your goal is to show the software works, you write tests that pass. Glenford Myers flipped it in 1979 with The Art of Software Testing: testing is the process of executing a program with the intent of finding errors. Be adversarial, because your users will be.

The 1980s made testing an institution: an IEEE documentation standard in 1983, the first commercial PC test tool in 1985, QA departments with binders, matrices, and release checklists. Rooms of people checking math by hand had become rooms of testers clicking builds by hand.

1988 was a strange, great year. Gelperin and Hetzel argued for prevention: catch faults early, not just often. And in Wisconsin, storm noise on a dial-up line kept crashing Barton Miller's programs, so he made the accident a method: feed random garbage to Unix tools and count the crashes. Fuzz testing was born from a thunderstorm.

The 1990s industrialized it. Capture-and-replay tools like WinRunner replayed a tester's clicks on every build. In 1997, on a flight to a conference, Kent Beck and Erich Gamma wrote JUnit, and tests became something developers wrote as they coded.

In 2004 Jason Huggins, tired of maintaining browser tests at ThoughtWorks, built Selenium. The name is a joke: selenium treats mercury poisoning, and Mercury was the test-tool giant of the day. WebDriver merged in 2009, continuous integration ran the suites on every commit, and Cypress and Playwright refined the formula.

Everyone who has owned one of these suites knows the bargain. The scripts are literal. A renamed button and the build goes red for reasons that have nothing to do with bugs. The industry even named the tax: flaky.

Every era automated the previous era's grunt work. Human computers gave way to machines, test teams to tools, manual clicking to scripts. The job never changed: prove it holds before the public arrives.

Now AI writes the features and shipping is the easy part. Testing is the bottleneck: teams produce more change than any script suite or manual pass can keep up with, so you either slow down or let bugs through. And bugs through are the expensive option: one bad bug can sink a pilot, and a customer who churns over a broken flow is ten times harder to win back.

The scripts were literal, so the next step is agents that are not: software that explores an app like a real user and knows the product like its team. It catches what breaks before users see it, reproduces it with evidence, and writes the regression test itself. Myers' intent, Miller's randomness, the moth hunters' taped-down proof, running at the speed you ship.

That is what we are building at Nua: QA that keeps up, so shipping fast stops meaning breaking things. The full philosophy is a post of its own. The locomotives on the bridge, a century and a half later: load the thing the way real life will, and watch what holds.