Why Do We Test Software?

4 min read

Software is built by people, and people make mistakes. A misplaced minus sign in a banking script can swap deposits for withdrawals. A forgotten edge case in a checkout flow can let users buy a $1,000 phone for $1. A race condition in a hospital pager can delay a dose by minutes. Testing exists because the gap between "the code we wrote" and "the behaviour the user experiences" is wider than it looks.

Software bugs are expensive in real money

Every few years, a study tries to put a number on the cost of poor-quality software. The Consortium for Information & Software Quality estimated the cost in the United States alone at over $2.4 trillion in 2022. That figure includes failed projects, abandoned features, downtime, support tickets, lost customers, and the long tail of patches that ship after release. Testing is not free, but it is one of the cheapest insurance policies engineering teams can buy.

Some of these failures are famous: the Therac-25 radiation machine that gave patients fatal doses because of an integer overflow, the Knight Capital trading bug that lost $440 million in 45 minutes, the Boeing 737 MAX MCAS software that contributed to two crashes. Most are quieter — a typo in a SQL migration that drops a column nobody noticed was important, an off-by-one error that mis-charges shipping by 1¢ per order, a feature flag that defaults to "on" in the wrong region.

Where testing fits in development

In a healthy team, testing is not a phase that happens at the end. It runs alongside every other activity: requirements get reviewed for testability, designs get challenged with edge cases, code is checked by automated suites on every commit, and exploratory sessions probe for the things automation cannot reach.

The practice of pulling testing earlier in the development cycle has its own name — shift-left. It means defects are found while they are still cheap, ideas are still fluid, and the cost of changing direction is low. By contrast, a bug found in production is dragged through customer support, triage, fix, regression, and re-deploy before it goes away. The same defect can cost a hundred times more to handle once a real user has hit it.

Testing is a quality conversation, not a gate

Modern QA engineers do far more than click buttons. They write automated checks that run on every pull request, design exploratory charters that uncover risk, advocate for accessible and inclusive experiences, mentor developers on how to write good test cases, and partner with product to define what "done" actually means. Testing is less a final stamp and more an ongoing conversation about quality that touches every role on the team.

What you will learn in this course

This course gives you the vocabulary and the mental models you need to start a career in software testing — no coding required. You will learn how to think about risk, how to design test cases that catch the bugs that matter, how to write a bug report a developer will actually act on, and how to navigate the rituals and tools modern testing teams rely on. By the end, you will be able to walk into your first day as a QA engineer and contribute meaningfully on day one.

The next lesson digs into the single biggest economic argument for testing: the cost of a bug, and how that cost grows the longer it lives.

// tip to track lessons you complete and pick up where you left off across devices.