Why software testing matters
The real cost of bugs: why a defect gets roughly 10x more expensive at every later stage, four famous failures explained simply, and the idea of testing early ("shift left").
Picture a tiny crack in a windshield. On Monday it's a chip you could cover with a coin, and a quick repair costs almost nothing. Ignore it, and by Friday it has spread across the whole glass and you're replacing the windshield. The crack didn't change its nature. It just got more expensive to deal with the longer it sat there. Software bugs behave exactly the same way, and that single fact is most of the reason testing matters.
In the last lesson we learned what testing is. This lesson is about why anyone pays for it. The short answer: catching a problem early is cheap, and catching it late is brutally expensive. Sometimes it costs money. Sometimes it costs a company. In rare, awful cases, it costs lives.
Bugs get more expensive over time
Software is built in stages. First someone decides what to build (requirements). Then someone plans how it will work (design). Then it gets written (code). Then it gets checked (testing). Finally it goes live for real users (production). A long-observed pattern in our industry is that a defect costs roughly ten times more to fix at each stage it survives.
| Stage the bug is caught | Rough relative cost to fix | Why it's cheap or costly there |
|---|---|---|
| Requirements | 1x | It's just a sentence to reword. Erase and retype. |
| Design | ~10x | A plan has to be reworked before anyone built on it. |
| Code | ~100x | Real code must be found, changed, and re-checked. |
| Testing | ~1,000x | Now it ripples into other features and re-test cycles. |
| Production | ~10,000x | Live users are hit, support floods in, trust and revenue take damage. |
Requirements
cheapest
Design
~10x
Code
~100x
Testing
~1,000x
Production
most painful
Why the steep climb? Early on, a bug is just an idea on paper. You change a sentence and move on. By the time it's live, that same mistake is woven into real code, real data, and real user habits. You have to find it, fix it, prove the fix didn't break anything else, ship an update, and clean up after every user it already hurt. Same bug, wildly different bill.
Four times a bug made history
These stories get told in QA classes for a reason: each one is a clear, real lesson about what testing protects us from. The details are accurate, and the takeaways are simple.
Ariane 5, Flight 501 (1996): a number too big for its box
Europe's brand-new Ariane 5 rocket exploded about 37 seconds after launch on its very first flight. The cause was a piece of reused software that tried to cram a large number (a 64-bit value) into a smaller container (a 16-bit one). The number didn't fit, the conversion failed, the guidance system shut down, and the rocket tore itself apart. The kicker: that piece of code wasn't even needed after liftoff. It was left running from the older Ariane 4. A simple range check would have caught it.
Mars Climate Orbiter (1999): metric meets imperial
NASA lost a roughly $327 million Mars probe because two teams used different units of measurement. One team's software produced thrust values in imperial units (pound-force seconds) while the navigation software expected metric units (newton-seconds). Nobody converted between them. The orbiter drifted off course and was destroyed in the Martian atmosphere. No single line of code was "wrong" on its own. The two halves simply didn't agree, and no test caught the mismatch.
Knight Capital (2012): 45 minutes, $440 million
A trading firm deployed new software to its servers but missed one server during the rollout. That stray server ran old code that reacted to a reused flag in a way nobody intended, and it began firing off millions of unintended stock trades. In about 45 minutes the company lost around $440 million and nearly went under. The lesson is brutal and ordinary: a deployment that isn't applied consistently and verified everywhere is a loaded weapon.
Therac-25 (mid-1980s): when a bug can hurt a person
The Therac-25 was a radiation-therapy machine. Under a specific, fast sequence of operator inputs, a timing flaw (a race condition, where two parts of the program collided in the wrong order) caused it to deliver massive radiation overdoses. Several patients were seriously harmed and some died. It is the most sobering example in the field, and the reason safety-critical software is tested with extraordinary care.
Not one of these was caused by an evil genius or sabotage. Each was an ordinary, human-sized mistake that nobody tested for in the right way. That is exactly the kind of thing good testing exists to catch.
The big idea: shift left
If bugs get cheaper the earlier you catch them, then the smartest move is obvious: start testing as early as possible. The industry calls this shifting left. Imagine the project timeline drawn left to right, from first idea to live release. "Shifting left" means pulling testing activities toward the left (earlier) end, instead of saving all the checking for a panicked rush at the end.
In practice, shifting left means testers help review the requirements before a line of code is written, ask hard questions during design, and check small pieces continuously instead of waiting for one giant test phase at the end. It's the windshield chip again: deal with it Monday, not Friday.
A quick way to sound like you understand QA in an interview: "The earlier you catch a defect, the cheaper it is to fix, so we shift testing left and start checking from the requirements stage, not just at the end." Plain, true, and exactly what teams want to hear.
- A bug gets roughly 10x more expensive to fix at each later stage: requirements, design, code, testing, then production.
- Famous failures (Ariane 5's number overflow, the Mars Climate Orbiter's unit mismatch, Knight Capital's botched deployment, the Therac-25's race condition) were all ordinary human mistakes that the right test would have caught.
- "Shift left" means starting testing as early as possible, because early defects are cheap and late ones are ruinous.
- Testing matters because it converts expensive, public failures into cheap, private fixes.