Guide

Sample Data for Software Testing

Test data is information crafted to exercise software—not to record real commerce. For document-heavy products, sample receipts and invoices are among the highest-leverage fixtures you can keep in a repo. ReceiptPlay helps you produce those fixtures quickly while keeping personal data out of staging.

What test data is (and is not)

Good test data is intentional: each file exists to prove a behavior (parse total, reject corrupt QR, render thumbnail). It is not a dump of production exports with names scrubbed poorly. Prefer synthetic merchants and customers from the start.

Why avoid real customer information

Production scans can contain phone numbers, vehicle plates, and card hints. Once those land in CI artifacts or shared drives, deletion is hard. Building samples in-browser with invented values removes that class of incident. ReceiptPlay stores generator fields in your browser only; downloads go where you save them—treat shared ZIPs as carefully as any fixture set.

Realistic vs random data

Pure randomness (random strings everywhere) finds encoding bugs but fails user acceptance—“nobody would type that.” Realistic samples use plausible station names and amounts. ReceiptPlay’s Random fill leans realistic; you can still escalate to pathological lengths when hunting overflow bugs.

Boundaries, invalid data, and edge cases

Bulk datasets and repeatable scenarios

Fuel → Bulk generation offers Monthly Receipt Plan (date range + monthly/total sample amount) and Fixed count. Use them to produce ZIP batches and optional CSV planning reports for repeatable month-view tests. Name scenarios in your test tracker (e.g. MRP-2026-Q3-LONG-NAMES) and keep the same generator settings documented beside the ZIP.

Export testing: PNG, PDF, ZIP

Image export checks canvas capture and compression. PDF export checks page margins and A4 fill (postpaid sheets aim to fill the page). ZIP export checks batch pipelines and filename uniqueness. Always open downloads outside the browser once—OS viewers catch issues the in-app preview hides.

Browser, responsive, and visual regression

Run the same fixture through Chrome and Safari viewers. Capture mobile viewports of your product’s receipt detail page. For visual regression, regenerate the identical ReceiptPlay scenario after CSS changes and diff PDFs or PNGs (see also UI/UX Testing With Document Mockups).

Sample Document QA Checklist

Example — monthly test dataset

In Fuel → Bulk, choose Monthly Receipt Plan, set a three-month window, and a modest sample monthly amount. Generate the batch, download ZIP + CSV, and drop them into receipt-tests/normal-cases/mrp-demo/. Point your reporting UI at the folder and assert month buckets fill without using any live fuel history.

Currency and locale edges

Even when you stay on ₹ formatting, test grouping separators and decimals your parser might misread. If your product localizes, generate one slip and rename expectations per locale rather than assuming the PNG text will change—ReceiptPlay’s visible currency conventions are layout samples, not a full i18n suite.

Invalid and demo QR behaviour

Postpaid mockups include QR codes that look real but are corrupted so phones cannot pay them. That is a feature for demos: you can test “QR present” UI states without enabling accidental payments. Assert that your scanner fails gracefully.

Tying checklist items to generators

Map each checklist row to a generator once, then reuse the mapping in onboarding docs for new QA hires.

Open Fuel & Bulk generation →