Famous Software Bugs That Prove Testing Matters

Liviu Lupei

Founder & Solutions Architect, Endtest · June 4, 2026

The scariest production bug I personally witnessed

Before looking at famous software bugs from history, I want to start with one production bug I actually witnessed.

In 2012, I was working as a manual software tester at an online retailer.

At some point, the company released a change that somehow caused all generated invoices to be printed with the price of 0.00.

The strange part was that the product prices were correct in the system. The total price of the order was correct in the system. The checkout flow was not obviously broken. The issue appeared only on the generated invoice.

That made it dangerous.

Most of those orders were going to be paid by cash or card when the package arrived at the customer's door. They were not paid in advance. And in many countries, invoice and pricing mistakes can create serious legal, accounting, and customer-service problems. Even when the company is not legally forced to honor the mistake, it still has to deal with angry customers, cancelled orders, manual corrections, and internal chaos.

Luckily, someone in the warehouse noticed the issue pretty quickly.

But it could have been much worse.

The company had automated tests, but those tests did not check the generated invoices. They checked the application, but not the document that the application produced.

That is an important lesson.

Sometimes the bug is not on the page.

Sometimes the bug is in the PDF, the invoice, the email, the exported CSV, the receipt, the contract, the report, or the file that gets sent to the customer.

That is why modern test automation needs to go beyond clicking buttons. With Endtest, for example, you can test generated PDF files, extract content from them, and validate that the invoice contains the right values. You can read more in the Endtest PDF testing documentation.

A test that only verifies that the invoice was downloaded is incomplete.

A better test verifies that the invoice is correct.

Why famous software bugs are worth studying

Famous software bugs are more than interesting stories.

They show what happens when software reaches the real world before enough people understand its risks.

Some bugs waste money. Some damage reputations. Some break companies. Some affect hospitals, airports, emergency services, financial markets, and space missions.

The lesson is not "write better code". That is too vague.

Software must be tested from multiple angles:

• Does it work under normal conditions?
• Does it work under unusual conditions?
• Does it fail safely?
• Does it behave correctly when data is missing?
• Does it behave correctly when systems are under load?
• Does it produce the right files, emails, reports, and documents?
• Does the team actually understand what is being released?
• Is there a way to detect the issue before customers do?

Automated testing matters because humans are not good at repeating the same checks forever.

Manual testing matters because humans are still better at noticing context, confusion, risk, and strange behavior.

The best teams use both.

1. The London Ambulance Service dispatch failure

One of the most famous software failures in testing literature is the London Ambulance Service computer-aided dispatch system from 1992.

The goal was reasonable: use software to dispatch ambulances faster and more efficiently.

But the system went live before it was ready.

The result was disastrous. Emergency calls were delayed, ambulances were misallocated, and the system failed under real operational pressure.

The London Ambulance case is often remembered as a software bug, but that description is too small. It was not one bad line of code but a failure of requirements, user involvement, testing, deployment planning, training, load handling, and fallback procedures.

That is what makes it so useful as a testing lesson.

A system can work in a controlled demo and still fail in production.

For an emergency dispatch system, testing should not only ask:

"Can the dispatcher create an ambulance request?"

It should also ask:

"What happens when thousands of real calls arrive?"

"What happens when data is incomplete?"

"What happens when operators make mistakes?"

"What happens when the network is slow?"

"What happens when the system has to recover?"

"What happens if the automated system is unavailable?"

For business applications, the stakes may not always involve life and death. But the pattern is similar.

A checkout flow may work with one test order, but fail during Black Friday.

A banking flow may work with a normal customer, but fail when two systems update the same account.

A SaaS onboarding flow may work in Chrome, but fail in Safari.

Testing needs to reflect reality beyond the happy path.

2. Therac-25 and the danger of unsafe software

Therac-25 was a radiation therapy machine involved in several serious accidents in the 1980s.

Patients received massive radiation overdoses. Some were seriously injured. Some died.

This is one of the most disturbing software failure stories because it involved a medical device that people trusted with their lives.

Again, the lesson is bigger than "there was a bug".

Safety-critical systems need defensive design, independent checks, reliable error handling, and strong testing of edge cases.

In a normal web application, a race condition might create a duplicate order.

In a medical device, a race condition can injure someone.

The same type of technical issue can have very different consequences depending on the system.

That is why testing strategy must match risk.

A landing page does not need the same testing process as a medical device. A button color change does not need the same testing process as a payment system. A product recommendation algorithm does not need the same testing process as an emergency service.

But every team should ask:

What is the worst realistic outcome if this software behaves incorrectly?

That question should guide the testing effort.

3. Ariane 5 Flight 501 and reused code

In 1996, the first Ariane 5 rocket exploded less than a minute after launch.

The failure was connected to software in the inertial reference system. A value conversion caused an overflow, and the guidance system lost critical information.

One of the painful details is that the problematic software logic had been reused from Ariane 4.

