POSTOct 2026

Seed Through the Front Door: QA Test Data from a Claude Chat

Two phone screens. On the left, a Claude chat asking for a childcare booking that runs through the whole job day with a 5-star rating. On the right, the finished result card, with a Payment Successful notification arriving on top.

Most of a QA tester's time goes into setting up, not testing. Before they can check a single screen in our app, they have to create a booking, switch to a carer account, apply, switch back, approve, pay, start the job, and so on.

Some states can't be reached by hand at all. A tuition class can only be started within two hours of its start time, and every booking path needs days of notice. Testing those meant asking a developer to move things around in the database.

I work on the platform at Kiddocare, a Malaysian marketplace where parents book Kiddocarers (our babysitters) and tutors. I wanted to fix this with Claude, both for the QA team and to check my own work faster.

The answer is a Claude chat connected to an MCP server loaded with QA scenarios. A tester tells Claude the state they need, and starts testing.

One sentence in, a finished job out

This is the whole request:

Make a childcare booking for customer 51921 with carer 51918, run the whole job day, and have the parent rate 5 stars.

Claude picks the matching scenario, runs it, and replies with a card that says what it built and what to check next. Within a minute the booking is paid, the carer has gone on the way, arrived, filled in the checklist and report, and finished the job, and the parent has left 5 stars. In the customer app, the session already shows "Completed with Review".

Why not just write rows into the database?

That's how most seed scripts work. But an app action is more than a database write. There are notifications, cascading updates, queued jobs, prices and points.

So the scenario plays the customer and the carer step by step, through the same API our apps call, as the tester's own accounts. Everything that happens in real life happens here too: push notifications, KiddoPoints earned, the review prompt. One run sends about 20 notifications across the customer's and the carer's phones. Only the bank's payment page is skipped.

Four push notifications from one scenario run, in the order they arrived: a Kiddocarer has applied, Payment Successful with 101 KiddoPoints earned, your Kiddocarer has arrived, and you have 6 new notifications.

A SQL seed skips every one of those rules, and it drifts from the code without anyone noticing. A scenario can't drift quietly. When an endpoint's contract changes, the scenario breaks, and that's the point. A seed would keep "working" and build a state the product can no longer reach.

It found a bug on its first demo

The first time I ran the demo for this post, it failed. The carer I picked had old applications pointing at bookings that had since been deleted from QA, and the step that tidies up a carer's other applications after a payment crashed on them.

A seed script would never have noticed, because it never runs the payment flow. The scenario did, because it pays the way a customer does. The fix went out the same evening, and the demo ran clean on the next try.

How it's built

Steps own the API, scenarios own the story. Endpoints and payloads live in reusable steps, and a scenario only picks which steps to run. When the API changes, the fix happens in one place.
One registry, three front doors. A new scenario class is immediately available from a developer command, from the MCP server in a Claude chat, and from a Backoffice page.
Refuse early. Each scenario declares the tables and columns it needs, and won't build anything if one is missing. QA migrations are applied by hand, so the app can't tell what's pending.
Stop and ask. When a scenario reaches a choice that belongs to a person, such as which tutors to offer, it lists the options and waits.
A card, not a wall of text. The tool returns plain text for the model, plus structured content that the chat renders as an MCP App card: what was built, the next steps as a checklist, and a link to the booking in Backoffice.

The result card in a Claude chat: session completed and rated 5 stars, with its status, payout, customer and carer, price and review. Ids and locations are blurred.

The states that took longest are now one sentence

A carer who has to accept the parent's edits halfway through a fee negotiation. A tuition class that starts in 30 minutes. A customer with 5,000 points, some expiring in 3 days, and a 3x promo running.

Each of those used to need a developer. The first thirteen scenarios landed within a week, and there are 21 now, from vouchers to tuition reschedules. The tool keeps growing as our features grow.

On safety

The scenario server only exists on QA. Production doesn't register it at all, whatever the config says. Signing in goes through OAuth with a per-user permission, and scenarios that need a password hand off to Backoffice, so Claude never sees one.

A tool that can run whole user journeys is too much uncontrolled power for production. If you build something similar there, build small, narrowly scoped tools that each do one thing, and gate each one by permission. That's what we do on production: each write tool changes one setting, shows a preview first, and only saves after you confirm.

If you're curious how we use Claude and MCP for data questions on production, I wrote about that in Data Analysis with MCP and Claude Chat.

Fixtures test your fixtures. Endpoints test your product.