En bref : Que ce soit pour un réveil programmé sur votre smartphone ou une commande d’un repas via une application, tout passe par du code, et parfois ce code déraille ! Ce guide couvre : Ariane 5 (1996) – un bug à 370 millions de dollars, Le bug de la Y2K (l’an 2000), Knight Capital (2012) – 440 millions de pertes en 45 minutes, Windows 10 Update (2018) – suppression de fichiers utilisateurs.
Whether it's setting an alarm on your smartphone or ordering a meal through an app, everything relies on code—and sometimes that code goes haywire!
Software bugs may be minor, but some have cost billions, caused major crises, and even put lives at risk.
For testers, these failures are valuable lessons that should never be forgotten.
In this article, we explore some of the most notable software failures in history and the lessons to be learned from them.
1. Ariane 5 (1996) – a $370 million glitch
On June 4, 1996, in Kourou, French Guiana, the Ariane 5 rocket was launched for the very first time.
37 seconds after takeoff, it veered off course, broke apart in mid-air, and exploded, resulting in the loss of more than $370 million worth of equipment— all caused by a software error.
The guidance software used a portion of code that had been reused from the previous version, Ariane 4, and the flight conditions for Ariane 5 were radically different.
While converting a floating-point number to an integer, an unhandled exception occurred, causing the navigation system to lose control.
Furthermore, the error occurred in a software module that was no longer even needed after takeoff but remained active.
This bug could have been detected during realistic simulations or a thorough code audit. It was actually a known vulnerability, but one that had been deemed unlikely to occur.
The lesson for testers:
Never assume that legacy code is reliable simply because it worked before. Every time you reuse code, you must consider it within the context of the new system.
Testing is not just about validating current functionality, but also about evaluating the relevance and robustness of legacy code, especially in mission-critical environments.
2. The Y2K (Year 2000) Bug
In the late 1990s, a seemingly simple problem took on global proportions: date handling in computer systems.
For decades, to save memory, developers often represented years using only two digits (e.g., "99" for 1999).
Many feared that computers would interpret the year 2000 as 1900, leading to massive errors in date calculations, banking systems, or navigation software, for example.
Contrary to the widespread panic, January 1, 2000, was not a day of widespread chaos.
There were no large-scale power outages, no grounded planes, and no collapse of the banking system. However, that does not mean the bug was overestimated, nor that it had no consequences.
Hundreds of billions of dollars have been invested in prevention, primarily by governments, banks, hospitals, and insurance companies. A global campaign to update and test computer systems was carried out over several years.
However, a few bugs have still been identified:
- Credit cards issued with an expiration date ending in “00” were declined.
- Nuclear monitoring equipment in Japan briefly malfunctioned.
- Vending machines and ticketing systems misread the dates.
- Some software programs displayed the year “19100” due to improperly handled conversions.
Nothing catastrophic, but enough to show that the risk was very real.
The lesson for testers:
It is crucial to test time-related edge cases and to avoid making implicit assumptions in the code (“we’ll never reach the year 2000”).
It also shows that preventive testing—even if it is costly and invisible to the end user—can be crucial in averting massive crises.
3. Heathrow Terminal 5 (2008) – Logistical Chaos Caused by Software
On March 27, 2008, London Heathrow Airport opened its new Terminal 5, which was expected to revolutionize the passenger experience.
From the very first day, tens of thousands of pieces of luggage were lost, flights were canceled or delayed, and British Airways’ reputation was severely tarnished— all because of a new automated baggage-handling system that had not been sufficiently tested under real-world conditions.
The errors stemmed from a combination of software issues, a lack of coordination between the various systems (baggage elevators, conveyor belts, scanners, etc.), and inadequate staff training.
More than 42,000 pieces of lost luggage in just a few days, with losses estimated at tens of millions of euros.
The lesson for testers:
A system may work perfectly in a test environment but fail in production.
Tests must therefore include complex, multi-system scenarios and take human behavior into account.
4. Knight Capital (2012) – $440 million in losses in 45 minutes
On August 1, 2012, Knight Capital, a U.S. company specializing in high-frequency trading, deployed new trading software on the financial markets.
Less than an hour later, the company lost more than $440 million.
An old test feature, which was supposed to be disabled, was still active on some servers.
The software automatically sent massive, incoherent buy and sell orders for hundreds of stocks. The system was unable to detect the anomaly because no rollback or real-time monitoring mechanisms had been implemented.
The company is trying to limit the damage, but the harm has already been done. The bug caused unusual volatility in the market, literally ruined Knight Capital, and the company was acquired a few months later.
All of this was due to a deployment error and the lack of post-release validation tests. No tests had been conducted under real-world conditions on all the servers, and the errors were not reported in time.
The lesson for testers:
Tests must include the deployment phase itself, not just the features. It is essential to verify that all environments are consistent, that legacy features are disabled, and that monitoring tools are active.
A configuration error can sometimes have just as much of an impact as a functional bug, and even the slightest discrepancy can trigger a disastrous domino effect.
5. Windows 10 Update (2018) – Deletion of User Files
In October 2018, Microsoft released a Windows 10 update designed to improve the system's stability.
A few days after the rollout, thousands of users reported a particularly serious bug. The update deleted personal files in the “Documents” folder without warning and with no way to recover them.
However, this bug had been reported by testers several weeks before the official launch. Of course, the feedback was not taken into account in time, and no corrective measures were taken.
The problem stemmed from a conflict between the folder redirection tool (Known Folder Redirection) and duplicate file handling—a known issue that was not properly addressed during testing.
Microsoft will temporarily suspend the update and release a fix, but the damage has already been done, and user confidence has taken a hit!
The lesson for testers:
It is not enough to test only “normal” cases. Specific cases, custom configurations, and user feedback must be an integral part of the testing cycle.
A good QA process must also be able to listen and respond quickly.
What should today's testers keep in mind?
1. Testing doesn't stop at "works as expected"
A piece of software may very well do what it's supposed to do, but it might not do it well in a real-world context. The tester's role is also to imagine what could go wrong.
2. Testing means anticipating the unlikely
Just because a case is unlikely doesn't mean it doesn't warrant testing. The potential impact should guide testing priorities just as much as frequency.
3. Communication is a weapon against bugs
Most major bugs result from a lack of communication between teams, between developers and testers, or between the company and its users.
4. Automation tools are no substitute for human intuition
Tools such as Mr Suricate enable powerful, no-code automation of test scenarios. However, the tester’s curiosity—and their ability to ask the right questions—remains irreplaceable.
5. Document to avoid repeating mistakes
Every bug that is discovered is a learning opportunity. Documenting the causes, impacts, and solutions helps raise the overall quality standards within the company.
Testing also means learning from failures
At Mr Suricate, we see every day just how much no-code test automation enables development teams to anticipate, detect, and fix errors more quickly.
As Benjamin Franklin once said, “A penny saved is a penny earned.” Following this logic, QA testing is an essential component of a company’s return on investment.
👉 Read the article – ROI and Test Automation: What Savings and Revenue Are Generated?
If you'd like to calculate your own ROI and measure the impact of automation on your projects, we offer a free estimate.