6.1 Testing Strategy, Not Just Test Types
Testing is not mainly about memorizing labels like unit, integration, system, and acceptance testing. A real testing strategy answers a more engineering-shaped question:
How can this system hurt users, the business, or the team, and what evidence should appear early enough to prevent that harm?
Start From Risk
A payment feature and an avatar preview can both have unit tests, integration tests, and end-to-end tests, but their risks are very different. Payment worries about duplicate charges, amount-unit mismatches, timeout consistency, and audit evidence. Avatar preview may care more about compatibility, upload failure messages, and user experience.
Start by listing risks:
- Could a business rule calculate the wrong result?
- Could two modules misunderstand an interface?
- Could a critical user path break?
- Could data be lost, leaked, or unrecoverable?
- Could a change break old behavior?
Test Levels Are A Toolbox
Unit tests give the fastest feedback and fit pure logic, boundaries, and error branches. Integration tests check contracts between modules, databases, queues, and third-party APIs. System tests check whether important paths work together. Acceptance and exploratory testing check whether the system fits real human work.
A mature strategy does not say, "higher-level tests are more realistic, so make everything end-to-end." Higher-level tests are closer to real use, but they are usually slower, more brittle, and harder to diagnose. Lower-level tests are faster, but they cannot prove that a whole workflow works.
A healthy mix often looks like a pyramid: many fast low-level checks, a useful layer of contract and integration tests, a small number of critical end-to-end paths, and focused exploration for experience and unknown risk.
Regression Tests Are Team Memory
A regression test does not prove the code is perfect. It prevents the team from stepping on the same fault twice. When a production defect is fixed, leave behind a test that would catch it again. The bug becomes system memory, not just a patch.
A testing strategy should make clear:
- Which risks are covered by automation?
- Which risks need review, rehearsal, human acceptance, or exploration?
- Which tests run on every commit?
- Which tests run before merge, nightly, or before release?
- How quickly can the team diagnose a failure?
The value of testing is not the count. It is making important bad news earlier, cheaper, and more precise.