Campaigns
A suite is code. A campaign is a decision.
A suite runs on every commit and answers to the merge button. A campaign is scoped on purpose — this build, this environment, this window — and somebody has to say at the end of it whether the thing ships. Confusing the two is how a release regression becomes “the pipeline is green” and nobody notices the pipeline never covered the payment flow on Safari.
Campaigns
Continuous
Everything fast and deterministic enough to run on every commit: unit, component, integration and contract tests. Not a campaign anyone schedules — it is the one whose failure blocks the merge.
How the suite is shapedRelease regression
The scoped run against a candidate build in a production-like environment: the end-to-end journeys, the cross-browser matrix, and whatever the risk analysis flagged for this release rather than for every release.
Read the end-to-end typologyPerformance
Load, stress, soak and spike runs against the service-level objectives — with the workload written down as code rather than recorded in a GUI, which is what the research section is about.
Read the performance typologySecurity
Dependency and container scanning on every build, static analysis on every merge, and a scoped penetration test per major release. The first two are pipeline checks; the third is a campaign with a report and a deadline.
Read the security typologyExploratory
Time-boxed chartered sessions against a build, run by people who did not write it. The only campaign whose value comes from not being repeatable — the automated suite already covers what we knew to expect.
Read the exploratory typologyIn production
Synthetic journeys, canary analysis and the health of a progressive rollout. The campaign that never ends, and the only one that observes the properties a staging environment cannot reproduce.
Read the production topology- Planned
Results
Run history, pass rates, durations and flakiness trends per campaign. One run tells you about one build; the trend is the only thing that tells you about the suite.
Open the campaign results (leaves this site)
Who answers, and when it ends
Every campaign has an owner who is not “QA”, and an exit condition that is not “when we run out of time”. Those two columns are the shift-left commitment made concrete — if one of them is ever blank, the campaign has quietly become somebody else’s problem.
| Campaign | Answers | Cadence and exit | Owner |
|---|---|---|---|
| Continuous | Is the change that just landed safe to keep? | Every commit — ends when the pipeline is green | The author of the change |
| Release regression | Does the release candidate still do what the last one did? | Per release candidate — ends on a go/no-go decision | The release manager, on the team’s evidence |
| Performance | Does it still hold at the load we promised? | Per release, and on any change to a hot path | The team owning the service under test |
| Security | What can someone do here that they should not? | Continuous scanning, plus a scoped test per major release | The security engineer, with the team |
| Exploratory | What did none of us think to write a test for? | Per feature, in 60–90 minute chartered sessions | Whoever takes the charter |
| In production | Is it still true now, with real traffic on it? | Continuously, against live traffic | The on-call engineer |
| Results | What happened the last twenty times we ran it? | Written by every campaign above | The test manager |