JinuGen
Nothing broke.
Five of six never got through.
Six simulated testers work one journey through your app in a real browser. They skim, misread, lose patience and give up — and the run records why, in their own words.
They are not your users. No account, no history with you, no domain knowledge, no reason to care. What they catch is the class of failure where a page confuses someone reading it for the first time. That is the whole claim.
A recording of one simulated tester, Jordan, working through a live online classes page. Across thirteen actions over three minutes his frustration rose from 0.40 to 0.95 while looking for a price and a schedule that the page did not carry. Five of the six testers on this run did not finish.
50% of all 100 actions were scrolling · 0 prices on the page · 0 class times · 6 of 6 reached for the chat widget
Every request returned 200. Every test passed. Nobody finished. Call it a green failure: a journey where nothing broke and no one got through. It is the only kind of failure your CI cannot see.
The tape · run ec937c0f7a6d
The whole session, unedited.
GOAL — “Find out about the live online classes: what ages they are for, when they run, and what they cost.”
Dotted underline marks a word our redactor over-stripped from the stored trace and we put back. Nothing else is edited.
…and what it doesn’t prove
The case against that tape.
Nothing on that page was broken. Every request returned 200, and a passing test suite is the correct result there — the suite was not wrong, it was asked a different question.
Sofia, one of the six, finished. A clean six-for-six wipeout would read as fabricated, and it should.
This is one page, one journey, one run. It says nothing about a visitor who arrived from an ad that had already told them the price.
One finding from this run never reached the report. The panel flagged three testers as blocked by an overlay; the check that runs before anything is shown to you compared that against what they did next, found all three had clicked straight through it, and dropped it. You are reading what survived that step, which is the point of having it.
Convergence
One tester is an anecdote.
Six ran the same journey independently, with different patience, different reading speed, different tolerance for a dead end. All six ended above 0.85.
Start, peak and action count are recorded. The dashed line marks 0.70, where a tester starts abandoning their plan. Only Jordan has a stored per-action trace on this run, so the path between start and peak is drawn straight rather than invented.
Six channels
Parameter sets, not personalities.
| Tester | Behaviour | Peak | Steps | Actions | Outcome |
|---|---|---|---|---|---|
| Jordan | Skims. Clicks fast. Assumes the obvious thing works. | 0.95 | 2/3 | 13 | stuck |
| Dorothy | Reads everything before acting. Slow, thorough, easily unsettled. | 0.87 | 2/3 | 20 | ran out of actions |
| Tyler | Impatient, mobile-minded. Gives a page seconds, not minutes. | 0.95 | 2/3 | 18 | stuck |
| Catherine | Compares options. Checks the details before committing. | 0.95 | 2/3 | 19 | stuck |
| Amara | Navigates by structure and labels rather than layout. | 0.90 | 1/3 | 20 | ran out of actions |
| Sofia | Anchors on a first impression and struggles to re-plan. | 0.93 | 3/3 | 10 | completed |
The same six every run, fixed on purpose. If the testers changed between builds, “this is fixed” would be indistinguishable from “a different tester didn’t happen to hit it.”
Mechanism
How it actually runs.
- 01
A real browser
Chromium, driven by Playwright. Not a crawler, not a DOM parser, not a language model reading your HTML.
- 02
They navigate by looking
The tester works from the rendered page, the way a person does — not by reading your HTML. Anything that can only see markup passes tests a human would fail.
- 03
Six fixed parameter sets
Each tester carries its own tolerances, calibrated so a session behaves like a person having that kind of day rather than an agent completing a task. Identical every run, which is what makes two runs comparable.
- 04
No selectors, ever
You describe the journey in a sentence. Nothing in the scenario names a CSS class, so re-theming your app does not invalidate the test.
A research panel interviews people about a product. It has no second build to compare against, so it cannot tell you whether your change worked.
Send us a staging link.
Tell us the URL and the one flow that would hurt most if it broke. We are taking a small number of early teams.
Not a replacement for talking to your users, not an accessibility audit, and not a replacement for your test suite. A finding needs two testers to independently hit the same thing before we report it. When a run is compromised — by our tooling or by your rate limiter — we say so and run it again rather than grading you on it.