Testing Fundamentals
What testing is actually for, the shape of a suite people trust, and how to write a bug report that gets fixed.
Testing Buys Information, Not Certainty
That framing settles most arguments about coverage. A suite is not better because it runs more assertions; it is better because a failure in it means something is genuinely broken, and a pass means the risky parts still work.
Two roles sit underneath the word QA. Verification asks whether the thing was built to spec. Validation asks whether the spec was worth building. A team that only does the first ships a product that matches a document and disappoints its users.
Types of Testing
The vocabulary is worth pinning down, because half of testing disagreements are two people using one word for different things.
| Type | Answers |
|---|---|
| Unit | Does this function behave, in isolation |
| Integration | Do these pieces agree at their boundary |
| End-to-end | Can a user complete the journey |
| Regression | Did fixing that break this |
| Smoke | Is this build worth testing further |
| Acceptance | Does this satisfy the person who asked for it |
Cutting the same space another way: functional testing asks whether it does the right thing, and non-functional testing asks whether it does it fast enough, safely enough and for enough people at once. The second kind is skipped far more often and causes the more expensive incidents.
The Testing Pyramid
The pyramid is a claim about cost and feedback speed, not about virtue. Tests near the bottom are fast, cheap and precise about what broke. Tests near the top are slow, expensive and the only ones that prove the product actually works.
| Layer | Share | Runs in | Tells you |
|---|---|---|---|
| Unit | Most | Milliseconds | Exactly which function is wrong |
| Integration | Some | Seconds | Which boundary disagrees |
| End-to-end | Few | Minutes | Something in this journey is broken |
The shape is guidance, not arithmetic. A thin service that is mostly glue between other systems genuinely needs more integration tests than units, because its own logic is small and its risk is at the seams.
Writing Test Cases
A test case is a claim about behaviour that someone else can check. It needs a precondition, an action, and an expected result specific enough to be wrong.
| Weak | Usable |
|---|---|
| "Check login works" | "Given a verified account, entering the correct password lands on the dashboard within 3s" |
| "Test the form" | "Submitting with an empty email shows the field error and does not call the API" |
| "Verify the list" | "With 0 results the empty state is shown, not a blank panel" |
Two techniques do most of the work of choosing inputs. Equivalence partitioning says values that should behave alike need one representative each, not fifty. Boundary value analysis says the bugs live at the edges — 0, 1, the maximum, one past the maximum, empty, and null.
Bug Reports That Get Fixed
A bug report is a request for someone else's time. The ones that get acted on quickly all contain the same six things.
| Field | Why it decides the outcome |
|---|---|
| Title | Read in a list of two hundred — state the symptom, not "broken" |
| Steps | Numbered, from a known starting state, reproducible by a stranger |
| Expected vs actual | Without both, it is an opinion |
| Environment | Build, browser, device, account — half of bugs are conditional |
| Evidence | Screenshot, video, logs, network trace, request id |
| Severity and frequency | Impact and how often — the two inputs to priority |
Separate severity from priority. Severity is how badly it behaves; priority is how soon it should be fixed. A crash in an unused admin screen can be severe and low priority; a typo on the pricing page is trivial and urgent.
Interview Questions
Can testing prove software is correct?
No. It can only demonstrate that particular behaviours held under particular conditions. The skill is picking the conditions that carry the most information for the time spent.
Verification versus validation?
Verification asks whether it was built to spec; validation asks whether the spec solves the user's problem. Teams that only verify ship things that match a document and miss the point.
Why is the pyramid shaped that way?
Cost and feedback speed. Unit tests are fast and say exactly what broke; end-to-end tests are slow and flaky but are the only ones that prove the journey works. Invert it and the suite gets ignored.
What is the ice cream cone anti-pattern?
A suite dominated by end-to-end tests. It takes tens of minutes, fails for environmental reasons, and reports a screen rather than a cause — so people stop trusting the results.
What are equivalence partitioning and boundary values?
Partitioning groups inputs that should behave identically so you test one from each. Boundary analysis then targets the edges of those groups — 0, 1, max, max+1, empty, null — where bugs actually cluster.
Severity or priority — what is the difference?
Severity is how bad the behaviour is; priority is how soon it gets fixed. A crash in an unused screen is severe and low priority; a pricing typo is trivial and urgent.