Stop 02 · Manual Testing FundamentalsTopics · 9/11

Test Data Preparation

In short

Testing with 'test' and 'abc123' finds almost nothing. Realistic, varied test data is what turns an okay test into one that catches real bugs.

Setting up the specific data needed to execute a test case realistically — valid data, invalid data, edge-case data, and enough volume to catch performance-related issues where relevant.

The purple blob drives a small car over a speed breaker on a practice track with cones.

Think of it like this

A proper driving test track

A driving test on an empty straight road proves nothing. A real track has a slope, a speed breaker, a tight turn and a pothole. Good test data is that track: normal cases plus every awkward one.

Watch it happen

Test data for a mobile number field

9876543210

+919876543210

98765

98765abcde

98765 43210

0000000000

1/5Valid: a normal 10-digit number. This should save without fuss.

The big ideas

What you need to know

Valid, invalid, edge

Every field needs normal values, wrong values and values right at the limits.

Never use real customer data

Copying production data into test servers can break privacy laws. Use fake or masked data.

Volume matters too

A list page that works with 5 items may crawl with 50,000. Some tests need lots of rows.

Make it repeatable

Scripts or seed files that rebuild the same data mean tests behave the same every run.

See it in code

Walk through the code

python

1from faker import Faker2 3fake = Faker("en_IN")4Faker.seed(42)  # same fake data on every run5 6users = [7    {"name": fake.name(), "email": fake.email(), "phone": fake.phone_number()}8    for _ in range(50)9]10edge_cases = [{"name": "", "email": "no-at-sign", "phone": "12"}]

1/3The en_IN locale gives Indian-style names. Seeding makes the output repeatable.

Faker makes realistic Indian names, emails and numbers. Add your own edge cases on top.

Save yourself the pain

Common mistakes

Oops

Copying real customer data into the test environment.

Do this instead

Generate fake data or mask real data first. Test servers are rarely as protected as production.

Oops

Using the same one test user for every test.

Do this instead

Use separate data per scenario so tests don't change each other's results.

Your mission

Make a test data sheet

~25 min

Quick check

Why is copying production customer data into a test server risky?

Go deeper

1Prepare 3 categories of test data (valid, invalid, edge case) for a sample form.
2Learn why using unrealistic or insufficient test data can hide real bugs.
3Understand data privacy considerations when using production-like data in test environments.