test-data-requirement-analysis

Test Data Requirements Analysis

Before test design or data generation, analyze entities, fields, relationships, states, roles, privacy, sources, lifecycle, initialization, and cleanup requirements, and output TDR-## data preparation requirements and blockers. It does not generate data, does not read production data, and does not replicate test-data-generation dataset plans.

When to Use

When you need to know which entities, fields, states, roles, and referential integrity a given test scenario requires.
When you need to identify gaps in schema, data sources, masking, isolation, lifecycle, cleanup, and environment prerequisites.
When data materials are incomplete and you need to provide a constrained requirements list that can be consumed by test design or data generation.

Not applicable to directly generating records, calling real data sources, replicating production data, writing complete test cases, or executing tests.

Output Format Options

Default output is Markdown; when the user requests tables, CSV, or JSON, retain the same evidence, status, impact, responsible role, and verification fields.
Do not write structured formats or static checklists as execution, pass, approval, or release evidence.

How to Use

First read this Skill's main Prompt, and provide the goal, scope, materials, environment, and existing evidence.
Execute according to the Prompt's input audit and output contract; when information is missing, deliver a bounded initial version.
For each finding, retain the source, evidence status, impact, responsible role, closure conditions, and verification method.

Working Approach

Read and follow prompts/test-data-requirement-analysis.md, and first perform the six-category input audit.
Map the scenario/test objective to the required entities, fields, relationships, states, roles, data sources, and environment.
Use TDR-## to record valid/invalid/boundary/combination conditions, privacy and cleanup requirements, blockers, and verification methods.
Distinguish facts, data preparation inferences, constraints to be confirmed, and Human/compliance decisions.
When information is insufficient, deliver constrained requirements, mark the reasons why generation or execution cannot proceed, and do not promise that data already exists.

Domain Execution Points

From scenario/risk, list the scenario → entity/state/relationship → values/boundaries → quantity basis → acquisition source/permissions → preparation/cleanup conditions matrix; this Skill analyzes requirements and does not generate or fetch data by default.
Data volume basis comes from concurrency/isolation/repetition count/consumption patterns; when the count is unknown, provide a formula and gaps; do not arbitrarily set 100 rows or equate session count with entity count.
When schema is missing, separate known business relationships from undefined fields/keys and propose minimal clarification; cross-entity state and foreign key requirements must be traceable, not merely a list of CSV file names.
For personal/restricted data, prioritize synthetic or licensed masked data, and record source restrictions, retention/cleanup, and acceptance oracle; mark authorization as BLOCKED when unknown, and do not write analysis recommendations as already prepared.

Core Constraints

Cover applicable entities/fields, referential integrity, valid/invalid/boundary/combination, states, roles, sources, masking, initialization, cleanup, and isolation.
Do not generate data, do not read or export real personal/production data, and do not connect to real data sources.
Do not invent fields, relationships, quantities, privacy rules, retention periods, environment permissions, or cleanup results.
TDR-## are preparation requirements and gaps, not proof that data has been created, is usable, is compliant, or has passed testing.
Only specify what data and evidence are needed subsequently; do not replace data generation, test design, or Human/compliance approval.

Reference Files

When calibrating domain results, correct controls, or evidence gaps, read the desensitized input, item-by-item expectations, and recalculation basis of references/domain-decision-example.md .
Must read before each output prompts/test-data-requirement-analysis.md。
During regression, read evals/eval.yaml and matching test cases; configuration does not prove that the data is ready.
Trigger validation uses evals/trigger-prompts.csv and evals/local-rules.json; when selection trace is missing, report BLOCKED。

Best Practices

Prioritize high-impact and verifiable gaps, and use minimal experiments or supplementary evidence actions to reduce uncertainty.
Separate facts, evidence-supported inferences, recommendations, and Human decisions to avoid escalating assumptions into conclusions.

Pre-delivery Self-check

Known facts, information gaps, conflicts, outdated information, out-of-scope items, and assumptions have been recorded.
Each TDR-## has scenario/objective, entity fields, relationships/states/roles, sources/constraints, and evidence.
Valid/invalid/boundary/combination, desensitization, initialization, isolation, and cleanup requirements have been separately specified (when applicable).
Blocking items have responsible roles, minimal supplementary evidence actions, and verification methods.
No records were generated, no production data was read, and requirements were not written as data already existing/tests already passing.

Common Misconceptions

Listing data values directly without explaining why the data is needed, how it is related, and how it is cleaned up.
Treating the existence of a schema as data availability, and treating a desensitization statement as compliance evidence.
Confusing data preparation requirements analysis with dataset generation.
Ignoring roles, states, relationship integrity, and environment isolation, and covering only field formats.