DEV Community: mohammed amine bousmaha

How to Stop Filling the Same Form Over and Over (Across Dev, Staging & Prod)

mohammed amine bousmaha — Mon, 29 Jun 2026 12:10:58 +0000

If your job involves a web form, you've done this: fill the signup form on localhost, fix a bug, fill it again on staging, retype every field, ship it, fill it one more time on production to confirm. Same form, same fields, three environments, twenty times a day.

The typing isn't the real cost. The real cost is that you do it inconsistently — slightly different data each time, a field skipped here, a typo there — so when something breaks you can't tell whether it was the code or the way you filled the form.

This guide is about killing that loop: filling the same form the same way, every time, across every environment, in one click.

Why this is harder than it should be

Browsers and password managers are built for one job: drop your personal details into one checkout. That's a single identity, filled occasionally.

Testing is the opposite shape:

Many fills, not one. You run the same form hundreds of times across a release.
Many environments. localhost:3000, staging.app.com, app.com — same form, different URLs.
Consistency matters more than realism. You need the same setup every run, or your results aren't comparable.

Built-in autofill solves none of these. So testers reach for a form filler — and most of them only solve the first half.

The usual tools — and where they stop

Random / fake-data fillers (Fake Filler popularized this; MockFill and FakerFill are newer takes) fill every field with one click. Great for a quick smoke test where any value will do. But the value is different every time and you can't save a per-form setup — so you can't reproduce a run, and you re-decide field-by-field behavior on every page. (Worth noting: the original Fake Filler hasn't been updated since August 2024.)

Save-and-restore extensions (Web Developer Form Filler and similar) remember what you typed and re-inject it on refresh. Closer — but the saved data is tied loosely to the page, breaks across environment URLs, and gives you no rules: every field is just a frozen string.

Macro recorders (iMacros and friends) replay a recorded sequence. Powerful, but brittle — the recording snaps the moment the form's markup shifts, and maintaining macros is its own job.

Each is fine for the slice it covers. None of them nails "the same controlled setup, auto-loaded on the right environment, every time."

The fix: capture the form once as a preset

This is how Fillr approaches it. Instead of filling fresh every time, you capture the form once:

Point Fillr at the form. It captures every field — inputs, selects, radios, the lot.
For each field you set a rule, once: Generate (realistic value), Fixed value (always this exact string), Blank, or Skip.
Save it as a preset.

Now that form has a saved identity. Email is always the same fixed test address. Signup date is always freshly generated. The internal-notes field is always skipped. Every fill is identical because the rules are identical — that's the consistency that makes a broken run mean something.

The part that matters across environments: URL matching

Here's the wedge no random filler has. Each preset stores URL match patterns — glob patterns like *.app.com/signup or localhost:*/signup.

So when you land on the signup form — whether it's localhost:3000/signup, staging.app.com/signup, or app.com/signup — Fillr recognizes the page and the right preset is already there. No picking it from a list. No re-uploading. One click fills it the same way it filled on the last environment.

That's the whole loop collapsed: same form across dev, staging, and prod = one preset, auto-matched, filled identically every time. You stop deciding how to fill and just fill.

Side-by-side: filling the same form repeatedly

	Browser autofill	Random fillers	Save-and-restore	Fillr (presets)
One-click fill	⚠️ per field	✅	✅	✅
Same setup every run	❌	❌ random	✅	✅
Per-field rules (fixed / generate / skip)	❌	⚠️ limited	❌	✅
Auto-loads on the right URL	⚠️ basic	❌	⚠️ fragile	✅ glob patterns
Works across dev / staging / prod	❌	⚠️ manual	⚠️ breaks on URL change	✅ one preset, many envs
Reproducible runs	❌	❌	⚠️	✅
Realistic generated data when you want it	❌	✅	❌	✅ 120+ types, 60+ languages
Data stays local / private	✅	✅ usually	✅ usually	✅

The gap every other column shares: nothing carries one controlled setup across multiple environment URLs. That's exactly the repetitive-testing case.

Walkthrough: set it up once, fill it forever

Using Fillr, end to end:

Install the extension and open the form you fill most — your signup, checkout, or admin form.
Capture it as a preset. Fillr grabs every field.
Set your rules. Fixed values for the things that must stay constant (test email, plan tier), Generate for the things that should vary realistically (names, dates), Skip for fields you never touch.
Check the URL pattern. Fillr suggests one automatically; widen it so it matches all your environments (e.g. *app.com/signup and localhost:*/signup).
Go fill. On any matching environment the preset loads itself. One click, identical fill, every time.

Set up once at the start of a feature. Spend the rest of the release clicking.

When the data itself needs to change each fill

Sometimes you don't want the same data — you want to march through a list of test cases (20 accounts, a batch of edge-case phone numbers). That's a dataset, not a single preset, and it's a related-but-separate workflow: see how to autofill forms with your own data. And if you're testing across markets, localized test data in 60+ languages covers filling with locale-correct names and addresses.

For the plain "same form, same setup, over and over" loop, a preset is all you need.

FAQ

How do I fill the same form repeatedly without retyping?
Capture it once as a preset with per-field rules, then fill in one click. Tools like Fillr save the setup so every fill is identical — unlike random fillers, which produce different values each time and save no configuration.

How do I test the same form across dev, staging, and production?
Use a form filler that matches forms by URL pattern. In Fillr, one preset stores glob patterns (e.g. *.app.com/signup, localhost:*/signup) so the same setup auto-loads on every environment and fills identically.

What's the difference between this and a random form filler?
A random filler drops any value in every field — good for a quick smoke test, useless when you need the same input twice. A preset saves a rule per field (fixed, generate, skip), so runs are reproducible and comparable across environments.

Can I still generate realistic data for some fields?
Yes. Set those fields to Generate — Fillr produces realistic values across 120+ data types and 60+ languages — while keeping others fixed or skipped. Mix per field.

Does it work on internal tools, admin panels, and localhost?
Yes — any web form, including staging and localhost. URL patterns match your environments and nothing is installed on the site itself.

Is my data private?
Your presets live in your own account, visible only to you. The extension stores no passwords or tokens, filling happens locally in your browser, and a form is only captured when you explicitly save it.

The short version

The waste in repetitive form testing isn't the typing — it's doing it differently every time across every environment. Fix that and the loop disappears: capture the form once, set a rule per field, let it match your dev, staging, and prod URLs, and fill the same way in one click forever.

That's what Fillr is built for. Add it to Chrome and turn your most-filled form into a one-click preset.

How to Fill Forms With Localized Test Data in 60+ Languages (Names, Addresses, Phones)

mohammed amine bousmaha — Fri, 26 Jun 2026 11:03:44 +0000

> Testing a multilingual app means filling forms with locale-correct names, addresses, and phone numbers — not English data with accents bolted on. Here's how to generate localized test data for any web form, in 60+ languages, without building a spreadsheet per market.

If you test a product that ships in more than one language, you already know the chore: every signup, checkout, and address form has to be filled with data that looks right for each market. A Japanese name in kanji. A German street address with the house number after the street. A French phone number that starts +33. A Brazilian name with a tilde in it.

English test data with a couple of accents pasted in doesn't catch the bugs. The bugs live in the real shapes — the field that truncates kanji, the validator that rejects a 9-digit local number, the address line that assumes a US ZIP. To find those, you need localized test data: values generated to each locale's actual conventions.

This guide is about getting that data into your forms quickly — without hand-building a spreadsheet for every language you support.

What "localized test data" actually means

It's not translation. It's data shaped to a region's real conventions. For a typical form, that's:

Names with the right script and characters — ü, ñ, é, kanji, Cyrillic, Arabic — not Latin names with a diacritic sprinkled on.
Addresses in the local format — street/number order, postal-code shape, and the fields a country actually uses.
Phone numbers with the correct country code and local grouping, not a US 10-digit pattern everywhere.
Dates, currency, and numbers that exercise each locale's separators and formats — the things that quietly break parsing and sorting.

The reason this matters: most internationalization (i18n) defects come from the shape of the input, not the translated label above it. A form that works fine with John Smith falls over on José Müller or 田中太郎. You only see it if you fill it with data that looks like that.

Why the usual ways are slow

Most teams reach for one of these, and each has a catch:

A spreadsheet per locale. Accurate, but you build and maintain one by hand for every market. It's the single biggest time sink in localization testing, and it goes stale.
Google Translate the English data. Translates words, not formats. You get translated text in a US address shape — which is exactly the case that hides the bug.
A random / fake-data filler. One click fills the form, but the data is English-only. Most random fillers (Fake Filler and similar) have no concept of locale, so they can't produce a kanji name or a +49 number at all.
A faker script in code. Libraries like Faker.js do generate locale-aware data — but you're writing and running code, exporting files, and pasting values into the browser by hand. It's not a fill-the-form-in-front-of-you workflow.

The gap is the same one every time: there's no quick way to drop locale-correct, realistic data straight into the form you're looking at, switch the language, and go again.

The faster way: pick a language and fill — no setup

This is what Fillr is built for, and the core of it takes no configuration at all.

Open the side panel, pick a language, click fill. On any form, open the Fillr side panel, choose your locale from the list — English, Japanese, German, French, Portuguese, Arabic, and 60+ in total — and hit fill. Every field gets realistic data generated for that locale: the name in the right script, the address in the local format, the phone with the right country code. No preset, no spreadsheet, no code. Switch the locale, fill again, and the same form is populated for the next market. That's the whole loop.

The generated values draw from 120+ data types — names, emails, street addresses, phone numbers, IBANs, company names, and more — each one locale-aware. So a full multilingual pass on a form is: pick a language, fill, switch, fill — a few clicks per market.

Want it the same way every time? Save a preset (optional). If you test a form often and want control over individual fields, capture it once as a preset. Then each field gets a rule — Generate a realistic value, use a Fixed value, leave it Blank, Skip it, or pull it from your own data — and the preset surfaces automatically next time you land on that page. This is for repeatability and per-field control; you don't need it just to fill in another language.

Need exact records? Drive it from your own rows (optional). Generated data covers "give me a realistic German address." When you need specific localized records — a known list of edge-case names, the exact Turkish phone format that broke production — import them as a dataset (CSV, Excel, or JSON), link it to a preset, and fill row by row. Sequential mode shows "row 3 of 20," so when a locale-specific bug appears you know precisely which record caused it. That's reproducibility, the thing a random filler can't give you.

Walkthrough: fill a form in another language, step by step

Install the extension and open the form you want to test — a signup, checkout, or address form.
Open the Fillr side panel and pick a locale — say, Japanese.
Click fill. The name fills in kanji, the address in Japanese format, the phone with +81. No preset needed.
Switch the locale to German and fill again. Same form, now populated for the German market.
Repeat for every language you ship. Each fill is one click with locale-correct data.

That's the whole flow. Two optional add-ons when you want more:

Save it as a preset if you test the form often and want a saved rule per field.
Import a dataset of your own localized rows and fill sequentially — with a "row N of M" readout so every submission is a known case.

Side-by-side: ways to get localized test data into a form

	Spreadsheet per locale	Google Translate	Random / fake fillers	Faker script	Fillr
Locale-correct names (scripts, diacritics)	✅ manual	⚠️ translated, wrong shape	❌ English only	✅	✅
Local address & phone formats	✅ manual	❌	❌	✅	✅
Fills the form in front of you	❌ copy-paste	❌ copy-paste	✅	❌ export first	✅
Switch language without rebuilding data	❌	❌	❌	⚠️ re-run code	✅ one click
Number of languages	however many you build	any (text only)	usually English	60+	60+
Fill from your own exact records	✅	❌	❌	⚠️ via code	✅ row by row
Reproducible ("which row was that?")	⚠️ manual	❌	❌	⚠️	✅ "row 3 of 20"
No code required	✅	✅	✅	❌	✅

No single built-in tool spans "locale-correct data," "drop it into this form," and "switch language in one click." That combination is the gap localization testers keep hitting.

FAQ

How do I generate test data in different languages?
Use a form filler with locale-aware generators. In Fillr, open the side panel, pick a locale, and click fill — every value (names, addresses, phones) comes out in that language's real format. No preset, spreadsheet, or code; switch the locale to change the whole fill.

What's the difference between localized test data and translated test data?
Translation changes the words. Localized test data changes the shape — the script a name uses, the order of an address, the country code on a phone, the separators in a number. Most i18n bugs come from shape, so translated English data in a US format usually misses them.

Can I test a form with non-Latin characters like kanji or Arabic?
Yes. Pick the matching locale (Japanese, Arabic, and 60+ others) and generated names and text come out in the correct script — the input you need to check that fields, validation, storage, and export all round-trip Unicode correctly.

Can I use my own localized records instead of generated data?
Yes. Import a CSV, Excel, or JSON file of your own rows as a dataset, link it to the form's preset, and fill row by row. Sequential mode shows "row N of M" so every locale-specific case is reproducible.

Do random form fillers support other languages?
Most don't — they fill with English data and have no locale setting, so they can't produce a kanji name or a non-US phone format. That's the main reason testers outgrow them for localization work.

Does it work on internal tools and staging sites?
Yes — any web form, including admin panels, internal apps, and localhost/staging. URL patterns match your environments, and nothing is installed on the site itself.

The short version

Localization testing breaks on the shape of the data, not the translation. To catch those bugs you need locale-correct names, addresses, and phone numbers in the actual form — and you need to switch languages without rebuilding a spreadsheet each time.

That's what Fillr gives you with no setup: open the side panel, pick one of 60+ languages, and click fill — realistic, locale-correct data dropped straight into the form. Save a preset or bring your own rows when you want per-field control and reproducibility. Add it to Chrome and fill your next form in any language in one click.

How to Autofill Forms With Your Own Data (CSV, Spreadsheets & Repeat Fills)

mohammed amine bousmaha — Wed, 24 Jun 2026 11:07:33 +0000

There are two completely different things people mean by "autofill forms with your own data."

The first is the everyday one: you want your name, address, and email to drop into a checkout without retyping them. Chrome already does this, and it does it well.

The second is the one almost no tool handles cleanly: you have a spreadsheet of data — 20 test accounts, 50 customer records, a list of edge-case phone numbers — and you need to push that data into a web form. Often the same form, over and over, one row at a time.

This guide covers both, but it spends most of its time on the second — because that's where the built-in tools fall apart and where people waste the most time.

What "your own data" actually means

Quick gut check, because it decides which method you need:

"My personal details" — one identity, reused everywhere. → Chrome's built-in autofill is the answer.
"A set of records I keep in a file" — many rows, many fields, used repeatedly. → You need a form filler that reads from your data, not a built-in profile.

If you're in the second group, skip ahead — but here's the fast version of the first.

Method 1: Chrome's built-in autofill (for personal info)

For your own contact and payment details, you don't need anything extra:

Open Chrome → Settings → Autofill and passwords.
Add or edit your address and payment info.
On any form, click a field and pick your saved profile.

This is great for you filling out your forms. Its limits show the moment your data lives outside that one profile:

One identity only. No second persona, no test accounts, no "fill with row 7."
It guesses fields by type — you can't say exactly what goes where.
It's built for real personal data, not the test data a developer or QA tester works with.

The same applies to password managers: one real identity, the wrong job for everything below.

Method 2: Random / fake-data fillers (when you don't care what the values are)

If you just need something in every field to test a form — any name, any email — a random filler does it in one click. Tools like Fake Filler popularized this, and it's genuinely useful for a quick smoke test.

But "random" is the catch. The whole point of your own data is that this specific value goes into the form — a real customer name, a known-bad IBAN, the exact phone format that broke production last week. A random filler can't give you that, and it can't reproduce the same input twice. (Worth noting: Fake Filler itself hasn't been updated since August 2024.)

Newer fillers like MockFill generate more realistic-looking data and detect field types well — but it's still generated data. There's no saved configuration per form, and no way to fill from a file you control.

So if the values matter, keep reading.

Method 3: Autofill a form from a CSV or spreadsheet

This is the request that sends people in circles: "I have a CSV — how do I get it into this web form?"

A handful of small extensions read a CSV and map columns to fields (search "CSV to form autofill" and you'll find several). They work, but most share the same rough edges:

You re-upload or re-map the file every session.
Mapping is fragile — rename a column and it breaks.
No saved per-field rules (some fields you want fixed, some generated, some left blank).
No clean way to walk through rows one at a time and know which row you're on.

For a one-off import that's fine. For a form you fill every day, the setup cost comes back every time.

Method 4: Presets + datasets — autofill with data you control

This is the approach built for the second meaning of "your own data," and it's how Fillr works. The idea is two pieces that click together:

Capture the form once as a preset. Point Fillr at any web form and it captures every field. For each field you set a rule once: Generate · Fixed value · Blank · Skip · Dataset column. Next time you land on that page, the right preset finds you automatically (it matches the URL) and one click fills the whole form exactly the way you set it up.

Drive it with your own dataset. Import a CSV, Excel, or JSON file — or build the rows by hand — and link it to the preset. Fillr maps your columns to the form's fields. Now each fill pulls a real row from your data:

Sequential mode walks row 1, row 2, row 3… with a visible "row 3 of 20" readout, so you always know exactly which record you just submitted.
Random mode picks a row at random when you want variety.

That row readout is the part that matters for anyone testing: when something breaks, you can say which row did it. That's reproducibility — the thing random fillers and built-in autofill can't give you.

Everything stays yours: presets and datasets live in your account, visible only to you. The extension stores no passwords or tokens, filling happens locally in your browser, and nothing is captured unless you explicitly save it.

Side-by-side: which method fits your data

	Chrome autofill	Random / fake fillers	CSV-only extensions	Fillr (presets + datasets)
Fills personal info	✅	⚠️ random only	⚠️ manual	✅
Fills from your own file (CSV/Excel/JSON)	❌	❌	✅	✅
Saves per-form setup (presets)	❌	❌	❌	✅
Per-field rules (fixed / generate / skip)	❌	⚠️ limited	⚠️ limited	✅
Fill same form repeatedly, row by row	❌	❌	⚠️ clunky	✅
Tells you which row was used	❌	❌	❌	✅ "row 3 of 20"
Realistic generated data when you want it	❌	✅	❌	✅ 120+ types, 60+ languages
Data stays local / private	✅	✅ usually	✅ usually	✅

No single built-in tool spans "fill from my file" and "save the setup" and "tell me which row." That combination is the gap.

Walkthrough: fill a form from your spreadsheet, step by step

Using Fillr as the example, start to finish:

Install the extension and open the form you fill often.
Capture it as a preset — Fillr grabs every field. Set a rule per field if you want (e.g. email = Fixed value, signup date = Generate, internal-notes = Skip).
Import your data as a dataset — drop in a CSV, Excel, or JSON file. Fillr reads your columns.
Link the dataset to the preset. Fillr auto-maps columns to fields by their names; fix any it couldn't match.
Pick a fill mode — sequential to march through every row, random to sample.
Click fill. The form populates from the next row, and you see "row N of M" so you know exactly where you are. Submit, click again, next row.

Set up once. After that, every fill is one click with the data you chose.

FAQ

How do I autofill a form from a CSV file?
Use a form filler that imports CSV and maps columns to fields. In Fillr: import the CSV as a dataset, link it to the form's preset, and each fill pulls one row. Your column headers auto-map to the matching fields.

How do I fill the same form repeatedly with different data each time?
You need a tool with a dataset and a row cursor, not a random filler. Fillr's sequential mode advances through your rows — row 1, row 2, row 3 — showing "row N of M" each time, so every submission uses a different, known record.

Can I autofill a form with realistic fake data instead of my own?
Yes. Set fields to Generate and Fillr produces realistic values — 120+ data types across 60+ languages — for any field you don't want to pull from your file. Mix and match: some fields from your data, some generated.

Is it safe to put my own data into a form filler?
With Fillr, your presets and datasets are stored in your own account and visible only to you. The extension keeps no passwords or tokens, filling runs locally in your browser, and a form is only captured when you explicitly save it.

Does Chrome's built-in autofill work for this?
Only for one set of personal details. It can't hold multiple records, fill from a file, or fill the same form with a different row each time. For test data or any multi-record workflow, you need a dedicated form filler.

The short version

Browser autofill is for your one personal identity. Random fillers are for "any value will do." But when the values matter — when you're filling the same form again and again with data you keep in a spreadsheet — you want control: a saved setup, a rule per field, and your own rows driving the fill, one knowable row at a time.

That's exactly what Fillr is built for. Add it to Chrome and fill your next form from your own data in one click.

Run data-driven manual tests on web forms without writing a single selector

mohammed amine bousmaha — Mon, 22 Jun 2026 10:30:19 +0000

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	email	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):

Stop Using "John Doe": A Better Way to Generate Test Data

mohammed amine bousmaha — Wed, 23 Jul 2025 08:56:30 +0000

Hey everyone,

Picture this: you've just pushed a small change to a user settings page. It's a simple fix, maybe a single line of CSS. Now, you need to test it.

You open the browser, navigate to the page, and are greeted by a form with ten fields: First Name, Last Name, Email, Password, Confirm Password, Address, City... you get the picture. You sigh, and begin the monotonous task of tabbing and typing.

We've all been there. This isn't the exciting part of development; it's the boring, repetitive grind that kills our momentum and drains our focus.

The Real Cost of Manual Form Filling
It's easy to dismiss this as "just part of the job," but the cost is higher than we think:

It's Incredibly Slow: The 60 seconds it takes to fill out that form, 20 times a day, adds up to hours of wasted time by the end of the week.

It's Error-Prone: Did you meet the password requirements? Is that a valid email format? Making a typo means starting all over again.

It Breaks Your Flow: The biggest cost is context switching. You go from a deep "code focus" state to a mindless "data entry" state, and getting back into the zone is hard.

It Makes for Poor Testing: When it's painful to fill out a form, we unconsciously avoid testing edge cases. We use the same simple data every time, leaving bugs undiscovered.

The Common "Solutions" (That Don't Really Work)
We try to fight back, of course. Maybe you use:

Browser Autofill: Great for your home address, but terrible for test data. It can't handle multiple test users (Admin, New User, User with long name, etc.) and offers zero randomization.

A notes.txt file: You keep a file with test user credentials. It's better than nothing, but it's messy, you have to copy/paste every field, and it's impossible to share with your team.

LastPass/1Password: These are password managers, not test data managers. They aren't built for generating varied, realistic data on the fly.

I was so frustrated with this cycle that I decided to build a proper solution for it.

Introducing a Better Workflow with Fillr
I created Fillr, a Chrome extension built specifically to solve this problem for developers and QA engineers.

It's a smart form filler that not only saves your form configurations but also generates high-quality, realistic test data for you.

Here’s how it transforms the workflow:

Stop Typing, Start Clicking

Instead of manually typing, you can save any form's configuration as a "Fillr". The next time you visit that page, you can populate the entire form with perfectly valid data in a single click.

Generate Realistic Test Data Instantly

This is the real game-changer. The power comes from the sheer variety of data available. We're not just talking about basic names and emails. Fillr supports over 100 different data types, giving you the ability to handle any testing scenario.

You can instantly generate everything from the essentials (company names, addresses, user bios) to highly specific and creative data sets like vehicle makes, airport codes, RGB colors, zodiac signs, and even Pokémon. This allows for truly robust testing of edge cases and complex validation rules without ever leaving the browser.

[Insert a GIF here showing the user scrolling through the impressive list of data types in the Fillr menu, perhaps highlighting a few unique ones like "Airport Code" or "Vehicle". This is your "wow" moment.]

Make Localization (i18n) Testing Trivial

If you've ever had to test an app for different countries, you know how painful it is to find valid addresses and phone numbers. Fillr has a built-in generator for country-specific data. Need a valid German address and phone number? It's two clicks away.

This workflow has personally saved me countless hours and, more importantly, saved my sanity. It keeps me in a state of flow and allows me to focus on what I actually enjoy: building and shipping features.

If you feel this pain too, I'd love for you to give Fillr a try. It's a new project, and I'm actively looking for feedback from the community on how to make it even better.

You can grab it from the Chrome Web Store and check out the landing page for more info.

➡️ Get Fillr on the Chrome Web Store
https://chromewebstore.google.com/detail/fillr-smart-form-filler-t/peppngdnnhjpchacodkdadojgnafepdd

➡️ Landing Page:
https://fillr.app/

Thanks for reading, and I hope this helps you reclaim some of your productivity!