There's a specific kind of wasted hour that QA practitioners know well. You're on your third regression pass of the day. You enter the same test user — name, email, IBAN, account status — by hand, again. By run 6 or 7 you've fat-fingered a field. The form behaves unexpectedly. You spend 40 minutes tracing a "bug" that turns out to be a typo in the test data.
The textbook answer is: automate it. Write a Playwright script. Setup fixtures. Wire up a CI job.
That's the right answer for stable, repeatable E2E tests. But for exploratory passes, quick smoke checks on a form that reshapes every sprint, or manual testing on a staging environment that doesn't have a CI pipeline — a script that ties you to CSS selectors you'll be updating for the rest of the quarter is overkill.
There's a middle path, and it uses a concept from E2E testing that rarely gets applied to manual work: data-driven testing.
What data-driven testing actually means
In automated test frameworks, "data-driven" means: run the same test scenario with multiple rows of input, and let the data — not the code — vary what the form receives.
The principle works just as well for humans filling forms by hand. Instead of re-typing values from a spreadsheet, you build a dataset of test cases once, then replay each row through the form on demand. If a bug appears on row 7, you know exactly which values caused it. You can reproduce it in 10 seconds.
This is the pattern I want to walk through — no code, no selectors, no test runner required.
Step 1 — Build your dataset once
Start by writing your test cases as rows in a spreadsheet. Columns match the form's fields. One row = one test scenario.
For a typical signup form you might have:
| first_name | last_name | phone | account_type | |
|---|---|---|---|---|
| Maria | García | maria.garcia@example.com | +34 600 000 001 | premium |
| 张 | 伟 | zhang.wei@example.com | +86 138 0000 0001 | free |
| Edge | Case | edge+tag@example.com | +1 (555) 000-0000 | free |
| (blank) | (blank) | no-reply@example.com | (blank) | guest |
The + tag in the email is the kind of thing that breaks parsers. The blank-name row tests "required field" validation. These are cases you'd type by hand today — the goal is to type them once and replay them forever.
Step 2 — Capture the form
(Full disclosure: I built Fillr, the extension I use for this workflow — honest maker note. The concept works with any tool that supports form presets + CSV fill; this is just the one I know best.)
Install Fillr
(Chrome extension — free plan covers the full workflow below). Click Capture on your test form. Fillr detects every input and saves them as a preset: a named set of fields, each with a configurable rule.
You set a rule per field:
- Generate — produce a realistic random value each fill (good for fields you don't need to control)
- Fixed value — always use this exact string
- Blank — leave the field empty
- Skip — don't touch the field at all
- Dataset column — pull from a column of a linked dataset, row by row
For a controlled test run, the important fields get the Dataset column rule. Fields irrelevant to the test case (e.g., an optional "company" you don't care about for this suite) can just Generate.
Step 3 — Link the dataset
Import your CSV (or Excel / JSON) into Fillr's dataset editor. Map each column to the matching form field. That's the full configuration.
When you fill, Fillr shows a "row N of M" readout in the floating bar. Click fill → observe the result → advance to the next row → fill again. Sequential mode for reproducible regression passes; random mode for exploratory variety.
If row 7 triggers an unexpected validation message, your bug report includes the exact inputs: first name Edge, email edge+tag@example.com, row 7 of dataset "signup-smoke". No guesswork, no "I think I typed…".
Why this is different from random-fill extensions
Most form filler extensions give you realistic-looking generated data on demand. That's useful for "does this form submit at all?" checks. But generated data doesn't help when:
- Your form validates against a seeded backend (the test account must exist and match)
- You need to prove which input triggered a bug
- You're covering specific edge cases: unicode names, E.164 phone formats, email tags,over-length inputs, deliberate blank fields
Random data can't reproduce a test case. A dataset row can.
The distinction matters: a 1★ review of one popular filler puts it plainly — "cannot use custom set of test data." That's the whole gap this workflow fills.
The practical payoff
Once the preset + dataset is configured (~5 minutes for a typical form):
- Each regression pass is one click per row, advancing through a predefined list of cases
- The whole team can run the same dataset — not just the person who memorized which edge cases to type
- Any new bug you find becomes a permanent regression case: add a row to the dataset, no scripting required
The workflow scales naturally. When the form adds a new field, update that field's rule. When you find a new edge case, add a row. No selector maintenance, no fixture files, no
pipeline to wire up.
Feedback question
I built this because I kept chasing false bugs caused by mistyped test data during manual regression passes. Playwright was the right answer for the CI suite — wrong tool for a form that changes every week and needs a 10-minute smoke check.
Does this workflow match something you've run into? I'm especially curious: is a ~5-minute per-form setup reasonable, or does even that barrier keep people from leaving the spreadsheet-and-copy-paste habit?
Any other patterns you use for managing test data in manual / exploratory passes — I'd genuinely like to hear them.
The extension is free to try (unlimited presets, 120+ data types, 3 datasets):
Top comments (0)