Certyn reads the change, finds the scenarios your tests miss, runs them, investigates what fails, verifies the fix, and keeps the release assessment current. You make the calls with evidence in front of you.
Sounds familiar
A billing change enters a release. Here is what Certyn does with it, and what you see.
A billing change enters the release. Certyn identifies the flows it touches.
The existing tests miss one customer scenario. Certyn assigns it.
Reported by a customer in support ticket #5531.
An executor runs the scenario in a real browser, and investigates the failure.
Cause: the billing API drops the credit when a coupon is set. The page is right.
Certyn files the issue, then verifies the fix when it lands.
The release assessment updates: what Certyn established, what it resolved, and what still needs attention.
Established
Billing flows: 4 of 4 verified on staging. 3 sessions on record.
Resolved
ACM-318, proration credit dropped with a coupon. Fixed in PR #491, re-verified, closed.
Needs attention
Renewal charge could not be observed on staging. Read-only check after the production deploy.
Coverage, investigation, and the release call. Each one links to the run behind it.
The change decides what to check
Certyn reads the pull request and the spec, lists the flows the release touched, and shows which of them your existing tests already cover. What is left becomes an assignment.
A failure gets investigated, not re-run
When a scenario fails, the executor finds the failing request, compares it with a working one, and says whether the page or the API is wrong. The video and the network log come with it.
The fix is verified before the ticket closes
The finding is filed with its evidence. When the fix merges, the same scenario runs again, and the ticket closes only if it passes.
Jira, Linear, GitHub · Slack for the update
The assessment says what is still unknown
Verified flows, the evidence behind them, and the ones that could not be observed. You sign off on a list you can defend, not on a green suite.
Paste this into Ask Certyn in the dashboard, or send it to the Certyn bot in Slack, with your own release and pull request in place of the example.
Before you start
Release 2.5.0 goes out on Thursday.
For the billing change in PR #482:
- which flows does it touch?
- which of those have no test, or a test that has not run since the change?
- which open findings sit on those flows?
Then run the uncovered scenarios on staging, investigate any failure,
and tell me what is still unverified before I sign off.Good follow-ups: "which of these scenarios should become permanent tests?", "show me the video of the failure", "what changed since the last assessment?"
Every finding waits for someone to confirm or dismiss it. Nothing closes itself, and a pass after a failure does not close a bug.
Records from runs that happened, not a report someone assembles by hand.
Affected flows per change
Which flows a pull request touched, and which of them have a test.
Investigations with a cause
The failing request and the working one side by side, with the session video.
Verified fixes
The re-run after the merge, so a closed ticket means the scenario passed again.
Release assessment
Ready or not, with the verified flows, the open findings, and what could not be observed.
Evidence for every claim
Video, network log, and steps behind each finding, for the review and for the argument.
The same answer in Slack
Ask in the channel where the release is being discussed, not in another tab.
No. Your cases stay in TestRail, Zephyr, Xray, or Azure Test Plans, and Certyn runs them and writes the results back. Playwright and JUnit results from CI count as evidence too. Certyn adds the scenarios your suite misses and the investigation when something fails.
It reads the pull request, the spec if you connect one, and what it learned about the app from earlier runs. The list of affected flows is shown before anything runs, so you can add to it or strike from it.
A statement of where the failure is, with the evidence: the failing request and response, a working comparison where one exists, the session video, and the steps. Enough for an engineer to start on the fix without reproducing it first.
You do. Certyn reports what was verified, what failed, and what it could not observe. Findings wait for a person to confirm or dismiss them, and a bug stays open until a person closes it.
Setup is about two minutes: a URL and a test login. Certyn explores the app and runs a first pass on its own, and the first findings arrive in minutes. One free QA hour is enough to see a real assessment before you decide.
QA hours, not seats. Free gives you one hour with no card. Founder is $99 a month for 6 hours, Team is $499 a month for 40 hours and three runs at once.
Release readiness
What goes into the assessment and how to make it trustworthy.
Release readiness playbook
A week-by-week routine for a release, with the questions to ask.
Quality metrics
Pass rate, flaky rate, and how to read a trend before a release.
Security
How data, credentials, and recordings are handled.
Start free, no card. A URL and a test login, and the first assessment comes from your app, not from an example.