For developers and QA who know which version carries a fix.
Your setup
- Issue #12 was found on staging by a Certyn run, and is confirmed.
- 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 staging. - You want the retest on 2.6.1, not before, and the issue marked fixed in 2.6.1.
Say this to Certyn
The fix for issue #12 ships in 2.6.1. When 2.6.1 is on staging, retest it. If it passes, close it as fixed in 2.6.1.
What Certyn does
- Reads issue #12 (
app.issue.get): where it was found, what it is linked to, and its last retest. - Reads the version on staging (
app.environment.get). If it is not 2.6.1 yet, it says so and does not retest: a retest on the old version proves nothing. - When staging runs 2.6.1, it starts the retest after you agree (
app.run.createtyperetest). The retest runs on the environment where the bug was found and is saved against 2.6.1. - Puts the result on issue #12: passed or still failing, with the new evidence.
- If it passed, asks, then closes #12 as fixed with version 2.6.1 (
app.issue.updatewith statusfixedandversion).
What you get
- A retest on the version that has the fix.
- "Fixed in 2.6.1" on the issue. It counts as fixed in 2.6.1 for release notes.
- If it still fails: the issue 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 issue #12. - The fix version is saved only when the issue is closed as fixed. You cannot set it on an open issue first, and a closed issue cannot be retested. So retest first, then close.
- Retest needs a confirmed issue linked to a tracker issue or a test case.
- A passing retest does not close the Certyn issue or the tracker issue by itself.