| name | designing-test-data |
| description | Designs realistic, boundary-heavy, and role-aware test data packs for manual and automated testing. Use when a feature needs deliberate inputs and fixtures before execution, when edge-case values keep being improvised, or when automation needs stable example data with setup notes. |
| argument-hint | Entities, fields, constraints, roles, state combinations, and whether data is for manual or automated use |
| user-invocable | true |
Designing Test Data
Use this skill when the team needs better inputs, not just more tests.
It helps turn vague "use some sample data" habits into deliberate datasets that exercise happy paths, failures, boundaries, and real workflow states.
When to Use
- prepare test data before manual execution starts
- create stable fixtures for automation work
- design edge-case inputs from field constraints
- generate role-aware or state-aware data combinations
- replace improvised sample values with a reusable data catalog
Data Design Rules
- Derive from constraints, not vibes - lengths, formats, ranges, relationships, and states drive good data.
- Happy path is not enough - pair realistic valid data with deliberate invalid and awkward values.
- Synthetic first - use safe, non-sensitive values unless the user explicitly provides approved test data.
- Dependencies must be visible - if a dataset requires setup, state it clearly.
- Time and state matter - dates, expirations, roles, and lifecycle states often create the real edge cases.
Workflow
Phase 0: Frame the target
Clarify the data goal:
- manual execution support
- automation fixture design
- boundary testing
- negative validation
- role or state combinations
Identify the core entities involved.
Phase 1: Map the constraints
For each entity or field, capture what matters:
- required vs optional
- type and format
- minimum, maximum, and off-by-one limits
- allowed values or enums
- uniqueness or relationship rules
- lifecycle state or permission dependencies
If constraints are not fully known, list assumptions instead of fabricating precision.
Phase 2: Build the data categories
Generate values across these buckets where relevant:
- Typical valid data - realistic and reusable
- Boundary values - min, max, zero, empty, whitespace, off-by-one
- Invalid format data - malformed, wrong type, disallowed characters
- Role and state combinations - guest, user, admin, active, suspended, expired, pending
- Temporal data - past, future, leap day, expiry edge, timezone-sensitive values
- Stress or awkward data - long strings, Unicode, duplicate keys, near-collision values
Phase 3: Package the dataset
Use ./resources/test-data-catalog-template.md when possible.
The output should make clear:
- what the record is for
- how to use it
- any setup dependencies
- whether it is better suited for manual or automated use
Phase 4: Add handling notes
Before finishing, call out:
- seeding requirements
- cleanup expectations
- masking or privacy concerns
- values that should never be used outside safe test environments
Common Failure Modes
- only generating happy-path data
- ignoring entity relationships or setup dependencies
- using realistic-looking but sensitive data carelessly
- forgetting state or role permutations
- writing data tables with no explanation of why each set exists
Resource Map
./resources/test-data-catalog-template.md - structure for grouped test data packs and setup notes
Related Skills
designing-functional-tests - when the data pack should map directly to scenarios or casesapi-playwright-test-developer - when the dataset needs to become automation fixtures or API payloadsreporting-bugs - when broken data handling should be captured as a defectverifying-acceptance-criteria - when data assumptions affect readiness verdicts
Definition of Done
This skill is complete when:
- core entities and constraints are visible
- data is grouped by purpose rather than dumped randomly
- edge cases are included intentionally
- dependencies and cleanup notes are explicit
- the final dataset is ready for real QA use
