Any program is a set of rules someone wrote, in a hurry and holding only a limited slice of the picture in their head. That's why programs make mistakes: a button doesn't click, money is charged twice, a form lets an empty name through. Testing is what catches such mistakes before a user sees them.
Put simply: testing is checking that a program does what's expected of it, and doesn't do what it shouldn't. A tester figures out in advance how the program will be used (both correctly and incorrectly), walks through those scenarios, and compares what happened with what was expected.
Why programs break
A mistake in a program is called a bug. Bugs appear not because developers are bad, but because software is complex. Typical causes:
- People make mistakes. Flipped a sign, forgot to check an empty field, didn't account for a user typing text instead of a number.
- Requirements were understood differently. The analyst meant one thing, the developer read another — and both are sure they're right.
- Everything changes. Fixed one thing — broke a neighbor. Added a new feature — broke an old one.
- The real world is unpredictable. Slow internet, an old phone, strange data, two actions at once.
The conclusion is simple: bugs are the norm, not the exception. The question isn't "are there any" but "will we find them before the user does".
Checking expected against actual
At the core of all testing is one comparison: expected result against actual.
Take a registration form, for example. Expected: entering an already-taken email shows a clear "this address already exists" error. The tester enters a taken address and looks at what actually happened. It matched the expectation — the check passes. It didn't (the form silently froze, or created a second user) — that's a bug.
The expected result doesn't come out of thin air — it comes from requirements: the task description, the mockup, common sense. So a tester must always understand "how it should be" — otherwise there's nothing to compare against.
The cost of a bug grows over time
The main argument for "why bother" is money. The same bug costs different amounts depending on when it was found:
- At the requirements stage — almost free: fix a line in a document.
- During development — cheap: the developer changes code that's still fresh in their head.
- Before release — more expensive: everything needs re-checking, the release is delayed.
- At the user's — expensive: unhappy customers, urgent nighttime fixes, damaged reputation, and sometimes direct losses (charged money, leaked data).
That's why teams try to start testing as early as possible. The earlier it's caught, the cheaper it is to fix.
Testing isn't debugging, and isn't "break everything"
Two common misunderstandings among beginners.
Testing ≠ debugging. The tester finds and describes the problem ("with these steps, instead of A you get B"). Debugging is when the developer looks for the cause in the code and fixes it. These are different roles and different work.
The tester doesn't "break" the program. They show that it's already broken under certain conditions. The bug existed before the tester too — nobody just noticed it. A good tester doesn't assert themselves at the developers' expense — they help the team ship a product they won't be ashamed of.
Another useful distinction: quality isn't "zero bugs". Perfect software doesn't exist. Quality is when the product solves the user's task and has no serious problems on the important scenarios. A minor bug in a rare setting can be lived with; a crash during payment cannot.
Where this applies
Checking "expected against actual" is what a tester does every day, on any task: from a new button to a complex payment scenario. Everything else in this program is about doing that check systematically: how to design scenarios (test cases), how not to forget anything (test design techniques), how to clearly describe what you found (a bug report).
Where beginners stumble:
- They check only the "happy path" — where everything is entered correctly. But most bugs live where the user makes mistakes: empty fields, extra spaces, too-long text.
- They don't know "how it should be", so they can't tell whether they're looking at a bug or not. Always check against the requirements.
- They see their job as "breaking" the product and argue with developers. The job is to ship a good product together.
What to learn next. Get to know who a tester is and what they do every day, how manual testing differs from automated, and how the software lifecycle works, to understand where your place in it is.