The operating model

How Continuous QA works

Two teams, two loops, one shared source of truth. The regression team runs its own continuous cycle beside your delivery cadence — validating before every release, and building coverage after it.

The big picture

Two loops around one product

Feature teams — sprint loop Plan & build Feature testing Merge to main Release Regression team — continuous loop Write test cases (Gherkin) Automate Master Test Suite runs in CI/CD Manual + perf pre-release pass every merge triggers the suite release gated on green

Feature teams keep their sprint cadence. The regression team runs continuously beside them, meeting at the Master Test Suite.

The two phases of the regression loop

Before a release: validate

As a release candidate forms, the regression team executes the full protective pass — automated scenarios via the Master Test Suite, plus targeted manual testing for flows automation can't reach yet. Defects found here are triaged back to the owning feature team before customers ever see them.

  • Run the Master Test Suite against the release candidate
  • Execute manual regression on not-yet-automated areas
  • Run performance passes: load, stress, and boundary testing
  • Report defects with the failing scenario attached — reproduction comes built in

After a release: build

Between releases, the team's job flips from validating to expanding the protected surface. New features that just shipped get test cases; test cases get automated; flaky or outdated automation gets repaired. This is the work that in-sprint QA never has time for — here, it's the whole job.

  • Write Gherkin test cases for newly shipped functionality
  • Automate the highest-value manual cases
  • Maintain the automation framework and retire dead scenarios
  • Grow the Master Test Suite's coverage of the product

Test cases in Gherkin: one artifact, three jobs

Continuous QA standardizes on Gherkin because a single well-written scenario is simultaneously a test case a human can execute, a specification automation can run, and documentation anyone can read.

donation-checkout.feature
Feature: Donation checkout

  # Protects the flow that processes 80% of revenue
  Scenario: Returning donor completes a one-time gift
    Given a returning donor with a saved payment method
    When they donate "$50" to "Children's Hospital A"
    Then the payment is captured exactly once
    And a receipt email is sent within 2 minutes
    And the hospital's running total increases by "$50"

  Scenario: Declined card leaves no partial state
    Given a donor whose card will be declined
    When they attempt a "$100" donation
    Then no charge is recorded
    And the donor sees a clear retry prompt

Because scenarios read like plain English, product owners can review coverage directly, new hires can learn how the product behaves by reading the suite, and — with AI assistance — the same scenarios can be transformed into always-current user manuals.

Keeping it honest

KPIs that show progress before incidents stop happening

The payoff of regression work is invisible when it succeeds. These simple weekly metrics make the practice visible and steerable from day one.

TC/wk

Test cases written per week — is the protected surface growing?

Auto/wk

Automations added per week — is manual effort compounding into leverage?

%cov

Share of product functionality covered by the Master Test Suite.

Escapes

Defects reaching production that a regression pass should have caught — trending to zero.

Where performance testing fits

Load, stress, and boundary testing rarely have a natural owner inside sprint teams — they need environments, tooling, and repetition. In Continuous QA they belong to the regression team's pre-release pass: the same team that knows the product's protected behaviors also verifies those behaviors hold under pressure.

Ready to try it? The Adoption Playbook turns this operating model into five concrete steps, starting with a single engineer.