Case study: Kasu Money’s Pay Later launch
Kasu Money is a digital wallet launching Pay Later in India, the UAE, Japan and Mexico. Its 26 people ran the whole release on KaDeep Studio Pro: planning, testing on web and Android, translating into four languages, and deciding whether to ship.
Case study · a fictional company, real runs
- 26people in 10 roles
- 3projects, set up from 45 documents
- 4languages: hi-IN, ar-AE, ja-JP, es-MX
- 6sign-offs on the release
- 269problems found in KaDeep, all fixed
- 22rounds of fixes
1. The company and its launch
Section titled “1. The company and its launch”Kasu Money sells a wallet app for the web and Android. Its release, v1.1 Pay Later, lets customers pay in three or four instalments at checkout, including at a partner merchant’s shop.
The launch had to work in four markets at once: Hindi for India, Arabic (right to left) for the UAE, Japanese, and Mexican Spanish. Each market needed the app strings, legal text, a launch poster, social copy and a staff training course.
2. The team and their roles
Section titled “2. The team and their roles”Kasu invited its people with one KaDeep role each. Three departments shared one organization.
| KaDeep role | People | Who they are at Kasu |
|---|---|---|
| Admin | 1 | Head of Quality |
| Manager | 3 | Head of Product, Legal Counsel, Marketing lead |
| QA lead | 1 | QA Lead for the app |
| Tester | 7 | QA engineers for web, Android, the UAE and Mexico; the engineering lead; the Android lead; the support and ops lead |
| Language lead | 1 | Localization lead |
| Linguist | 5 | One linguist per language, and a translation vendor’s project manager |
| Reviewer | 5 | One in-country reviewer per language, and the L&D manager |
| Finance viewer | 1 | Finance Controller (read-only) |
| Compliance auditor | 1 | Head of Compliance & Risk (read-only) |
| Viewer | 1 | Design lead (read-only) |
The admin sent 28 invitations; 25 were accepted, and 5 custom roles were made. See Invite people and give them roles and Roles and what they can do.
3. How they set KaDeep up
Section titled “3. How they set KaDeep up”Kasu made three projects: one testing project for the app, and two localization projects, one for app strings and legal text and one for marketing and training.
- Knowledge transfer. The setup wizard read 45 of Kasu’s documents: Kasu’s product specs, fee rules and terminology. See Create a testing project.
- Imports. The QA lead imported 320 existing test cases into folders. Importing them again added none twice. See Tests.
- Test logins. Test logins for each market were stored once, and the agent signs in with them. See Test logins.
- The agent’s own tests. From the Pay Later spec, the agent wrote 40 test cases in 3.4 minutes, each with its rule ids, priority and steps. See Approve the agent’s plan.
Manage view
Hands-on view
To check what the agent had learned, the team asked it 17 questions about Kasu’s own rules, such as Japan’s late fee. On the first ask it answered 5 correctly. After the fixes in section 8, it answered 15.
4. Testing on web and Android, in four languages
Section titled “4. Testing on web and Android, in four languages”Seven testers ran suites and exploratory sessions on the release candidate, on the web and on Android phones, in all four languages.
- About 400 web runs over three passes, and 31 exploratory sessions written from Kasu’s own test charters. Those sessions filed 52 bugs, 4 of them critical: one was a triple debit when a customer tapped Send three times quickly.
- Speed and accessibility. The agent found both accessibility bugs Kasu had planted. On a deliberately slow build it found both slow calls: top-up went from 418 ms to 10.2 s, and Release Ready said so to the Head of Product.
- Planted bugs, counted honestly. Kasu had planted 22 bugs in the release candidate to measure the agent. It found 16 of them (73 %), below Kasu’s own 80 % target.
The bug, fix and re-check loop
Section titled “The bug, fix and re-check loop”The head of product handed out a UI and UX pass as tasks. The testers’ agents filed 52 distinct bugs, and Kasu’s engineers fixed them in five batches. When a developer marked a bug fixed, the agent re-checked it. 42 closed on a passing re-check, 10 were dismissed with reasons, and none stayed open. Eight reopened along the way when a re-check failed; all eight were then fixed.
See Bugs and Run a test suite.
5. Localization: strings, legal, a poster and a course
Section titled “5. Localization: strings, legal, a poster and a course”The language lead ran two localization projects with four linguists, four in-country reviewers and a vendor.
- App strings and legal text. 606 app strings and 67 merchant strings went through translation and review in four languages, in 8 deliveries, all approved. Kasu’s build pulled them in. Reviewers sent strings back with a reason, and the linguists heard about it in Needs you.
- Posters and social copy. All 4 posters and 4 social copies were approved. The Arabic reviewer sent back a line that ran 42 % longer where 30 % fits, and the Arabic linguist shortened it.
- A SCORM course. Staff training was translated and accepted, 616 of 616 strings in all 4 languages, and signed off by the L&D manager. In every language, the course player records Passed · Score 100 of 100.
6. The release decision
Section titled “6. The release decision”On release day, Release Ready refused a clean go: 18 critical bugs were still open, and the gate was right to refuse.
Kasu decided to ship anyway, on the record. The QA lead named six stakeholders: localization, the UAE country lead, compliance, legal, product and quality. The UAE lead first rejected over the Arabic poster, was asked again, and approved. With 6 sign-offs, v1.1 Pay Later shipped with the risk accepted and a written reason. An evidence pack and a read-only link for 14 days followed.
Manage view
Hands-on view
See Release Ready: can we ship? and Export evidence.
7. Control along the way
Section titled “7. Control along the way”| What happened | Where it shows |
|---|---|
| Every decision in the story is in the audit log: 4,478 events by the end. | Audit log |
| Every write a read-only person tried was refused, and the refusal was recorded. | Governance |
| Overnight scheduled runs used up Kasu’s $600 monthly budget, so new runs stopped. The admin raised it to $1,000, and the change is on record. | Spending limit and approvals |
| One request to run tests was signed by the lead, then the manager; one escalated after 31 minutes; one was rejected with a reason. | Approvals |
| All 26 people replayed their own work: each finished in 5 minutes or less, with no dead end. | Your Home page |
8. What it found and fixed in KaDeep
Section titled “8. What it found and fixed in KaDeep”Running a whole company on KaDeep also tested KaDeep. The team logged 269 problems: 9 blocking (P0), 68 serious (P1), 135 moderate (P2), 53 minor (P3) and 4 unrated. We fixed all of them, over 22 rounds. They are in KaDeep Studio Pro 4.0.
| Before | After |
|---|---|
| The head of product could not see who does what by when. | Team › Timeline: people and projects on one axis, with a today line and late flags. See Timeline. |
| Requirements read from the documents came out as 589, from documents that hold 209, without their ids. | 315 requirements, each with its document id. See Requirements and coverage. |
| None of the 320 imported cases linked to a requirement. | 320 of 320 linked. |
| Release Ready judged every release on default criteria. | The exit criteria on the test plan drive the release gate. See Plans. |
| Assigning a bug, or asking for a sign-off, told nobody. | The person gets a bell row and a Needs you item. See Needs you. |
| A forbidden glossary term could become the translation. | A forbidden term is never taken as the translation. |
The full list of changes is in What’s new in v4.
9. Timeline
Section titled “9. Timeline”| When | What happened |
|---|---|
| Day 1, 4 Nov | People invited and roles given. Three projects set up from 45 documents. 320 cases imported. The agent wrote the Pay Later tests. |
| Night of 4 to 5 Nov | Translation and review of all 8 deliveries. Three test passes on the release candidate and 31 exploratory sessions. Posters, social copy and the course. Speed and accessibility checks. Approvals, finance and audit. |
| Early 5 Nov | Release Ready refused a clean go. Six stakeholders signed, and v1.1 Pay Later shipped with accepted risk. Evidence pack and read-only link. |
| 5 Nov | Every one of the 26 people replayed their work. The UI and UX pass started as tasks. |
| 5 to 6 Nov | 52 bugs filed, fixed in five batches and re-checked. Late strings found, translated, reviewed and approved. Final checks of the fixes. |
| 6 Nov | KaDeep Studio Pro 4.0.0 released, with every fix. |
10. Results and lessons
Section titled “10. Results and lessons”| Result | Number |
|---|---|
| People who replayed their own work with no dead end | 26 of 26 |
| App and merchant strings delivered, in 4 languages | 606 + 67, in 8 deliveries |
| Course strings accepted, in 4 languages | 616 of 616 |
| Bugs from the UI and UX pass closed or dismissed with a reason | 52 of 52 |
| Planted bugs the agent found | 16 of 22 (73 %; Kasu’s target was 80 %) |
| Problems found in KaDeep, and fixed | 269, all fixed |
What we’d tell a team starting out:
- Write your exit criteria before release day. The gate judges against them. It refused a clean go here, and it was right.
- Measure the agent before you trust it. Plant a few known bugs and count what it finds. Kasu’s number, 73 %, told them where to keep human testers.
- Run your own checks on deliveries. Kasu’s build check caught what review missed. Those checks are now gates in KaDeep.
- Leave room in the budget and the AI allowance. Overnight runs used up the month’s budget, and the AI provider’s allowance ran out too. Runs now show Paused when that happens, never “running”.
- Track late changes. Two late string files sat untranslated for 13 hours, so about 129 Pay Later strings shipped in English. Once found, they were translated, reviewed and approved in 50 minutes. The gaps that hid them are fixed.