200apps Corpus

Appearance

Quality & Testing · master area

Regression Testing ​

Full-slice verification before release. The Gherkin set + the explicit critical paths. Not "what changed" — "did anything that was supposed to keep working still work?"*

Owners: QA, Developer Phase it lives in: How We Build (Volume IV) The corpus principle this enacts: The pipeline catches a different chain level at each stage.

Where it lives in the chain ​

How to do this ​

Regression coverage is layered:

  • Automated regression — the full Gherkin set runs in CI. Every scenario named in amigos for every feature, across the product. Fast — under 15 minutes for the full set.
  • Manual critical paths — N critical user journeys walked manually before release. Authored and maintained by QA. "Gal grades 3 exams. Uri reconciles a payment batch. The receptionist books a vet appointment."
  • Visual regression — every Storybook story checked against baseline.
  • Performance regression — load test at SLO threshold.

What good practice looks like ​

The regression set grows by one scenario per cycle, on average. Every bug that ships becomes a new regression scenario in the next release. The wallet bug became a "display negative balances correctly" scenario; the JWT outage became a "gateway accepts existing-shape tokens" contract test. The chain learns by accumulation.

The regression set is pruned, too. Scenarios that have not failed in a year and don't represent active risk get retired. A regression suite of 10,000 tests that takes 4 hours is a suite the team has stopped paying attention to.

The discipline: regression is the chain's memory of what it has learned. A team without regression testing relearns the same bugs every quarter. A team with overgrown regression testing pays for the memory in CI time and ignores the failures. The middle is intentional curation.

200apps · How We Work · NWIRE

Internal corpus. Voice and structure © 200apps.