QA Data Seeder

Analyze how a feature is implemented, design a balanced dataset that covers every category QA needs, and populate it into a target environment so the feature can be tested manually or by automation.

Critical Constraints

• Never seed production. Confirm the target environment is a test/dev/staging one before writing any data. If in doubt, stop and ask.
• Never produce broken data. Every seeded record must pass the application's own validation. Edge cases are extreme-but-valid values, not corrupt ones. Malformed input belongs in negative tests executed live, never in persisted seed data.
• Balance the dataset: at least 70% regular (expected) data, at most 30% edge cases.
• Do not seed until the user approves the categories and the exact item count (Step 3 gate).
• Credentials, tokens, and connection strings come from env vars or user input — never hardcode them.
• Prefer the project's existing seeding mechanisms (factories, seed scripts, fixtures, admin console) or REST API or MCP. Write seed script in language of application.
• Generated artifacts (dataset plans, one-off seed scripts) go into the gitignored .testeiya/seed-data/ — add .testeiya/ to .gitignore if missing.
• Mark every seeded record with one recognizable marker (in a name, note, or tag field the schema allows) so QA can find the data and clean it up later. Use the same marker for the whole run.

Workflow

Step 1: Understand the feature