Small QA teams fail in a predictable way: they try to test everything on every build, fall behind, and then start skipping things at random under deadline pressure. The fix isn't working harder — it's deciding in advance what runs when. Here's the model I use.
The smoke suite: "is this build worth testing?"
Smoke isn't a small regression suite. It answers exactly one question: is this build stable enough to spend time on? My rules for what gets in:
- The app launches and login works.
- The one or two flows the business dies without — checkout, booking, sending the thing the app exists to send.
- Any integration that has burned you before.
Hard limit: 10 minutes automated, 30 minutes manual. If your smoke suite is longer, it's a regression suite wearing a smoke suite's name, and people will start skipping it — which defeats the point.
The regression suite: organized by risk, not by feature list
For regression I keep a simple two-axis view of every feature: how likely is it to break (recently changed? complex? historically buggy?) and how bad is it if it breaks (revenue? data loss? embarrassment?). That gives you four quadrants:
- Likely + severe: automate first, run on every release candidate.
- Unlikely + severe: automate a happy path; deep-test when the area changes.
- Likely + minor: quick manual checks, good exploratory targets.
- Unlikely + minor: test when touched. Accept the risk and say so out loud.
The last point matters most. Untested areas should be a decision, written in the test plan — not a surprise discovered after an incident.
Tags are the whole system
In practice the strategy lives in test tags. Every automated flow carries smoke or regression; sprint-specific manual charters live in the test plan. CI runs --include-tags=smoke on every push and the full regression set on release branches. When someone asks "what's covered?", the tags are the answer — no stale spreadsheet.
Reporting: trends beat counts
"We ran 214 tests" tells stakeholders nothing. What I report instead: which risk areas are green, what's not covered and why that's acceptable, and defect trends — are bugs clustering in one module? Are severity-1s going up? That's the difference between QA as a checkbox and QA as the team's release-readiness signal.