Concepts

Assurance: regression and security regression suites

Assurance is where you replay tests against a running deploy and get back a dated, pinned report of what passed, what broke, and what changed since last time. You reach it under the Assure pill, which has two leaves: Governance (the delivery and audit report) and Assurance (the suites you run here). Assurance is the second leaf — selecting Assure lands you on Governance first, then you switch to Assurance.

This page explains what Assurance is and how its two suites work. For the click-by-click steps, see Run an assurance suite.

What a suite is

A suite is a set of checks you run on demand against a chosen pipeline stage’s live deploy. Two suite types ship, and you switch between them with the toggle at the top of the page:

  • Regression — replays your maintained set of test scenarios against the live deploy to catch anything that broke since the last run.
  • Security Regression — replays authorized security checks against the live deploy to catch new weaknesses and any that have re-opened. It is automated evidence: it supports, but does not replace, an independent penetration test.

These two are the whole list. There is no performance, accessibility, or contract suite.

Every run you trigger is version-pinned — tied to the exact version of your code that was live when it ran — and immutable: the report doesn’t change after the fact. The delta is always measured against the previous run of that same suite, so each report answers “what changed since last time?” The first run of a suite has no earlier run to compare against, so it reports no delta.

Nothing you do in Assurance writes to your repository. Your test scenarios and your security findings both live in DIJJI.

Regression: the scenario loop

A regression run replays your corpus — your maintained set of test scenarios. Before a suite has a corpus to replay, you build one, then keep it current over time. The loop is:

  1. Author. DIJJI explores your live app, tries scenarios, and keeps only the checks that pass. The result is saved as a draft for you to review — it is never written to your repository.
  2. Review. Read the draft scenario by scenario. You can leave a comment on any single scenario to change it, and you can add corpus-wide guidance to add scenarios, drop a class of them, or reshape coverage.
  3. Regenerate. Once you’ve left at least one comment or some guidance, Regenerate re-authors the draft with your changes applied and re-validates the affected scenarios against the live deploy.
  4. Approve. When the draft reads right, Approve it. Approving promotes the draft to the active baseline — the set of scenarios the suite replays on every run from then on.

Each draft is numbered (for example, Corpus draft · v2). You can only approve a draft once no comments are still waiting to be applied, so a review either ends in a Regenerate or in an Approve, never a half-applied state.

Security Regression: the findings gate

The security suite is different in shape: you don’t author it. The scan discovers weaknesses on your live site, and each one becomes a finding in a persistent set that is tracked across runs. A finding’s title names the protection the scan checked for — it’s listed because that protection is currently missing.

A new finding starts as proposed and waits for your decision:

  • Confirm a proposed finding to track it permanently. It becomes an open finding and can be routed to a fix.
  • Retire a finding whose risk you accept or that no longer applies.

This human gate is the point: the scan surfaces candidates, you decide which ones count. A finding that you’d seen fixed but which reappears in a later scan is flagged reopened — a security regression, called out so a quietly-returning weakness can’t slip past.

What you get back

Each completed run produces its own report — the delta against the previous run, the failing or open cases with their details, and the likely culprit changes when something newly broke. A regression and a security run for the same deploy are also fused into a single per-deploy evidence package you can export. See Delivery Evidence reports for what that report contains.

Because a suite runs against a pipeline stage’s deploy, it helps to know how your stages are laid out first — see The pipeline: stages and gates. When you’re ready to trigger a run, head to Run an assurance suite.