Test Data

Why it matters

Data decides what a test can find. Tests run only with tidy records — "Test User", one order, a short address — prove the happy path and little else; defects wait in the empty field, the name with an apostrophe, the order delivered exactly 14 days ago. Data also decides whether a result can be trusted: a test that fails because a colleague changed a shared account, or passes because of a leftover record, wastes time and hides real problems.

Data carries legal risk too. A copy of production in a test environment exposes real customers’ personal data to everyone with test access, usually under weaker controls than production. In Saudi Arabia that is processing of personal data under the Personal Data Protection Law (PDPL).

Four kinds of test data

For each test condition, ask which data would show whether the behaviour is right. Four kinds cover most needs; a good test set mixes them on purpose, building on the lessons on positive and negative testing and on edge cases.

• Valid: data the system must accept and process — a registered customer, an in-stock product, an email such as sara.k@example.com.
• Invalid: data the system must refuse safely — an empty required field, a wrong format, an expired card, or a record in the wrong state, such as an order that is already cancelled.
• Boundary: values at the edges of what is allowed — the longest name, zero, the last day of a period. Boundary value analysis, in the test design module, chooses them precisely.
• Production-like: data that resembles real use in shape and volume — Arabic and Devanagari names, long addresses, a customer with hundreds of orders — without belonging to a real person.

Try it: Special Character Dataset Generator Try it: Unicode Dataset Generator

Where test data comes from

The first two sources below are synthetic: made-up data that describes no real person. Synthetic data is the default because you control every value, including boundaries, invalid values and rare states.

• Hand-made: a tester writes the few exact records a test needs in a spreadsheet, a fixture file or a seed script. Precise, but slow when you need volume.
• Generated: a tool or script creates records from rules, or the test creates them through the product’s API so they obey the business rules. Repeatable, from ten rows to a million.
• Masked production data: a production copy with names, ids, phone numbers, emails and addresses replaced, shuffled or removed, and the links between tables kept. Realistic — useful for a migration rehearsal, for example — but it needs an approved process.
• Production data as it is: real records. Not for test environments without a legal basis, approval and production-level protection.

Try it: Test Data Factory Try it: Fake User Generator Try it: Fake Customer Generator

Personal data: keep real people out of test systems

The PDPL, overseen by the Saudi Data and AI Authority (SDAIA), defines personal data broadly: any data that can identify a person directly or indirectly, such as a name, an identity number, an address or a phone number. Health data is among the categories classed as sensitive.

Masking does not automatically make data anonymous. Replace the names but keep the birth date, district and employer, and a record can still point to one person. Whether a masked set is still personal data is for your data protection officer or privacy team to decide; until they do, treat it as personal data.

• Use domains reserved by RFC 2606, such as example.com, for test emails, so no message reaches a real inbox.
• Pay only with the payment provider’s published test cards in its sandbox.
• Keep real personal data out of bug reports, screenshots, logs and AI tools; if you find some in a test system, report it and do not copy it.

Try it: Fake Email Generator Try it: Saudi Address Test Data

Test data management

Test data management (TDM) is how a team plans, provides, protects and maintains test data so that tests stay repeatable. A large organisation may have a dedicated role for it; on a small team it is a few habits:

• Plan: write the data of each test case as a state. "A valid customer" is not test data; "customer C-101 with one card order delivered three days ago" is.
• Provide: create data with scripts or generators kept in version control next to the tests, not by hand on execution day.
• Isolate: give each tester or parallel run its own records with unique ids, so tests do not change each other’s data.
• Keep it current: write dates relative to the run ("delivered today minus 14 days"); a fixed date stops testing the rule weeks later.
• Reset and retire: restore a known baseline between runs, and delete exports and copies you no longer need.

Try it: SQL Dataset Generator

Worked example: test data for a refund rule

Requirement: "Customers can request a refund within 14 days of delivery. Card payments are refunded to the card; cash-on-delivery orders to the customer’s wallet."

Before writing steps, the tester lists the data: valid rows for both refund routes, boundary rows on each side of day 14 with relative dates, invalid rows for a wrong state and a wrong owner, and one production-like row. One question goes to the product owner first: does "within 14 days" include day 14? The sheet assumes it does.

ID     Kind             Record (all synthetic)                      Expected
TD-01  valid            card order, delivered today-3, 240.00 SAR   refund to card
TD-02  valid            cash-on-delivery order, delivered today-5   refund to wallet
TD-03  boundary         card order, delivered today-14              refund accepted
TD-04  boundary         card order, delivered today-15              refund refused
TD-05  invalid state    order shipped, not yet delivered            no refund option
TD-06  invalid state    order already refunded                      refund refused
TD-07  invalid owner    order of C-102, opened by its id            access denied
TD-08  production-like  customer with 350 orders, Arabic full name  history pages load

Log in as C-101 for TD-01 to TD-07; TD-08 logs in as C-103.
All emails end in @example.com. Dates are relative to the run date.
Restore baseline "refunds-v3" before each run.

Try it: Arabic Test Data Generator

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• Personal Data Protection Law (English translation)Saudi Data & AI Authority (SDAIA) · 2023The Saudi law governing personal data — why test environments should use synthetic data rather than copies of real customer records.
• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021Templates and content for test documentation — test policy, strategy, plan, status and completion reports, incident reports.
• RFC 2606: Reserved Top Level DNS NamesIETF · 1999Reserves example.com, example.net, example.org and .test/.example for documentation and testing — the domains to use in fake data.