Customer storyHow Yuna scaled release validation across languages, personas and regions
A QA system for mobile experiences that change with user context, conversation history and locale. Before Quash, the team could validate two or three persona-region combinations per release. The rest went out on trust.
Full regression cycle
3 days → 2.5 hours
Persona × region flows per release
2 → 12
Languages in test coverage
3 → 8
Chat scenarios with intent + card validation
45+
Automated runs across four months
1,831
Yuna is an AI-native mental wellness platform used across 155+ countries. Its mobile experience changes with language, region, role and prior conversation. Yuna includes crisis escalation and acute-care resource flows — paths sensitive to language, region and prior context. The team built validation into Quash and expanded from a four-suite pilot to 25 nightly suites in about four months.
The same build produces many valid experiences
Yuna serves different user groups across regions and languages. Region changes resource paths and parts of the content. Role changes which surfaces and escalation options are available. Conversation history changes the prompts and follow-up coaching a user sees.
For QA, that meant the state had to be correct before a test even reached the UI. Locale, persona, organisation tier and prior conversation context all influenced the expected result — and none of them were things a test could stub out.
Manual regression was selective by necessity — a small change in onboarding or chat could ripple across eight languages, four personas, four regions and several conversation states. The team could cover two or three combinations manually in a release cycle.
Chat introduced a second layer of uncertainty. Yuna's chat is dynamic: message length changes the layout, the detected intent determines which UI card is emitted, and the bot response varies with the conversation. A test couldn't stop at confirming that a reply appeared. A message about ongoing insomnia should trigger a specific sleep-support card — verifying that means checking the backend event, the card that renders on screen, and the response intent, all three.
The tools Yuna had evaluated could automate stable interactions, but none of them tied user state, backend intent, dynamic card rendering and response validation into a single release test. What worked for a form-based flow broke as soon as the app started varying with context.
How each scenario is validated — four deterministic layers
Quash's orchestrator, Mahoraga, sets the user state before the mobile test starts, then validates each layer of the chat experience separately. The checks are attributable — the team can always see which layer disagreed with the expected outcome.
25 suites · 629 test cases · 45+ chat scenarios
From a four-suite pilot to the full persona × region × language matrix, running nightly:
Set the test state
Before the mobile UI test starts, the suite configures locale, user role, organisation tier and prior conversation history — down to what the user has already discussed with the bot over past sessions. No mocked account, no generic placeholder.
Check the backend event
For chat scenarios, the emitted card ID is checked against the expected event contract. If a message about insomnia should have triggered the sleep-support card and the backend emitted the burnout card instead, the test fails at the event layer — deterministically, on the ID.
Confirm the card rendered
The card ID is validated in the client — that the same ID the backend emitted made it into a rendered element on screen, with its expected content. The check is anchored to the ID, not a screen position.
Validate response intent
A rule-based intent taxonomy is evaluated against a human-reviewed benchmark set curated for each scenario. If a message about panic breathing is expected to draw a grounding response, the reply is compared deterministically against phrasing sets Yuna's clinicians reviewed and signed off on.
Every failed step includes screenshots and gesture traces. Chat failures also include the backend event log so the team can see exactly which layer — event, render, taxonomy or tone check — disagreed.
Before Quash
After Quash
“The app doesn't just work. It has to sound right to someone reaching out. That's the bit we care about getting done, every release.”
Consistency, not just a larger test count
Before the new suite, localized escalation paths were spot-checked — most often in English and sometimes in Spanish. Those scenarios now run through the same process as the rest of the suite: the correct locale and persona, the expected backend card event, the matching on-screen render, and response-intent validation. Every release. Every locale.
In the three months since the escalation-flow gates went live, the suite has caught 7 regressions before release. Two were in escalation flows — the class of bug the team was most worried about. Both would have shipped otherwise.
The three-day regression cycle now runs in 2.5 hours, and roughly 40 hours of QA time a week — the manual re-testing that used to fill the calendar — has moved to exploratory work.
