Test Customers for Friday’s Checkout Demo

It is Thursday afternoon, and your team needs a checkout demo for Friday. The application works, but every customer is named Test User, every basket contains one item, and every payment succeeds. You could copy a few rows from production. Instead, you need invented customers and orders that behave enough like real ones to make the demo useful.

This is synthetic test data: information created for testing rather than collected from actual people or transactions. The goal is believable behavior. A checkout should calculate totals correctly, handle unusual addresses and survive a declined payment, even when the customer has never existed.

Realistic data follows your application’s rules

A convincing name is only a small part of realism. The relationships between fields matter more. An order’s delivery date should follow its purchase date. Its total should match its items, shipping, discounts and tax. A canceled order should follow whatever cancellation rules your application actually uses.

Start with a small specification. For the checkout demo, define customers, products, orders and payment outcomes. Mark required fields, allowed values and relationships. If each order belongs to a customer, every customer reference must point to a customer you created.

Keep three kinds of realism in mind:

• Format: dates, currencies and postal codes use the forms your application accepts.
• Logic: related values agree, such as an order total matching its component amounts.
• Variety: the dataset includes different basket sizes, missing optional fields and unsuccessful payments.

A small checkout dataset with useful variety

For Friday’s demo, begin with 30 customers and 80 orders. Give some customers no orders and others several. Include guest checkout if the product supports it. Use a few supported countries, with address formats appropriate to each, rather than changing the country field while leaving every address in the same format.

Reserve several records for deliberate scenarios: an expired discount, an unavailable product, a declined payment and a customer who retries successfully. Keep ordinary orders too. A dataset made entirely of failures makes the normal checkout path difficult to inspect.

Write down these choices. Your mix is a testing decision, not evidence of how customers behave in production. If you later need representative proportions for analysis or performance work, you will need a justified basis for them.

AI can draft records from a clear specification

An AI model can help invent varied names, product descriptions and plausible order stories. Give it the schema and rules before asking for records. A useful request might be: “Create 30 fictional customer records as JSON. Use unique customer IDs, email addresses under example.com, no real contact details and only the supported country codes GB, DE and CA.”

Then generate orders that reference those customer IDs. Specify the permitted payment states and the cases you want covered. For repeatable fields such as identifiers, totals and timestamps, a short script is often easier to control than asking a model to calculate everything.

If you want to try this through your existing development tools, RelayVano offers pay-as-you-go access to AI models through an OpenAI-compatible API at https://api.relayvano.com. Sign up to generate a small batch from your specification, then validate it before adding it to your test fixtures.

Invented records still need validation

Generated output can look polished while breaking basic rules. Check that IDs are unique, required fields exist, references resolve and totals add up. Reject unsupported status values. Save the validated dataset, or use a generator with a fixed random seed, so a failing test can be reproduced.

Keep intentionally invalid records in clearly labeled fixtures. A missing delivery address might be perfect for testing an error message, but confusing in a dataset expected to pass validation.

Keep fictional customers away from real delivery channels

Use reserved example domains for email addresses and route outgoing messages to a test inbox. Use your payment provider’s sandbox credentials and test payment methods. Disable actual fulfillment. Fictional records can still trigger real actions if the surrounding systems are live.

Changing names in a production export does not automatically make it synthetic or anonymous. Addresses, purchase histories and combinations of attributes may still identify someone. For this checkout demo, build from the application’s rules and invented scenarios. Store the fixtures with a brief note describing their purpose, assumptions and intentional failures, so the next developer knows exactly what they test.