Test strategy: think in risk
You will never have time to test everything. Strategy is deciding what to test first, what to test lightly, and what to consciously skip — by risk.
7 steps · 5 minThe uncomfortable truth
Complete testing is impossible — the input combinations of any real app outnumber the atoms you have time for. Everyone skips things; strong testers just *choose* what to skip instead of letting the clock choose for them.
Risk = how likely something is to break × how much it hurts if it does.
Two hours before release. Where do your first 30 minutes go?
Where bugs cluster
Bugs aren't spread evenly. They cluster in what's new or just changed, in complex logic (pricing, permissions, sync), at integrations with other systems, and in whatever's been buggy before — defect history repeats. Your testing should be exactly as uneven as the risk.
This sprint: the checkout was rewritten, the FAQ got new text, and a date-picker got restyled. The rewritten checkout is also covered by automation. Test what first?
Say what you skipped
Risk-based testing has a price: things go untested, on purpose. The professional move is to make that visible — 'tested checkout and auth deeply; admin reports untouched.' Now the release decision includes the gaps, and the team chose them together.
Silent gaps become your fault. Stated gaps are a team decision.
Time's up, and the admin reporting section is untested. What do you tell the release meeting?
Strategy in one breath
Find where the risk lives — new, complex, money, history. Spend your deepest testing there. Automate what you'll repeat. Explore what you can't predict. And say out loud what you skipped. That's test strategy; everything else is technique.
Lesson complete.
That's the whole intermediate toolkit: API skills, an automation strategy, a trustworthy suite, a fast pipeline — and now the judgment to aim all of it at what matters most.