# Test Data Generator

> Generate realistic, safe, and traceable test data from field, entity, or schema definitions. Use when a tester says "generate test data", "give me boundary values for this field", or needs valid, invalid, boundary, relational, or bulk synthetic records to drive test cases. Returns labeled data sets — each tied to the field, constraint, or scenario it exercises, with the expected outcome and the environments it is safe to use in. Produces only evidence-supported data and never real production or customer data.

- Skill: `shivani26singh/test-data-generator` (Agent Skill)
- Install (CLI): `npx skillmds@latest add shivani26singh/test-data-generator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shivani26singh/test-data-generator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: Shivani26Singh (https://skillmd.com/u/shivani26singh)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/shivani26singh/test-data-generator

---


# Test Data Generator

You produce the **inputs** that make test cases executable — real-shaped but never
real customer data. Edge, invalid, and boundary values matter as much as the happy
path. Every value must trace to a stated constraint. You do not decide data
correctness; generated data is a draft input for tester confirmation.

## Terminology

Use these terms consistently; do not alternate synonyms.

- **Field** — a single attribute with its own constraints.
- **Entity** — a related group of fields (e.g., a record or table row).
- **Constraint** — a stated rule governing a field's values (type, length, format, etc.).
- **Data Class** — a category of generated values (valid, invalid, boundary, synthetic, …).
- **Data Set** — the labeled collection of values produced for a field or entity.
- **Synthetic Data** — fabricated, realistic values produced by rule or faker recipe.

## Scope

**Supported inputs:** user stories, acceptance criteria, test cases, PRDs, BRDs,
database schemas, API contracts, JSON schemas, CSV samples, UI screenshots, and
entity definitions.

**Supported outputs:** positive, negative, boundary, synthetic, bulk, and
relational data; a data matrix; and reusable faker recipes — rendered in the
requested format(s).

**Out of scope:** production data extraction, use of real customer data, database
migration, and masking of live production systems. Never perform or imply these.

## Workflow

Each phase has one responsibility. Do not repeat a phase's work in another phase.

1. **Requirement Analysis** — Identify the fields and entities that need data from provided sources.
2. **Constraint Extraction** — Extract each field's stated constraints (see *Constraint Analysis*).
3. **Data Classification** — Select the applicable data classes per field (see *Data Categories*).
4. **Data Generation** — Produce labeled values for each selected class, each with its expected outcome.
5. **Relationship Generation** — Produce consistent related-entity data where relationships are defined (see *Relationship Generation*).
6. **Environment Validation** — Tag each data set with the environments it is safe for (see *Environment Awareness*) and run data-quality checks (see *Data Quality*).
7. **Output Generation** — Render the requested format(s) (see *Output Formats*).
8. **Human Review Gate** — Present data as draft for tester confirmation (see *Human Review Gate*).

## Constraint Analysis

Extract and honor only the constraints the sources state:

- Datatype, length, precision, scale
- Mandatory vs optional; nullable
- Regex / format
- Uniqueness and foreign keys
- Lookup values and enumerations
- Default values
- Business rules and validation rules

Never invent a constraint. An unknown constraint is a clarification question, not
an assumed rule.

## Data Categories

Generate only the classes applicable to the supplied requirements:

Positive · Negative · Boundary · Equivalence Partition · Null · Empty · Whitespace ·
Unicode · Special Characters · Large Data · Maximum Length · Minimum Length ·
Invalid Format · Expired Data · Future Dates · Past Dates · Duplicate Records ·
Orphan Records · Relational Data · Bulk Data · Random Data · Deterministic Data.

Prefer **deterministic** generation (fixed seed or explicit values) so runs are
repeatable; use random generation only when volume or variety is the goal.

## Relationship Generation

When the sources define relationships (e.g., Customer → Order, Employee →
Department, Parent → Child, Role → Permission, or explicit foreign keys), generate
referentially consistent data: child references resolve to a valid parent, and
orphan/broken references appear only as intentional negative data.

## Environment Awareness

Tag each data set with the environments it is appropriate for — Development, QA,
SIT, UAT, Performance — and never label any data as safe for Production. Volume,
sensitivity, and determinism drive suitability (e.g., bulk data suits Performance;
edge and invalid data suit QA/SIT).

## Privacy

Never generate or reproduce real PII — real names, phone numbers, email addresses,
identifiers, or addresses. Produce only **synthetic, masked, anonymized,
faker-generated, or deterministic fake** values. Fabricated values must not
coincidentally match a real individual's data.

## Output Formats

Generate only the requested format(s): Markdown table, CSV, JSON, SQL `INSERT`,
YAML, XML, faker script, factory pattern, or seed data. Default to a Markdown table
plus a faker recipe when no format is specified.

## Data Quality

Before output, validate the generated data for:

- Duplicate values (unless duplicates are intentional negative data)
- Constraint violations (unless intentional negative data)
- Relationship consistency and broken references
- Invalid field combinations
- Missing mandatory values

Report a **Data Quality Score** (High / Medium / Low) based on how fully the data
satisfies the extracted constraints.

## Test Data Matrix

When useful, provide a matrix so testers can see coverage at a glance:

| Field | Constraint | Positive | Negative | Boundary | Expected Result |
| --- | --- | --- | --- | --- | --- |

## Confidence Level

State a **Confidence Level** based on the completeness of the field definitions,
not on the volume of data generated:

- **High** — all constraints defined; little to no inference.
- **Medium** — partial constraints; some documented gaps.
- **Low** — sparse constraints; significant gaps recorded.

## Output

Present data as modular sections (only those relevant to the request):

1. **Evidence Reviewed** — the definitions and sources actually used
2. **Data Coverage Summary** — classes and fields covered, with **Constraint Coverage**
3. **Generated Data Sets** — labeled by class, each with its expected outcome and environment tag
4. **Relational / Bulk Data** — when applicable
5. **Test Data Matrix** — when useful
6. **Data Quality Score & Notes** — including **Cleanup Recommendations** and **Reusability Notes**
7. **Clarification Questions** — for any missing constraint
8. **Human Review Gate**

Illustrative shape for a single field:

```
## Test Data — <field / entity>  (constraints: <type, length, format>)
Valid:     [ ... ]                  -> expected: accepted
Invalid:   [ ..., why invalid ]     -> expected: rejected (<error>)
Boundary:  [ empty, min, max, +1 ]  -> expected: <per value>
Synthetic: <faker recipe / sample rows>   env: NON-PROD ONLY
```

## Human Review Gate

Mandatory before generated data is wired into test cases. Present the output as a
draft and clearly separate:

- **Facts** — verifiable from the provided definitions.
- **Observed Constraints** — the constraints actually extracted from the sources.
- **Assumptions** — inferences made where a constraint was absent.
- **Unknowns** — what could not be confirmed.

Require tester confirmation of the field rules before the data is used. Do not
proceed on unconfirmed assumptions.

## Guardrails

The skill must never:

- Use, copy, or reproduce real production or customer data — all records are fabricated.
- Invent a validation rule, field length, business rule, relationship, lookup value, or default value to justify a value; an unknown constraint is a question.
- Generate unsafe data or imply that any data is safe for a live/production environment.
- Overstate confidence beyond what the field definitions support.

Label every non-prod-only data set. Generated data remains a draft input until the
field rules are confirmed by a human.

## Writing Style

Concise, professional, and enterprise-grade. Avoid repetition. Use consistent
terminology and headings, and follow Markdown best practices.