Skip to content
Start Free

Retest a fix on its version

Certyn retests a finding on the version that carries the fix, on staging or after a hotfix on production, and you close it as fixed in that version.

For developers and QA who know which version carries a fix, and want proof on that version before anyone closes the finding.

Your setup

  • Finding #12 was found on staging by a Certyn run, and a person confirmed it.
  • It is linked to a Jira, Linear or GitHub issue, or to a test case.
  • The fix ships in 2.6.1. Your deploy sets the version on the environment.

Say this to Certyn

The fix for finding #12 ships in 2.6.1. When 2.6.1 is on staging, retest it.

Or type /retest and pick the finding with @.

What Certyn does

  1. Reads finding #12: where it was found, what it is linked to, and its last retest.
  2. Reads the version on staging. If it is not 2.6.1 yet, it says so and does not retest: a retest on the old version proves nothing.
  3. When staging runs 2.6.1, it starts the retest after you agree. The retest is a short run (5 minutes) on the environment where the finding was found, saved against 2.6.1.
  4. Puts the result on finding #12, with the new evidence: reproduced, not reproduced, partly reproduced, or blocked.
  5. If the bug did not reproduce, Certyn offers to close the finding with the reason Fixed and version 2.6.1. It closes it only if you agree. You can also close it yourself: Close finding, reason Fixed, then pick the release under Fixed in release.

After a hotfix on production

We just put hotfix 2.5.1 on production for finding #31. Do a read-only smoke check and retest #31 there.

  1. Reads the version on production. If it does not show 2.5.1, it offers to set it with a short changelog. You approve. A new version starts production's after-deploy suites, such as a read-only smoke check.
  2. Runs the smoke check, if no after-deploy suite already does: a short run on production with a look-only goal. Sign in, open the main pages, search, change nothing.
  3. Retests #31 if it was found on production. A finding from staging is retested on staging, so for production Certyn runs the finding's steps as a short run there, look-only where the steps allow.
  4. Reports both results, saved against 2.5.1. 2.5.1 shows on the Releases page with the date it reached production.

What you get

  • A retest on the version that has the fix, with evidence either way.
  • "Fixed in 2.6.1" on the finding once it is closed as fixed. It counts for release notes.
  • If the bug still happens: the finding stays open, with the new run as evidence.

Limits

  • Nothing retests by itself when 2.6.1 is deployed, and the chat cannot wait for a deploy. Ask after the deploy. Or let your deploy job send Certyn an instruction (GitHub Action or CI Runs API), for example 2.6.1 is on staging. Retest finding #12. Or put the retest on the release's agenda.
  • Retest needs a confirmed finding linked to a tracker issue or a test case. Other findings get a short run with the same steps instead.
  • The fix version is saved only when the finding is closed as fixed. A closed finding cannot be retested, so retest first, then close.
  • Certyn reports what the retest saw. It never closes a finding or a tracker issue on its own.
  • Read-only on production is an instruction in the goal and your Knowledge rules, not a lock. For a hard guarantee, use a production account that can only view.
  • If the bug only shows when data changes (for example placing an order), a look-only check cannot prove the fix. Retest it on staging with 2.5.1, or allow one named action on production.
  • Setting the version from the chat needs your approval. The same version twice starts nothing.
PreviousFollow a releaseNextWrite release notes from evidence