What Software Testing Actually Is (and Isn't)

Most teams treat testing as a checkbox: run the suite, watch it go green, ship. That framing quietly does a lot of damage, because it hides what testing is actually for and leads teams to optimise for the wrong thing — a high number, a green dashboard — instead of for confidence. This series builds testing up from first principles, and this first part sets the definitions everything else depends on.

A working definition

Testing is the process of gathering information about how a system behaves, so someone can make a better decision about it. That's it.

A test doesn't prove your software is correct. It produces evidence — a data point about how the system behaved under a specific set of conditions. "This test passed" means: the behaviour I thought to check, under the inputs and state I set up, matched what I expected this one time.

That distinction sounds pedantic until it bites you. "All the tests pass" does not mean "the software works." It means the behaviours someone thought to check, under the conditions they set up, matched expectations. Everything nobody checked — the input no one considered, the state that only happens in production, the interaction between two features tested separately — is still completely unknown. A suite of a thousand green tests can sit on top of a broken product.

So the useful question about a test isn't "did it pass?" but "what did it tell us, and what does it still leave uncertain?"

Verification vs. validation

Two words that sound nearly identical and mean different things:

Verification asks: did we build the thing right? Does the code do what the spec says it should?
Validation asks: did we build the right thing? Does the spec describe what users actually need?

A feature can pass every unit test — fully verified — and still be the wrong feature, solving a problem nobody has, or the right feature built in a way that confuses everyone who uses it. Neither of those failures shows up as a red test.

Automated testing of every kind is strong at verification and mostly blind to validation. That's not a flaw to fix; it's a boundary to remember. Validation comes from talking to users, watching how the product actually gets used, and product judgement — not from the test suite. We'll come back to this limit throughout the course.

Testing vs. quality assurance

These get used interchangeably, and it's worth separating them:

Testing is an activity: you exercise the system, observe what it does, and compare that to what you expected.
Quality assurance is broader: it's everything a team does to prevent defects in the first place — design review, type systems, linting, clear requirements, good deployment hygiene, sensible architecture, code review standards.

Testing is one input to QA, not a synonym for it. A team that only tests — that finds bugs after they're written but does nothing to stop the same kinds of bugs being written again — is doing quality control, not quality assurance. The distinction matters because the highest-leverage improvements are usually upstream of testing entirely.

What "good testing" optimises for

If testing is about information per unit of effort, then good testing maximises that ratio.

A test that can only ever fail when someone deliberately breaks it — asserting a constant, checking a getter returns what it was set to — costs effort to write and maintain and tells you almost nothing.
A test that catches a whole class of regressions across many code paths — a well-chosen integration test, a check on a critical user journey — earns its keep many times over.

The rest of this course is about designing tests — automated, exploratory, and autonomous — that sit on the high-information end of that spectrum, and about arranging them so the whole set stays worth maintaining. Part 2 pins down the vocabulary the rest of the series relies on.