Putting It Together: A Working QA Process

Fourteen parts of principles. This one assembles them into something a team of 5 to 50 can operate without a dedicated QA department — a process that's written down just enough to be repeatable, and light enough that people actually follow it.

The layers, from the whole course

Every layer earns its place by catching a class of bug the others can't:

Static analysis — types, linters, dependency and secret scanning. On every commit, near-zero cost, catches whole categories of error before the code runs.
Unit + integration tests — engineers write them alongside the code, for logic and for the wiring between modules. On every commit and merge. Most of your test count lives here. See choosing your test distribution.
A small scripted end-to-end set — only the exact, deterministic assertions that must never drift ("an expired card is declined"). Kept deliberately short because it's the highest-maintenance layer.
Autonomous coverage — broad behavioural regression testing across the whole app, triggered after each deploy to staging (scheduled and deploy-triggered runs are on the roadmap). Carries the breadth without a suite to maintain. See where autonomous testing fits.
Exploratory sessions — time-boxed and chartered, aimed at new features and risky changes. Finds what nobody predicted. See exploratory testing.
Non-functional passes — performance budgets in CI, security scans, an accessibility review — each on its own cadence. See Part 13.

The workflow

Before building — a lightweight test plan in the ticket: scope (including what you're not testing), the top risk areas, the approach per area, and acceptance criteria written as checkable statements.
While building — engineers write unit and integration tests alongside the code; static checks run on every push. Acceptance criteria become the scenarios.
On merge to main — the full integration suite plus the small scripted end-to-end set. Keep this stage fast. See testing in CI.
After deploying to staging — trigger an autonomous run plus the plain-English checks for the critical journeys. Review the findings; each arrives with a reproduction. For risky changes, add a chartered exploratory session here.
Before release — confirm the exit criteria: no open high-severity defects, every critical journey passing, and a clean autonomous run against the release candidate with nothing broken in the areas this release changed.
After a bug escapes to production — fix it, add a test that would have caught it, and spend five minutes asking why the process missed it. Adjust the process, not just the code.

Who does what

Engineers own the static, unit, and integration layers, and write the tests as part of "done."
Whoever holds the QA function (a dedicated person, or a rotating role on a small team) owns the test plan, the exploratory sessions, the exact scripted assertions, and the review of autonomous findings.
The autonomous layer runs itself once configured; someone just has to look at the results.

What makes it sustainable

The high-maintenance layer (scripted E2E) stays small on purpose — it's a standing decision, revisited when it starts growing.
The broad layer (autonomous) has no suite to repair, so coverage doesn't decay between releases — the standing cost is reviewing each run's findings, not fixing tests.
Human time goes to planning, exploration, and judgement — not click-throughs and selector repair.
The written process is short enough to fit on one page, and it gets revised whenever it fails to catch something.

Measuring it

Two metrics tell you whether the process is working:

Escaped bugs — defects that reached production in an area you believed was covered. Trending down means your coverage is real, not hollow.
Maintenance time — hours spent fixing existing tests versus adding new coverage. Trending down (or staying low) means the suite's shape is right.

Coverage percentage is a weak proxy for either — see test coverage. Track journeys covered end to end and the two numbers above.

Where to start

Don't build all of this at once. Start with the critical journeys: list the five to ten flows you'd be unwilling to ship broken, get an autonomous run against staging for a baseline, turn the must-not-break ones into plain-English checks, and put it in CI. Then grow the process from where bugs actually escape — not from a maturity checklist.

The takeaway

A working QA process for a small team: static and unit checks on every commit, integration and a thin scripted E2E set on merge, autonomous coverage plus plain-English checks on deploy, exploratory sessions around risk, and non-functional passes on their own schedule — held together by a one-page test plan and clear done-criteria. Keep the maintained part small, let the broad part maintain itself, and revise the process every time it misses something.

That's the course. If you want to see the autonomous layer working on your own app, start a free run.