What Testing Is Actually For
Not to prove software works — that is impossible — but to buy information about risk before your users find it. What a test is, what QA is, and why testing early costs less than testing late.
Not to prove software works — that is impossible — but to buy information about risk before your users find it. What a test is, what QA is, and why testing early costs less than testing late.
Every test passed. The pipeline was green, the release went out on Thursday afternoon, and by Friday morning support had ninety tickets from customers whose discount code did nothing at all.
Nobody had been careless. The tests that ran, ran correctly. They were simply not the tests that mattered, and writing more of the same kind would not have helped.
By the end of this lesson you will have a definition of testing you can actually work from, you will know what a passing test does and does not tell you, and you will know why one bug costs a two-minute conversation while an identical bug costs a weekend. No experience assumed, and no code in this lesson at all.
The obvious plan is to test everything. It is worth seeing exactly where that plan dies, because the answer shapes the whole job.
Take a login form. Two boxes and a button — about the smallest real feature there is. Now list what "everything" would mean: every email anyone might type, every password, on every browser, at every window size, with the network dropping halfway, on a phone keyboard that autocorrects, for an account that is brand new, or locked, or already signed in on another device, or was deleted last Tuesday.
That list has no end. Not "is very long" — has no end, because every item on it multiplies with every other one. Hiring three more testers does not help, and neither would three hundred.
So "make sure the software works" is not a goal you failed to reach. It is not a goal, in the way that "visit everywhere" is not a holiday plan. Something has to replace it.
Here is the one worth memorising:
Testing is buying information about risk, before your users find it for you.
Four words in that sentence are load-bearing.
Buying
Tests cost time to write, to run and to keep working. That makes testing an investment with a budget — which means choosing, which means some things will deliberately go untested.
Information
The output is knowledge, never a guarantee. "Checkout works for these twelve cases, including the three that broke last time" is honest, useful, and all anyone can offer.
Risk
Not correctness in the abstract. What could go wrong, how likely is it, and how badly would it hurt if it did?
Before they find it
All the value is in the timing. A bug you find is a task. A bug a customer finds is an incident, a support queue, a lost account — and still a task.
Notice what that definition asks of you. Not "try everything", which was never available. It asks you to work out where the risk is concentrated and look there first. That is a skill, it gets better with practice, and it is what most of this course is about.
Two words get used as if they mean the same thing, and they are not the same size.
Testing is examining a product to learn about its quality. It happens on something that already exists.
Quality assurance is everything a team does so that quality happens at all — including several things that occur before there is anything to test.
the cheapest place to catch a misunderstanding
a second pair of eyes before it exists as a bug
the shared definition nobody can quietly skip
this lesson's subject — and one band of many
the checks that never get tired or rushed
what real users hit that nobody predicted
A tester who improves how acceptance criteria are written prevents more defects than one who finds more bugs — and a prevented defect is strictly cheaper than a found one, for reasons the cost curve below makes concrete.
Software can pass one of these completely and fail the other completely, which is exactly why both have names.
Did we build the thing right?
Does it match the specification? Are the sums correct, the fields validated, the errors handled?
Answered by reading the requirement and checking the software against it.
Did we build the right thing?
Does it solve the problem the user actually had?
Answered by knowing who it is for — which no specification can tell you on its own.
Every requirement implemented, every test green, and the feature is one nobody wanted or one that falls apart in the situation it was built for. That is not someone else's failure to notice, and noticing it is squarely part of the job.
So when a specification lands on your desk, ask both questions. "Does the software do this?" and "would this actually help the person it is for?" The second is where the expensive mistakes hide, and asking it early costs nothing.
Here is the argument that decides how testing gets organised, and it is about money rather than principle. A defect gets more expensive the longer it survives — steeply.
The reason is not mysterious. A misunderstood requirement caught in conversation costs one changed sentence. The same misunderstanding found in production has already been designed around, built, tested, documented, possibly integrated with by another team — and it has produced bad data that now needs migrating. Every stage it passes through adds work that has to be redone.
Two things follow, and they are the practical core of this lesson.
Test early, and test things that are not code. Reviewing a requirement is testing. Asking "what should happen if this field is empty?" in a planning meeting is testing, and it is the cheapest testing that exists — it is at the far left of that chart.
When a bug does reach production, ask how it got through. Not to find someone to blame, but because the answer almost always points at a gap that will let the next one through as well. The gap is worth more than the bug.
"Shift left" is the industry phrase for moving testing earlier on that chart. It is worth translating into things you can actually do on a Tuesday:
None of that replaces testing the finished thing. It reduces how much is wrong by the time the finished thing reaches you.
Expecting any of these causes real friction on real teams.
Not a gate one person operates. A tester who is the last checkpoint before release becomes the person who says no. That is a slow and unpopular position, and it quietly lets everyone else treat quality as somebody else's department. Quality is a property of how a team works, not a stamp applied at the end.
Not a substitute for design. You cannot test defects out of badly structured software; you can only find them faster than they are created. If every change breaks three other things, that is an architecture problem wearing a testing costume.
Not a way to assign blame. A bug is information about a system, and the system includes the process that produced it. "Who wrote this?" is a much less useful question than "what would have caught this?"
You have a working definition and a reason to care about timing. The next lesson is the other half of the foundation: how software actually breaks. Failures come in recurring shapes — bad input, missing state, timing, the seams between systems, assumptions nobody wrote down — and knowing the shapes is what lets you guess where a bug is hiding instead of clicking at random.
Before that, one exercise that needs no tools. Think of the last piece of software that failed on you. Ask where on that cost chart the bug could have been caught, and what single question would have caught it. That habit is what this whole course is trying to build.
# The definition to work from
# Testing is buying information about risk, before users find it.
# buying -> it costs time; it has a budget; you choose
# information -> knowledge, never a guarantee
# risk -> what could go wrong x how bad it would be
# before -> all the value is in the timing
# Why exhaustive testing does not exist
# a login form's cases do not end; more testers does not help
# testing shows the presence of bugs, never their absence
# so: choose where to look. That choice is the skill.
# Testing vs QA
# testing examining a product to learn about its quality
# QA everything the team does so quality happens at all
# (requirements, reviews, done, pipeline, measurement)
# Verification vs validation
# verification did we build the thing right? (matches the spec)
# validation did we build the right thing? (solves the problem)
# software can pass one and fail the other
# The cost curve — why early beats thorough-but-late
# requirements a conversation ~1x
# coding minutes, by the author ~10x
# testing hours: report, triage, fix, re-test ~20x
# production an incident, plus bad data to fix ~100x
# Shift left, concretely
# ask the awkward questions while the feature is being defined
# write testable acceptance criteria before it is built
# review designs for testability
# automate the repeatable checks in the pipeline
# pair with developers instead of receiving finished work
# What testing is not
# not a gate one person operates
# not a substitute for good design
# not a way to assign blame
# and "bugs found" is a bad measure of it