Questions, terms & origins
Everything that didn't fit on the other pages: the questions teams ask before adopting, the vocabulary the model uses, and where it all came from.
Frequently asked questions
Isn’t a separate QA team a step backwards from "whole-team quality"?
No — feature teams keep full ownership of the quality of what they build each sprint: unit tests, code review, and in-sprint feature testing all continue unchanged.
Continuous QA adds ownership for a job that "whole-team quality" quietly leaves unassigned: continuously protecting everything that already shipped. Diffuse ownership of that job is exactly why regression suites rot.
How is this different from just hiring more QA engineers?
Headcount inside sprint teams gets absorbed by feature pressure — more people testing new features, still nobody guarding the existing product.
The difference is structural: a separately resourced team with its own backlog and cadence, whose work cannot be raided when a sprint runs hot.
We can’t afford a dedicated team. Can we still do this?
The canonical starting point is one existing QA engineer, repurposed — not hired. Scope them to your single most business-critical application and let weekly KPIs make the case for growth.
The original implementation ran under nonprofit cost constraints across 30+ applications, scaling with a blend of offshore capacity under experienced local leadership.
Why Gherkin specifically?
Because one artifact does three jobs: a human-executable test case, an automation-ready specification, and living documentation a product owner can read. Any structured, readable, automatable format achieves the goal — Gherkin is simply the widely supported default.
Does this slow releases down?
The automated Master Test Suite runs in CI/CD and adds minutes, not days. The manual pre-release pass runs in parallel with the release candidate hardening you already do.
What it actually removes is the slowest release step of all: the production incident.
Who should the regression team report to?
Anywhere that keeps it independent of sprint delivery pressure — commonly an engineering director or head of quality. The requirement is autonomy of backlog, not a particular org chart.
How does AI fit into Continuous QA?
Structured Gherkin scenarios are ideal AI input: teams use them to generate user manuals that stay current with the product, draft new scenario variants, and speed up automation code. The methodology predates and outlasts any particular tool — AI just compounds the value of the test-cases-as-source-of-truth principle.
The vocabulary of Continuous QA
Master Test Suite
The centralized, continuously growing collection of automated test scenarios covering the whole product, integrated into CI/CD and run on every merge. Releases gate on it being green.
Regression team
The separately resourced team that owns test-case creation, automation, suite maintenance, and the pre-release regression pass. Autonomous from sprint delivery by design.
Gherkin
A structured, human-readable format for test scenarios (Given / When / Then) supported by automation frameworks such as Cucumber, SpecFlow, and Behave. Continuous QA's default format for test cases as the source of truth.
Regression testing
Verifying that new changes haven't broken existing functionality. The chronically under-resourced discipline Continuous QA exists to give a permanent home.
Escape defect
A bug that reached production which a regression pass should have caught. Each one is treated as a missing scenario — the suite's backlog writes itself.
Pre-release / post-release phases
The regression team's alternating rhythm: validate the release candidate before it ships (automated + manual + performance), then expand coverage of what shipped afterwards.
Where the concept comes from
Continuous QA was articulated by Mark Farr (CEO, Nebo Consultants) and Tony Rehmer (SVP Information Technology, Children's Miracle Network Hospitals) — practitioners with over sixty combined years in software — in their article Continuous QA: A New Focus on Quality.
The model wasn't designed on a whiteboard. It emerged from running quality for a nonprofit managing more than thirty applications under real cost constraints — starting with minimal dedicated resources and scaling as results accumulated.
This site presents Continuous QA as an open, vendor-neutral methodology: free to adopt, adapt, and share. It is not affiliated with, or a substitute for, the original authors' work — it exists so the idea can travel further.
Adopting CQA in your organization? Start with the five-step playbook and the printable checklist.