That is a classic software engineering trap.

Code that works in one context may fail in another.

Ariane 5 was not Ariane 4. It had different flight characteristics. A piece of logic that was acceptable for the older rocket became dangerous in the new environment.

This happens in business software all the time, just with less dramatic explosions.

A team reuses a checkout component for subscriptions.

A team copies invoice logic from one country to another.

A team reuses a discount calculation for a different pricing model.

A team migrates a Selenium or Playwright test from one application to another and assumes the same assumptions still hold.

Reusable code is useful, but reused assumptions are dangerous.

Testing should validate the new context as well as the old logic.

4. Mars Climate Orbiter and the unit mismatch

In 1999, NASA lost the Mars Climate Orbiter because of a unit mismatch.

One part of the system used English units. Another part expected metric units.

The result was that the spacecraft approached Mars incorrectly and was lost.

This is one of the most famous software-related failures because the mistake sounds almost absurdly simple.

But that is exactly why it is important.

Many severe bugs are not complicated.

A currency is wrong.

A time zone is wrong.

A tax percentage is wrong.

A unit is wrong.

A decimal separator is wrong.

A field is interpreted differently by two systems.

A date is parsed as MM/DD/YYYY instead of DD/MM/YYYY.

A backend returns cents, but the frontend displays the value as dollars.

A PDF invoice shows 0.00, even though the database has the correct price.

These are boring bugs until they reach production.

Automated tests are very good at catching this type of problem when teams define the expected values clearly.

For example, a good end-to-end test can create an order with known data, generate the invoice, download the PDF, extract the invoice total, and assert that it matches the expected amount.

That is exactly the type of last-mile validation that many teams skip.

5. Knight Capital and the cost of a bad deployment

In 2012, Knight Capital suffered one of the most expensive software failures in financial history.

A deployment problem caused its automated trading system to send millions of unintended orders into the market. The company lost more than $460 million in less than an hour.

This was not a slow-moving bug.

There was no comfortable debugging window.

There was no time to open a ticket, assign it to the sprint, and investigate next week.

The system was connected to the market, and the consequences were immediate.

This is a powerful lesson for any team that deploys software into production.

The faster your system can act, the faster your bugs can cause damage.

That applies to financial trading, but it also applies to:

• Automated billing
• Subscription renewals
• Email campaigns
• Payment processing
• Fraud detection
• Pricing engines
• Inventory updates
• AI agents that can take actions
• Scripts that modify customer data

When software can perform many actions quickly, testing must include guardrails.

Can the system detect abnormal behavior?

Can it stop itself?

Can a human stop it?

Are there limits?

Are there alerts?

Are deployments tested in the same conditions as production?

Automated testing checks that a feature works, and it also checks that dangerous mistakes are blocked before they become expensive.

6. Heartbleed and bugs that expose secrets

Heartbleed was a major vulnerability in OpenSSL that became public in 2014.

It allowed attackers to read memory from affected systems, potentially exposing private keys, passwords, and other sensitive data.

Heartbleed is a reminder that some bugs are invisible to normal users.

The website still loads.

The login page still works.

The dashboard still appears.

The customer may see nothing unusual.

But underneath, the system may be leaking sensitive information.

This is why security testing cannot be treated as a separate luxury. It must be part of the quality conversation.

Functional testing asks:

"Does the system do what it should?"

Security testing also asks:

"Can the system be tricked into doing what it should not?"

For modern teams, this means combining several types of checks:

• Automated regression tests
• API tests
• Dependency scanning
• Security reviews
• Penetration testing
• Input validation tests
• Authentication and authorization tests
• Monitoring and alerting

A complete testing strategy is a system of safeguards, not one tool.

7. The Pentium FDIV bug and trust in calculations

In 1994, Intel faced a major public controversy over the Pentium FDIV bug.

The issue affected floating-point division calculations in some Pentium processors. For most users, the probability of noticing it was low. But for scientists, engineers, mathematicians, and anyone relying on numerical accuracy, it mattered.

The bug became famous because it damaged trust.

That is another important testing lesson.

Sometimes the business impact of a bug is the loss of confidence, more than the direct technical failure.

If customers believe your system cannot calculate correctly, they stop trusting it.

If customers believe your reports are unreliable, they stop trusting your analytics.

If customers believe your invoices are wrong, they stop trusting your billing.

If customers believe your automated tests are flaky, your own team stops trusting your test results.

Trust is hard to earn and easy to lose.

That is why tests should focus on the areas where correctness matters most.

For an accounting product, that means calculations.

For an e-commerce product, that means prices, taxes, discounts, payments, stock, and invoices.

For a healthcare product, that means patient data, permissions, audit trails, and safety-critical workflows.

For a SaaS platform, that means sign-up, login, billing, user permissions, integrations, and core customer workflows.

8. CrowdStrike and the risk of automatic updates

In July 2024, a faulty CrowdStrike update caused widespread Windows crashes across many organizations.

