Realistic User Profile Generation Prompt for QA

This prompt is designed for QA engineers and developers who need to generate a diverse, consistent set of synthetic user profiles to power persona-based testing scenarios. The core job-to-be-done is to move beyond user1@test.com and create a population of users with realistic, interdependent attributes—demographics, preferences, account states, and behavioral traits—that match a specific target user model. This is essential for testing personalization engines, user segmentation logic, access control rules, and any feature where the user's profile state dictates application behavior.

Use this prompt when your test plan requires a controlled cohort of users that represent a specific persona or a mix of personas. You must provide a clear [PERSONA_DEFINITION] that outlines the target attributes (e.g., 'budget-conscious parent,' 'power user on a free tier,' 'international student'). The prompt is most effective when you also supply a [COUNT] and a [DIVERSITY_AXIS] to ensure coverage across key dimensions like age, subscription tier, or geographic region. Do not use this prompt for generating production data, for security fuzzing (use a negative test data prompt instead), or when you need schema-compliant database INSERT statements without the persona layer—that's a job for a schema-seeding prompt.

The output is a structured list of user profiles, each with a consistent internal logic. A profile for a 'budget-conscious parent' should have a free-tier account, high usage limits, and a history of viewing discount-related features. The prompt includes a self-validation step to check for internal contradictions and coverage across the requested diversity axes. Before integrating this into a test harness, you should define a programmatic validator that checks the output against your application's user schema and confirms that each generated profile's attributes (e.g., account_status, permissions) are valid enums within your system. For high-risk applications involving financial or health data, always route the generated profiles through a human review step to confirm the absence of unintended bias or unrealistic edge cases before they seed a shared testing environment.

The following prompt template is designed to be copied directly into your AI harness, test runner, or evaluation pipeline. It uses square-bracket placeholders for all dynamic inputs, ensuring you can programmatically inject target personas, output schemas, and coverage requirements without modifying the core instruction set. This template assumes you have already defined your target user model and simply need to generate profile instances that exercise it.

textCopy
You are a test data generation assistant for QA engineering. Your task is to generate realistic, internally consistent user profiles for persona-based testing.

## INPUT
[PERSONA_DEFINITION]

## OUTPUT_SCHEMA
Generate a JSON array of user profile objects. Each object must conform to this schema:
[OUTPUT_SCHEMA]

## CONSTRAINTS
- Generate exactly [PROFILE_COUNT] profiles.
- Every profile must be internally consistent (e.g., age aligns with life stage, income aligns with occupation, preferences align with stated demographics).
- Profiles must be diverse across the following dimensions: [DIVERSITY_DIMENSIONS].
- Do not use real names, addresses, emails, or phone numbers. Use synthetic but plausible values.
- If a field is marked as required in the schema, it must never be null or empty.
- Account state fields must match one of the valid states: [VALID_ACCOUNT_STATES].
- Behavioral attributes must be drawn from the allowed values: [BEHAVIORAL_ATTRIBUTE_OPTIONS].

## COVERAGE REQUIREMENTS
Ensure the generated set of profiles covers:
- At least [MIN_PERSONA_VARIANTS] distinct persona variants from the definition.
- At least one profile in each account state: [REQUIRED_ACCOUNT_STATES].
- Edge cases: [EDGE_CASE_DESCRIPTIONS].

## EXAMPLES
Here are examples of well-formed profiles that meet the schema and constraints:
[FEW_SHOT_EXAMPLES]

## OUTPUT FORMAT
Return ONLY a valid JSON array. No markdown fences, no commentary, no additional text.

To adapt this template for your specific testing context, replace each placeholder with concrete values. For [PERSONA_DEFINITION], provide a structured description of your target user model—this could be a narrative persona brief, a set of demographic ranges, or a behavioral segmentation table. For [OUTPUT_SCHEMA], supply a JSON Schema object defining the exact fields, types, and constraints each profile must satisfy. The [DIVERSITY_DIMENSIONS] placeholder should list the axes along which you need variation, such as age range, geographic region, subscription tier, or accessibility needs. If you do not need few-shot examples, replace [FEW_SHOT_EXAMPLES] with the instruction 'No examples provided; generate profiles from the persona definition alone.'

Before integrating this prompt into a test pipeline, validate that the output schema you provide is compatible with your downstream test harness. If your test runner expects profiles in a specific format—such as CSV rows, SQL INSERT statements, or API request payloads—either adjust the [OUTPUT_SCHEMA] to match or add a post-processing transformation step. Do not rely on the model to guess your ingestion format. For high-stakes testing environments where profile accuracy directly impacts defect detection, add a validation step that checks each generated profile against the schema, verifies internal consistency rules, and flags any profiles that fail coverage requirements before they enter your test suite.

This prompt is designed to be called programmatically, not used as a one-off chat interaction. The typical integration point is a test data factory or QA seeding script that needs a batch of synthetic user profiles matching a target persona model. The caller provides the persona specification, the number of profiles required, and the output schema. The prompt returns structured JSON that downstream systems consume directly. Because the output feeds test scenarios, the harness must validate every profile before it enters the test environment—a single malformed profile can break login flows, analytics queries, or personalization logic that depends on consistent user attributes.

Wire the prompt into your application with a generate-and-validate loop. First, construct the prompt by injecting the persona definition, diversity constraints, and output count into the template's [PERSONA_SPEC], [DIVERSITY_DIMENSIONS], and [PROFILE_COUNT] placeholders. Call the model with response_format set to JSON Schema mode if your provider supports it, or with a strong schema instruction in the system prompt. Parse the response and run each profile through a validator that checks: (1) all required fields are present and non-null where specified, (2) enumerated fields match allowed values, (3) demographic attributes are internally consistent (e.g., age range matches life-stage attributes), (4) no two profiles are identical beyond a configurable similarity threshold, and (5) the diversity coverage across the batch meets the requested distribution. If validation fails, retry with the error details appended to the prompt as [PREVIOUS_ERRORS] so the model can self-correct. After three failed retries, log the batch for human review rather than silently accepting degraded data.

For production test data pipelines, add observability and audit hooks. Log the prompt version, model used, generation timestamp, and validation pass/fail counts per batch. Store generated profiles with a generation ID so you can trace test failures back to the data that caused them. If your QA environment requires reproducible test data, seed the model call with a fixed random seed passed through the prompt's [SEED] placeholder. When the persona specification changes—new user segments, updated attribute ranges, additional diversity requirements—version the prompt template alongside the persona definition and run a regression suite of known-good profile batches to detect drift. Avoid calling this prompt synchronously in CI/CD pipelines where latency budgets are tight; instead, pre-generate profile batches asynchronously and store them in a test data repository that test suites pull from at runtime.