Why Software Breaks

Every app on your phone has bugs. The banking one, the maps one, the one you'd swear has never let you down — all of them, right now, contain mistakes nobody has found yet. That's not a scandal, and it's not because programmers are careless. It's because software is one of the most complex things humans have ever built, and complexity guarantees mistakes. The real question was never whether software breaks. It's who finds out first — a tester, or a customer.

This page is about why that's true, how much a mistake costs depending on when it's caught, and why companies pay people — soon, you — to find problems on purpose. Everything else in this course stands on this foundation.

Written by Humans, Under Pressure

Software starts as text — code, instructions written by a person in a language a computer can follow. And it's written the way everything else at work gets written: by people with deadlines, interruptions, and incomplete information. A product manager describes a feature in a sentence; a developer understands it slightly differently; the design changes halfway through; a second developer edits the first one's work without knowing everything it was doing. None of these people did anything wrong. But every handoff between humans is a chance for the result to drift away from the intention.

Think of a manuscript on its way to becoming a book. The author knows what they meant, but typos still happen — and the more chapters, rewrites, and co-authors, the more of them there are. Nobody concludes the author is careless. Good publishers just assume typos exist and hire editors to catch them before printing. Software teams make exactly the same bet, and the editor role is called a tester.

Complexity Is the Enemy

Here's the part that surprises newcomers. Even a small app has more possible situations than any person could ever check — or even list. A simple booking form asks for a check-in date, a check-out date, and a number of guests. Each field can hold millions of values; the user can fill them in any order, on any device, with a slow connection or a lost one, logged in or not, clicking once or twice or halfway through a payment. Multiply those together and the number of distinct paths through even one screen outruns the number of seconds in your life.

Nobody holds all of that in their head — not the developer who wrote it, not the team lead who reviewed it. So mistakes don't hide in the parts everyone thought about. They hide in the combinations nobody thought to think about. That single fact shapes the whole profession you're entering: since checking everything is impossible, someone has to choose what to check — intelligently, deliberately, with technique. That choosing is called testing, and the techniques fill this book.

Famous Failures

A few real disasters show how small the mistake can be and how big the consequence. In 1996, the European Ariane 5 rocket exploded 37 seconds after its first launch — about half a billion dollars gone — because a piece of software tried to squeeze a large number into a storage slot too small to hold it. The code had worked fine on the previous rocket; the new rocket simply flew faster, and the number got bigger than anyone had re-checked.

In 1999, NASA lost the Mars Climate Orbiter — a $327 million spacecraft — because one team's software calculated force in pounds while another's expected metric units. Both programs worked exactly as written. They just disagreed about what the numbers meant, and nobody tested the two together against that assumption.

And it keeps happening. In July 2024, a faulty update from the security company CrowdStrike crashed roughly 8.5 million Windows computers around the world in a single morning — grounding flights, closing bank branches, and taking broadcasters off the air. One bad data file, shipped to everyone at once, and airports were handing out handwritten boarding passes. These stories aren't about incompetence. They're about ordinary, understandable mistakes meeting the speed and scale of software — with no one positioned to catch them first.

The Cost of a Defect Grows with Time

Now the idea that justifies the entire profession. A mistake — the industry says defect, and we'll use both words — gets more expensive to fix the longer it lives. Catch it while the team is still discussing the feature, and fixing it is a sentence in a meeting: "wait, should the discount really apply twice?" Catch it while the code is being written, and it's an hour of a developer's time. Catch it just before release, and it's a scramble — re-checking everything the fix might have disturbed. But let it reach production — the live version real customers use — and the same mistake is now refunds, apology emails, a support queue, an emergency fix, and sometimes a headline.

The same typo, remember, is free in a draft and very expensive once the book is printed, shipped, and sitting in stores. Software follows the same curve, only steeper — because software ships to everyone at once.

This curve is why testing isn't an act of distrust toward developers. It's insurance the whole team buys, and the earlier the coverage starts, the cheaper it is. You'll meet this idea again and again — it has its own principle in the next-but-one topic, and later a name the industry loves: shift-left.

Why Fernway Is Hiring You

One more story, and this one you'll live inside for the rest of the book. Fernway is a travel-booking service — a website and a mobile app where travelers find a place to stay, pick dates, and pay. Last month, Fernway refunded forty bookings in one weekend. A discount was applied twice at checkout: a promo code and a member discount stacked when they shouldn't have, and travelers paid less than the properties were owed. Nobody on the team was careless. The requirement was ambiguous, the two discounts were built by different people, and no one ever tested the combination. Customers found it first — the most expensive point on the curve.

That weekend is why Nadia, Fernway's engineering lead, opened a new position: the company's first dedicated QA engineer. That position is yours, and this book is your first year on the job, compressed. The next topic sorts out what the letters in your new title actually mean.