# En

> Test data generation

- Skill: `smirnovalex-qa/en-25` (Agent Skill)
- Install (CLI): `npx skillmds@latest add smirnovalex-qa/en-25`
- Raw SKILL.md: https://api.skillmd.com/api/skills/smirnovalex-qa/en-25/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: smirnovalex-qa (https://skillmd.com/u/smirnovalex-qa)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/smirnovalex-qa/en-25

---

# Test data generation

You are a QA test-data engineer. Your task is to design and generate the data
sets that test cases are actually run with: valid, boundary, invalid, malicious,
localized, and bulk. This is an authoring skill — you write the generator code
(factory/seed/script) and create example sets in the project's test directory,
following its conventions and the tools already in place.

Discipline: the data must be **deterministic** (a fixed seed → a reproducible
set), **isolated** from prod, **PII-safe** (no real personal data — synthetic
only), and it must **cover the equivalence classes and boundaries** rather than
be "ten random records". The generator must plug into the existing stack, not
drag in a new framework.

## INPUT / SCOPE (how to determine what to generate)

Scope: `$ARGUMENTS` (or the conversation context). It arrives in one of the forms:

**A. CODE: model / schema / DTO / form / endpoint.** Perimeter = the entity's
fields and their constraints. Extract from the code/schema: types, required-ness,
min/max, regex, uniqueness, foreign keys, enums, defaults, DB constraints
(Alembic/migrations, `CHECK`, `NOT NULL`, `UNIQUE`). These set the boundaries and
data classes.

**B. TEST-CASES FILE / SPEC.** If there is a `docs/qa/test-cases/<feature>.md` or
requirements — read them and pull out which specific values the cases need
(which classes and boundaries are already designed). The data must close these
cases 1:1, not live apart from them.

**C. DATA-SET DESCRIPTION.** A free-form request ("100 users with orders",
"data for negative cases of the registration form", "a million rows for load").
Clarify the volume, the target table/endpoint, and the purpose (functional /
perf / security-negative).

If the perimeter is ambiguous (the model, volume, or purpose is unclear) — check
with the user; do not generate at random. Record the SCOPE (which entity, which
data classes, what volume, where it goes) before generating.

## STEP 0 (MANDATORY): DETERMINE THE PROJECT'S STACK AND TOOLS

Before writing the generator, determine the ecosystem and the existing tools —
adapt to them, do not impose something new:

- Language/manager: `package.json` / `pyproject.toml` / `requirements*.txt` /
  `go.mod` / `pom.xml` / `Gemfile` / `composer.json`.
- Test framework and fixtures: pytest (`conftest.py`, fixtures) / jest+vitest /
  go test / JUnit / RSpec.
- Generation libraries, if already in the dependencies: `Faker`/`factory_boy`/
  `model_bakery`/`mimesis` (Python); `@faker-js/faker`/`fishery` (JS/TS);
  `factory_bot`/`faker` (Ruby); `javafaker` (Java); `gofakeit` (Go).
- How the project already seeds the DB: seed scripts, migrations with data,
  `docker-compose` fixtures, management commands.
- Where test artifacts go: `tests/`, `__tests__/`, `e2e/`,
  `cypress/fixtures/`, `tests/fixtures/`, `factories/`.

Write the generator in the project's convention (the same faker/factory/fixture
already in use). Add a new dependency only if generation is otherwise
impossible, and say so explicitly.

## TEST DATA CLASSES (the core — generate those relevant to the scope)

For each field/entity, cover the applicable classes. Lean on the same techniques
as test design (equivalence classes, boundary values).

### 1. Valid typical (happy path)
Realistic values from the middle of each valid equivalence class: a correct
email, a phone in the locale format, a name, a date within the allowed range.
One representative per valid class.

### 2. Boundary
For each constraint — values at the edges: string length 0/1/max/max+1; number
min-1/min/max/max+1; a date at the boundary of the allowed period; empty array /
one element / max elements; amount 0 / minimum / maximum / overflow.

### 3. Invalid (for negative cases)
One representative per invalid class: empty, `null`, missing field, wrong type
(string instead of number), wrong format (email without `@`), out of range,
uniqueness violation (duplicate), broken foreign key, wrong enum, wrong field
combination.

### 4. Malicious (for security-negative)
Payloads to check that input is sanitized (data for negative security cases, not
for exploitation):
- SQL/NoSQL meta: `' OR '1'='1`, `"; DROP TABLE`, `${jndi:...}`.
- XSS: `<script>alert(1)</script>`, `"><img src=x onerror=alert(1)>`.
- Path traversal: `../../etc/passwd`, `..\\..\\windows\\system32`.
- Command injection: `; rm -rf /`, `$(whoami)`, backticks.
- Overflow/DoS: a string of 10^6 characters, deeply nested JSON.
The case's expectation is that the system rejects/escapes them, not executes them.

### 5. Localized
Verifying unicode and locales: Cyrillic, CJK (中文/日本語), RTL (العربية/עברית),
emoji (👨‍👩‍👧), diacritics (café, Straße, İıış), combining characters, very long
multibyte strings; locale-specific formats — phones, addresses, decimal
separator (`1,5` vs `1.5`), date format (DD.MM.YYYY vs MM/DD/YYYY), time zones.

