What is Testing?
Let's start with the basics: what testing actually means, why it's bigger than "clicking around looking for bugs," and how it differs from debugging.
~6 min read
The core ideas, explained
Testing is more than just running the software
Testing includes both dynamic testing (executing the software and observing its behavior) and static testing (examining a work product - requirements, user stories, designs, or code - without executing it, typically through reviews or static analysis). It's tempting to equate "testing" with clicking through a finished app, but reviewing a requirements document before any code exists is testing too - and often the cheapest testing you'll ever do.
A requirements review that catches an ambiguous acceptance criterion before a single line of code is written is testing - even though nothing was ever "run."
Testing covers both verification and validation
Verification asks "are we building the product right?" - does the system meet its specified requirements and design. Validation asks "are we building the right product?" - does it meet the user's actual needs and intended use, in its real operating environment. Good testing addresses both; passing verification alone does not guarantee a useful product.
A checkout form might verify perfectly - it matches the written spec exactly - yet still fail validation if the spec itself never captured that users needed a guest-checkout option.
Testing has multiple objectives, not just "finding bugs"
Depending on the context and level, testing can aim to: evaluate work products such as requirements, user stories, and code; trigger failures and find the defects behind them; give stakeholders confidence and information about quality; prevent defects by catching problems early (e.g. in a review); reduce the risk of inadequate quality reaching users; and verify compliance with contractual, legal, or regulatory requirements.
A test team that spends a sprint reviewing requirements and asking clarifying questions is pursuing defect prevention - useful testing work, even though it produces zero test cases that week.
Testing and debugging are related but distinct activities
Testing's goal is to find failures (and, indirectly, the defects that cause them). Debugging's goal is to locate the root cause of a defect, fix it, and confirm the fix works. In most organizations, testers execute tests and report failures; developers debug the code and hand it back for confirmation testing - re-testing that verifies the fix actually resolved the reported issue.
A tester reports "adding an item to the cart throws a JavaScript error." A developer debugs the code, traces it to a null-reference bug, and fixes it. The tester then re-runs the same steps to confirm the failure is gone.
Key points to remember
- Testing includes static techniques (no code execution, e.g. reviews) as well as dynamic techniques (executing the software).
- Verification asks "did we build it right?"; validation asks "did we build the right thing?"
- Test objectives go beyond "finding bugs" - they include preventing defects, providing confidence, reducing risk, and ensuring compliance.
- Testing and debugging are complementary but different: testers find and report failures, developers debug and fix the underlying defects.
- Good testing can start long before any code exists - reviewing a requirement is a legitimate testing activity.
Terminology
A few terms from this topic worth knowing precisely.
Examining a work product - requirements, design, code, or testware - without executing it, typically through review or static analysis.
Testing that requires actually running the software and observing its behavior - the complement to static testing.
Checking that a product conforms to its specified requirements - "did we build it right?"
Checking that a product meets the user's actual needs in its real operating environment - "did we build the right thing?"
The underlying flaw or root cause present in a work product, such as a contradiction in a requirement or a bug in code.
The observable, incorrect behavior that appears when a defect is actually executed under the right conditions.
Locating the root cause of a known defect and fixing it - distinct from testing, which finds the failure in the first place.
Re-running a test that previously failed, using the exact same steps, to confirm that a specific reported defect has actually been fixed.
Summary
Testing is a broad discipline that starts before code exists (static testing), covers both building the product right (verification) and building the right product (validation), pursues objectives well beyond "finding bugs," and works hand-in-hand with - but is distinct from - debugging.
| Concept | One-line memory hook |
|---|---|
| Static vs. dynamic testing | Testing without running code still counts |
| Verification vs. validation | Built it right? vs. built the right thing? |
| Multiple test objectives | Not just "find bugs" - prevent, inform, ensure compliance |
| Testing vs. debugging | Testers find failures, developers fix root causes |
Check your understanding
10 quick questions - click an option to see if you got it right.