Mostly harmless, conspicuously useful
The Hitchhiker's Guide to Becoming a Quality Engineer
A quality engineer engineers the test strategy, automation, and feedback loops that stand between the team and the discovery of its mistakes by customers, which is a perfectly reasonable ambition until you recall that a test that passes proves only that the test passed, that the flaky test is a smoke alarm that has cried wolf until the wolf has moved in, and that the gate that blocks the release is the gate the team built to protect the release. You learn to translate "it should work" into test layers, data, pipelines, and quality gates that fail before production does, and to treat a green build as a hypothesis the next change will cross-examine. The grand objective is a release that fails in the pipeline rather than in production; the daily evidence is usually a test that catches a regression, a flake that is fixed rather than retried, and an automation that pays for itself by the third release it prevents from being the fourth. This guide travels from reading a test plan to governing quality strategy, with practical stops at test layers, performance, security, and the recurring discovery that the work you do twice is the work you should automate.
Level 1 · Novice
Admire the green test only after asking what it proved
You read test plans, test cases, and results without writing production tests, learning how a passing test can fail to prove anything about the system it claims to cover.
You begin with read-only artifacts: a test strategy document, a test plan, a set of unit and integration tests, a coverage report, and a build that is green. Test strategy is the selection of test layers and evidence appropriate to product risk; unit and integration testing is the practice of fast tests around components and their boundaries. A unit test exercises one module in isolation; an integration test exercises the seams between modules. Coverage reports which lines and branches the tests reached, which is a measurement of activity rather than of value, and a test that passes proves only that the test passed, not that the system works.
Suppose a team reports ninety-eight percent coverage and a green build. You read the tests and find that the most critical branch — the one that handles a payment failure — is covered by a test that asserts the function returns a value, any value, without asserting which value. The coverage is honest; the test is not. You record the observation, the missing assertion, and the risk. One brisk review is an anecdote with good posture, not a quality strategy; but it prevents the team from shipping a payment failure path that has been thoroughly exercised and not at all verified.
Words from the spaceship manual, translated
- Test strategy
- A document selecting which test layers — unit, integration, end-to-end, performance, security — apply to which risks, and why. It is the difference between testing everything a little and testing the right things enough.
- Unit test
- A fast test exercising one module in isolation, with dependencies replaced by stubs or mocks. It is the first to run, the first to fail, and the easiest to trust, until it asserts the wrong thing.
- Integration test
- A test exercising the seam between two or more modules, often with real dependencies or fakes. It catches what a unit test cannot: the disagreement between two modules that each believed they understood the contract.
- Coverage
- A measurement of which lines and branches the tests reached. It is a lower bound on activity, not an upper bound on confidence, and one hundred percent coverage of the wrong assertions is still zero percent verification.