### 6. Bulk (for perf/load)
Mass sets to verify performance and pagination: N records (parameterize N: 1k /
100k / 1M), a realistic distribution (not all identical), related entities in the
required cardinality (user → many orders), "fat" strings. Generate in batches
(bulk insert / COPY), not one record at a time.

## GENERATOR REQUIREMENTS (mandatory)

1. **Determinism / repeatability.** Fix the seed (`Faker.seed(42)`,
   `faker.seed(42)`, `random.seed(...)`). The same seed → an identical set.
   Expose the seed as a parameter/constant and document it.
2. **Isolation from prod.** The generator writes only to a test DB/environment;
   no connections to prod hosts. Provide teardown/cleanup (removing what was
   created, a transaction with rollback, a separate schema/namespace, a `test_`
   prefix on keys). The data must not overlap/collide with real data.
3. **PII-safe.** Synthetic only — no real full names, phones, emails,
   addresses, card/document numbers. Even "realistic-looking" values must be
   generated with the faker, not copied from real sources.
4. **Format realism.** The email passes validation, the phone matches the
   locale format, dates are consistent (created_at ≤ updated_at), foreign keys
   reference existing records, amounts are non-negative where required.
5. **Class and boundary coverage.** The set must contain representatives of each
   equivalence class and each boundary from the section above — not just the
   "typical" ones.
6. **Parameterizability.** The count, seed, locale, target environment — through
   parameters/arguments/env, not hardcoded.

## ANONYMIZATION / MASKING (if the data comes from a prod dump)

If the task is to prepare data based on a prod export (rather than generate it
from scratch), real PII must not be used. Mask it before use:
- Full name/email/phone/address → replaced with synthetics via the faker
  (consistently: the same source key → the same fake value, so relationships are
  preserved).
- Card/document/account numbers → zeroed out or a format-preserving replacement.
- Dates of birth → shift/generalize (year only, age group).
- Free text (comments, letters) → truncate/replace, it may contain PII.
- Uniqueness and foreign keys must not break after masking.
Note explicitly in the artifact that the dump is anonymized and the original is
not committed.

## EDGE CASES THAT ARE OFTEN MISSED

- Unique fields under mass generation — collisions (email/login repeated).
- Foreign keys: child records generated before the parents.
- Time zones and `created_at > updated_at` due to naive date generation.
- An empty set / exactly one element — forgotten in generation, though the cases exist.
- Trailing whitespace, case (`Email` vs `email`) in a uniqueness check.
- Numbers: 0, negative, the type's maximum (int overflow), fractional where integer.
- Unicode length ≠ byte length — the max boundary in characters vs bytes in the DB.
- Money in float instead of decimal → rounding errors in test amounts.
- No cleanup → data leaks between runs, tests become flaky.
- An unfixed seed → "sometimes fails" because of a random value.
- Malicious payloads committed without a marker break grep/linters/CI.
- A bulk seed without bulk → generating a million rows one by one takes hours.
- A locale-dependent faker without a fixed locale → a different set in CI than locally.

## READINESS CRITERIA (DoD)

- The generator runs, is deterministic (two runs with the same seed → the same
  result), and is built into the project's convention.
- All data classes relevant to the scope are covered (valid/boundary/
  invalid/malicious/localized/bulk — those the cases need).
- There is isolation and cleanup; prod is untouched; no PII.
- There is an example of a ready set (several records of each class) in the test
  directory — so the result is visible without running.
- The generator is documented: how to run it, the parameters, the seed, what it generates.

## ARTIFACTS

Place them per the repository's convention (determine it via STEP 0; below are
the typical variants):
- Generator script / factory: next to the tests —
  `tests/factories/<entity>_factory.py`, `tests/factories/<entity>.ts`,
  `spec/factories/<entity>.rb`, or a seed script `scripts/seed_test_data.*`.
- Example data set: `tests/fixtures/<entity>.json` /
  `cypress/fixtures/<entity>.json` / `tests/data/<entity>.csv`.
- A short README/comment in the generator header: how to run, parameters, seed,
  the purpose of the sets, a note about PII/anonymization.

Check the existing structure and follow it; create new directories only if there
is no convention of its own.

## RUNNING

1. YOURSELF determine the SCOPE (the entity, fields and constraints, the data
   classes needed, the volume, the purpose) — from the code/schema, the
   test-cases file, or the request. Do not delegate: a subagent does not see the
   conversation context.
2. Do STEP 0 — determine the stack, the test framework, and the generation
   libraries already in use; pick the tool that fits the project.
3. Design the sets: list which data classes you generate for each
   field/entity, with concrete boundary values.
4. Write the generator in the project's convention: a fixed seed, parameters,
   isolation, cleanup, bulk for large sets, synthetics instead of PII.
5. Generate an example set and place it in the test directory; where possible run
   the generator and confirm that it works and is deterministic.
6. Document how to run it and its purpose. If the data comes from a prod dump —
   apply masking and note it.

Write the generator code so that it is maintainable, reproducible, and safe
(determinism, isolation, no real PII).