Home/Sample verdict

This is what you receive before every release.

Not a dashboard you have to interpret — a verdict a named engineer has signed, with the evidence attached. Below is an illustrative report for a ticketing on-sale build. Real reports carry your flows, your numbers and a real name.

Illustrative sample · all data synthetic · format identical to a real Zenius verdict

Release verdict · Managed QA

Release 4.12 — "Boxing Day on-sale" build

Customer: Example Tickets Ltd (sample) · Product: web checkout + mobile web · Environment: staging-2 (production-like)
PR #2291 → main · build 4127 · Verdict issued 14 days before the on-sale

GO — cleared to ship

01Summary

All agreed critical flows are covered and passing on the release candidate. One genuine defect was found by the exploratory session, fixed in commit a3f9c2, and verified by a re-run. The load rehearsal found the payment gateway throttling at 32,000 concurrent users; the fix (connection pool + retry budget) was verified at 40,000 with p95 checkout latency of 1.8 s. No open P1 or P2 issues. Recommendation: ship, with the on-sale standby plan in section 08.

Critical flows covered
18 / 18
Automated cases run
316
Open P1 / P2
0 / 0
Rehearsed concurrency
40,000

02Scope agreed in writing (week 1)

Critical flowOwnerAutomatedExploratoryLoad
Seat selection & hold (single, group, accessible seating)Checkout squad42 casesSession 1Yes
Virtual queue entry & fairness at sale openPlatform18 casesSession 1Yes
Promo code redemption & stacking rulesCheckout squad37 casesSession 2Yes
Payment, retry after gateway timeout, 3-D SecurePayments64 casesSession 2Yes
Refund & cancellation (post-sale)Support tooling29 casesSession 2
Mobile web (iOS Safari, Android Chrome)Checkout squad126 casesSession 1

03Agent pre-validation — PR #2291

The Zenius agent read the three acceptance criteria on the pull request, generated 14 tests from the library, ran them against the branch and classified the results. A senior engineer reviewed every generated test before it joined the suite.

Acceptance criterionGenerated testsResultTriage
A promo code applies at most once per order55 passed
A refund releases the held seat within 60 seconds44 passed
A retry after a gateway timeout never double-charges54 passed · 1 failedP1 genuine defect → dev (fixed a3f9c2, re-run verified)

04Automated run — 316 cases on build 4127

Passed
312
Flaky → environment
3
Genuine defect → dev
1
Duration (parallel)
11 min
FailureClassificationEvidenceResolution
checkout/retry-after-timeout-does-not-double-chargeDefectvideo · trace · HAR · consoleFixed a3f9c2 · re-run 4128 passed
queue/position-updates-under-1s (×3)Flaky · envtrace · timing logsstaging-2 websocket cap raised · stable across 5 re-runs

Pass-rate trend, last 30 runs: 96.1% → 98.7%. Escaped defects this quarter: 0.

05Exploratory sessions — senior engineer, 2 × 3 hours

Worked the on-sale the way a frustrated fan, an impatient buyer and a malicious user would: two tabs on the same seat, abandoning at payment and returning, currency switch mid-checkout, promo replay after refund, expired queue tokens.

FindingSeverityReproductionStatus
Promo code re-applies after a refund; second order total goes negativeP1Refund order → reuse code → apply twice on new order (video 02:14)Fixed a3f9c2 · verified
Queue position badge shows stale value after tab restore on iOS SafariP3Background tab 90 s → restore (trace attached)Accepted for 4.13 · cosmetic

06Load rehearsal — T-minus 17 days

Full on-sale rehearsal at expected concurrency with seat holds, queue fairness and payment retries exercised together. Breaking point found at 32k concurrent (payment gateway throttling → checkout p95 above 6 s). After the fix, 40k concurrent sustained for 20 minutes.

StageConcurrent usersCheckout p95Error rateOutcome
Ramp 110,0000.9 s0.02%Pass
Ramp 225,0001.4 s0.05%Pass
Ramp 3 (before fix)32,0006.3 s4.1%Gateway throttling — breaking point
Ramp 3 (after fix)40,0001.8 s0.06%Pass — event-day target met

07Residual risks & recommendations

1. Third-party fraud-screening latency was mocked at 300 ms; production figures above 800 ms would push p95 over 2.5 s — confirm the vendor's peak-day SLA. 2. Refund flow has no load coverage by design; volumes are low post-sale. 3. iOS Safari stale badge (P3) is scheduled for 4.13.

08On-sale standby plan

A Zenius engineer is on standby from T-minus 60 minutes to T-plus 3 hours with the rehearsal dashboards open, the incident channel joined, and the rollback path pre-agreed with the platform lead. Post-event note delivered within 24 hours.

09Sign-off

Verdict
GO — cleared to ship1 defect fixed and verified · 0 open P1/P2 · load target met
Signed by
[Named senior engineer], Zenius QAOn real reports this is a person with a name, an email address and the authority to say no.
Why the signature matters. Dashboards report percentages; nobody is accountable for a percentage. A named engineer who signs the release is accountable for the verdict — and has the evidence to defend it in your incident review.

How this compares

Tools give you results. This gives you a decision.

Test platforms — including good ones — hand you pass/fail counts and leave the judgment to whoever has time. A Zenius verdict closes the loop: every failure classified, every defect tied to a fix and a verified re-run, the peak rehearsed, and a person who signs.

Want this on your product?

Free coverage map, five business days.

Send a URL. You get the critical-flow map, the tests we would run, the peak we would rehearse and a first verdict on one flow — in exactly this format.