The incident affected airlines, banks, hospitals, media companies, and many other businesses.

The details are technical, but the testing lesson is easy to understand:

When software updates are distributed automatically at massive scale, a bad update can become a global incident very quickly.

This is especially important for software that runs deep inside operating systems, browsers, networks, payment flows, or production infrastructure.

The more privileged the software is, the more careful the release process needs to be.

Teams should think about:

• Staged rollouts
• Canary releases
• Rollback mechanisms
• Strong validation before release
• Production-like testing
• Monitoring after release
• Emergency response plans
• Blast-radius reduction

Not every company distributes security software to millions of machines.

But many companies push changes to thousands of customers.

A broken JavaScript bundle can break a web app for every user.

A bad database migration can corrupt production data.

A broken feature flag can expose unfinished functionality.

A bad API change can break every integration.

The scale may be different, but the lesson is the same.

The release process is part of quality.

The common pattern behind famous software bugs

These bugs happened in different industries:

• E-commerce
• Emergency services
• Healthcare
• Space exploration
• Finance
• Security
• Hardware
• Infrastructure

But they share common patterns.

The bug was not tested in the right context.

The system behaved differently in production than in controlled conditions.

The team underestimated edge cases.

The failure involved more than one component.

The output looked correct in one place, but was wrong somewhere else.

Warnings existed, but were missed or ignored.

The rollback or fallback process was weak.

The people using the system were not involved enough.

The cost of the failure was much higher than the cost of better testing would have been.

This is why testing is more than a QA activity.

Testing is risk management.

Why automated testing matters

Manual testing is essential, but manual testing alone does not scale.

A human tester can carefully inspect a new feature.

A human tester can notice that a workflow feels confusing.

A human tester can explore strange behavior.

But a human tester should not have to manually verify the same login, checkout, invoice, email, and payment flows every day.

That is what automated testing is for.

Automated testing gives teams faster feedback. It helps developers know whether a change broke something, lets QA teams focus on deeper investigation instead of repetitive checks, gives managers more confidence to release, and catches boring but expensive bugs before customers find them.

The most useful automated tests are usually not the most clever ones.

They are the tests that cover the most important user journeys:

• Can a user sign up?
• Can a user log in?
• Can a user reset their password?
• Can a customer place an order?
• Can a customer pay?
• Is the invoice correct?
• Is the confirmation email correct?
• Does the flow work in Chrome, Firefox, Edge, and Safari?
• Does the flow still work after the latest deployment?

If these tests run automatically, the team gets a safety net.

Not a perfect safety net, but a useful one.

Why Endtest is built for real end-to-end testing

Many tools can click buttons.

That is not enough anymore.

Real applications involve emails, SMS messages, APIs, file downloads, PDF invoices, browser differences, user permissions, conditional flows, and data that must remain consistent across multiple systems.

That is why Endtest was built as a complete end-to-end testing platform.

With Endtest, teams can create automated tests without writing code, use AI to speed up test creation and maintenance, run tests across major browsers, validate emails, test SMS flows, call APIs, and check generated files such as PDFs.

This matters because many production bugs live outside the obvious UI.

The button works, but the invoice is wrong.

The form submits, but the email has the wrong link.

The payment succeeds, but the subscription status is not updated.

The report downloads, but the numbers are wrong.

The user can log in, but the wrong permissions are applied.

A strong automated test should follow the entire user journey instead of stopping at the first visible screen.

You can also explore the Endtest PDF and file testing product page or compare the available plans on the Endtest pricing page.

Testing should prevent boring disasters

Most production bugs are not cinematic. No rockets exploding, no spacecraft disappearing, no global outages.

Most bugs are more boring:

A customer cannot log in.

A discount is calculated incorrectly.

A PDF invoice shows the wrong total.

A form works in Chrome but fails in Safari.

A password reset email is not sent.

A payment succeeds, but the order remains pending.

A report exports incomplete data.

A user gets access to the wrong account.

These bugs are not famous, but they are the ones that damage companies every day.

They waste support time, create refunds, delay releases, make customers lose trust, and make teams afraid to deploy.

That is why automated testing is for any team that wants to release software without constantly wondering what broke, not only for large companies or safety-critical systems.

Final thoughts

Famous software bugs are useful because they make the cost of defects visible.

But you do not need to work on rockets, medical devices, trading systems, or emergency dispatch software to learn from them.

Every software team has critical flows, assumptions, and areas where a small mistake can create a large problem.

The best time to catch those mistakes is before production.

Start with the flows that matter most.

Automate the repetitive checks.

Keep manual testing for judgment, exploration, and product feel.

Test the full user journey, including emails, APIs, downloads, PDFs, and generated documents.

And remember the invoice bug from 2012.

The application looked correct.

The data in the system was correct.

But the document sent to the customer was wrong.

That is exactly the kind of bug that good end-to-end testing should catch.