Skip to content
Start Free

Follow a release

Declare a release, plan its tests with Certyn, see where it is across environments and what was found in it, and compare it with the last one.

For QA leads and release managers who want to plan the testing of a version, know where it is, and say what changed in quality.

Your setup

  • Environments such as dev, staging and production. Production is marked as a production environment.
  • Your deploys set each environment's version, for example 2.6.0 (see Run a suite after each deploy).
  • Release notes, or changelogs your deploys write on the environment.
  • Certyn test cases that cover parts of the app.

Plan the release

Create release 2.6.0 for 2026-11-03 with these notes: bulk edit on /products, faster checkout, coupon rounding fix. Then plan tests for what changed.

  1. Certyn asks, then saves the release with its notes and target date. It names no environment yet: naming one sets that environment's version to 2.6.0 and starts its after-deploy suites.
  2. Reads what changed: your notes, and the changelogs of the last versions on staging.
  3. Finds the test cases for each changed area by name, text or tag, and names the areas that have none.
  4. Drafts the release's agenda in the chat: the suites and test cases to run, retests of open findings, and a short exploration for each area without tests, new features first. You change it until you agree. Nothing is saved before that.
  5. Saves the agenda. Its items run at their planned times until the target date, on the version the environment runs then.

See where it is

Where is 2.6.0 now? When did it reach dev, staging and production, and what was found in it on each?

Certyn answers with one row per environment: the version now, when 2.6.0 arrived, and the findings found in 2.6.0 there. The first time a version reaches a production environment is its ship date. It reads each environment's last deploys with their changelogs.

Compare two releases

Compare 2.6.0 with 2.5.0. What is new, what is still open from 2.5, how do the pass rates compare, and what looks like a regression?

  1. Reads both releases: the verdict, the findings found in each, the runs with results, and for 2.6.0 the open findings from earlier releases.
  2. Splits the findings: new in 2.6.0, still open from 2.5.0 or before (not checked again on 2.6.0), and closed.
  3. Counts run results per version and gives a pass rate for each. It names the test cases that ran on both versions, so the numbers compare the same tests.
  4. Lists likely regressions: test cases that passed on 2.5.0 and failed on 2.6.0, and new 2.6.0 findings in areas that passed on 2.5.0.
  5. Offers next steps, such as retesting the old open findings on 2.6.0. It asks before it starts a run.

What you get

  • Releases in the top menu lists each release with where it is, its verdict and what was found. The verdict is one of Not tested yet, Not ready, Ready with risks, No known blockers, or On the agenda while its agenda runs. It comes from known evidence only; people decide if it ships.
  • A release page with its agenda, its environments, the runs on it, and the findings found in it.
  • "Found in" on each finding: the version its run tested. A finding from staging keeps 2.6.0 after staging moves to 2.6.1. The Findings page filters by it.
  • Runs and findings saved against 2.6.0, ready for a go/no-go and release notes.

Limits

  • Certyn knows only the versions your deploys report. With no version on an environment, runs and findings have none.
  • A run belongs to 2.6.0 only if the environment runs 2.6.0 when the run starts.
  • A deploy of the default 1.0.0 (or v1.0.0) or a 40-character commit SHA stays in the deploy history but does not become a release. Use real version names, or ask Certyn to create the release.
  • Names must match exactly: 2.6 and 2.6.0 are two different releases. Certyn lists the releases to find the right names.
  • A finding you file by hand in the chat has no "Found in".
  • Certyn matches changes to test cases by their text, not by your code. You can also name the test cases or a tag.
  • The chat sees only the first 300 characters of each changelog. Paste long release notes into your message.
  • Pass rate per version is counted from the runs, not stored. If each version ran different tests, the rates do not compare well, and Certyn says so. A likely regression is a guess from results until Certyn checks the cause in the run report.
  • Runs use plan time. Certyn says each run's length before it starts.
PreviousStripe test mode payments and feature flagsNextRetest a fix on its version