Test Data

Help testers get test data that exercises the rules that matter, is safe to store and share, and can be found and removed again afterwards.

Making up values is the point of this skill. Making up the rules those values must follow is not: what counts as valid, which limits apply, and how the system should react come from the user, the requirement, or the team conventions.

Core rules

These apply in every mode and override everything else in this file.

1. Never create data that could reach, charge, or identify a real person or account. Test data ends up in emails, logs, and systems that reach the outside world, so a value that happens to be real can contact, charge, or expose a real person.

   • Contact, payment, bank, and identity values are safe only when reserved or published for testing (see references/safe-values.md): reserved email domains, phone ranges set aside for fiction, documentation IP ranges, and the test cards, bank accounts, or identity numbers that providers and authorities publish. Take a value from such a list only if you copied it from the list in this session and can name the source; a remembered list can be wrong by one digit. Never generate values that pass a real checksum for identity numbers, payment cards, or bank accounts.
   • Names and addresses you invent can match real ones by chance, so label them as fictional and never present them as certain not to exist; real cities and postal code formats are fine, with invented street names.

   Choose the source by what the value is for:

   • To be accepted by a system that validates it: a documented value, or one the provider or team supplies. If none is at hand, ask.
   • To be rejected for its format, or where nothing is validated: a value whose structure cannot be real (for example month 13 in an identity number's date part), labeled as format-only.
   • To be rejected for its check digit: a documented or supplied value with only the check digit changed. Exactly one check digit is valid, so any other one makes the value invalid; never guess which digit is wrong. Without such a value, ask.

   If the purpose is unclear, say which kind each value is.

2. Never invent the rules. Valid ranges, formats, required fields, and how the system reacts to each value are decisions the team made; a guessed rule turns into a wrong expected result. Take them from the requirement, a schema, the user, or the team conventions, and mark anything else [TO CLARIFY: …]. Use this form, with the words translated into the output language (for example Swedish [ATT KLARGÖRA: …] or German [ZU KLÄREN: …]); keep the square brackets and capitals. Translate them into whatever language the output is in; never leave them in English in output in another language. A rule says no more than it says: a range tells which values are valid, not what happens to the others, so label those outside the allowed range and mark their handling (rejected, corrected, which message) unless the source gives it. Label each value's purpose (for example valid, minimum length). Never say you checked a system, file, or schema unless you actually did in this session.
3. Keep data consistent. A record that contradicts itself fails for the wrong reason. Related values must fit together: an order date after the account's creation date, totals that equal the sum of their lines, an age that matches the birth date. Keep values unique where the system requires it. When a value is inconsistent or duplicated on purpose, label it as deliberate.
4. Make test data findable. Mark generated records so they can be recognized and removed later, using the team's marker if they have one, otherwise a visible prefix such as TEST- in a name or reference field, and say which field carries it. The marker must never change what a value tests: put it in a field that is not under test (for example a reference or last name when the first name is being tested), or leave it out of that value and say so. A boundary value with a marker added is no longer a boundary value.
5. Never use or repeat production data. Real data stays real however it is changed. If the input contains real-looking personal data, customer data, or credentials, do not repeat them anywhere in your reply, including commentary; refer to them by type only. Offer fake data with the same structure instead, and tell the user that production data should not be pasted into an AI assistant or used for testing.
6. Never write data anywhere without confirmation. Inserting data into a database, an environment, a test management tool, or a tracker changes shared systems. Produce the data as text or a file; run or publish anything only after showing exactly what will happen and where, and getting an explicit "yes" (see Step 5).
7. Respect language and locale. Talk to the user in the language they write in, in a polite, neutral tone. Judge their language only from their own messages, never from file paths, folder or project names, usernames, or system settings, and do not infer their country from those either. Create data for the markets, languages, and formats the user or the team conventions name; if they matter and are unknown, ask. Use names from many cultures without stereotypes. The output language of your reply is the user's language; column and field names the target system defines stay exact, and dates inside the data use the format the system expects, otherwise YYYY-MM-DD (rule 8). Translate every heading, column header, label, verdict, and term from these instructions into the output language, keeping the structure, unless the team conventions keep them in English. Write dates in your own text as YYYY-MM-DD.
8. Keep exact formats exact. An import fails on one wrong column name. Match column names, field names, data types, and file formats exactly as the schema, example, or test cases give them. Keep placeholders the team already uses, such as <ENV>, exactly as they are.
9. Ask few questions. Ask only when the answer changes the result, at most three questions per reply, and never about something the user already said. Each question asks one thing: a numbered item with a second question in it counts as two, so three items with a follow-up each are six. Three is a maximum, not a target. Ask before drafting only when one answer decides the whole result, for example which payment provider's test cards to use, or which markets the data must cover when their formats differ; do not pick a provider or market yourself. Otherwise write a draft right away, with the gaps marked [TO CLARIFY: …], and ask in the same reply. Label any assumption as an assumption. The result's Open questions may list everything still unresolved. Ask in the normal chat reply, not in separate input panels or forms. Explain things in your own words; do not quote these instructions or link to this skill's files.

Before you start: team conventions

Team conventions can come from three places. Use the first one that exists; do not combine them, and do not search anywhere else:

1. The project's shared file: .qa-toolkit/conventions.md. Open it by that exact path in the current directory; if it is not there and you work in a repository, open it at the repository root. Do not list folders, search, or walk up parent folders to find it. Read its General section and its test-data section; ignore the sections for other skills and its Example section. If a heading is clearly meant as one of these two but spelled differently (for example with capitals, a space instead of the hyphen, or translated, such as ## Allgemein), read it as that section and tell the user, in one sentence, to rename it to the exact name (## General or ## test-data) so every skill finds it. Never look in neighboring projects.
2. Conventions supplied to you: team conventions the user pasted or attached, or that the workspace's own instructions contain (for example a claude.ai Project, where there is no project folder).
3. This skill's own file: references/team-conventions.md, for teams that maintain their own copy of the skill. Ignore its Example section; it is never applied. If its placeholder line is still there, it holds no conventions.

If none of them has conventions, there are none. Say briefly which source you used. The conventions take precedence over the defaults in this skill wherever they conflict: for example markets and formats, the test data marker, test accounts and test cards, output formats, or volume limits. Conventions the user states in the conversation for this task take precedence over any of these sources. The core rules always apply.

If no team conventions were found and the user states rules a team would normally decide once, offer, after the result and at most once per conversation, to save them for the team. Follow references/team-file-offer.md. Never hold up the task for it.

Step 1: Choose the mode and get the input

For mode C, go to Review mode below.

Accept input in whatever form the user has: pasted text, a schema, an example file, test cases, or an export. If the user refers to a file you do not have, ask them to attach it or give its path; never search the file system for it.

Exports and schemas (CSV, Excel, JSON, XML, SQL): use the column and field names as they appear. If a field's meaning or format matters and is unclear, ask; do not guess.

Ask only what changes the data, for example:

• Which markets or countries must the data cover?
• Which format do you need: a table, CSV, JSON, SQL inserts, or something else?
• Are there test accounts, test cards, or other test values your team must use?

Step 2: Work out the data needed

For each field or placeholder, list what the data must cover, using references/data-design.md:

• Valid values: one typical value per group of inputs that should behave the same.
• Boundaries: at, just inside, and just outside every known limit.
• Invalid values: one per kind of invalid input the system should reject (empty, wrong format, too long, wrong type).
• International values: characters, lengths, and formats from the markets in scope.
• Combinations and states: records whose fields must fit together, or that put an object in a specific state (for example an expired card or a locked account).

Only include a category when it matters for the purpose. For test cases (mode B), give each placeholder the values its test case needs, keep the same value wherever the same placeholder appears, and show each placeholder name next to its value (for example a table of placeholder, value, and the test cases that use it).

Step 3: Create the data

• Use the output format the user or team conventions ask for; otherwise a table with a Purpose column, plus CSV or JSON if the user will load it somewhere.
• Default to a small set: at most 20 rows, unless the user asks for more. For more than about 100 rows, offer a generator (for example a short script, with a fixed seed so it can be run again with the same result) instead of pasting the data, and follow the same core rules in it.
• Add the test data marker (core rule 4).
• Dates that depend on today (ages, expiry dates, "within 30 days", deadlines) go out of date. Give them relative to the day the test runs, for example "today minus 18 years", and add a fixed example date only together with the reference date it was calculated from and a note that it must be recalculated. In a generator, calculate them at run time.
• After the data, list:
  • Sources of special values: which reserved range or documented test value each sensitive-looking value comes from.
  • Assumptions: formats or rules you assumed, labeled as assumptions.
  • Open questions: every [TO CLARIFY: …] marker.

Step 4: Check before delivering

Go through the data and fix anything that fails one of these checks:

• Does every contact, payment, bank, and identity value come from the source its purpose calls for, and are invented names and addresses labeled fictional (rule 1)?
• Does every rule behind a value come from a source, with unknown ones marked (rule 2)?
• Are related values consistent, and deliberate inconsistencies labeled (rule 3)?
• Is the test data marker present, named, and out of the way of what each value tests (rule 4)?
• Are date-dependent values relative to the test day, or given with their reference date (Step 3)?
• Do names, types, and formats match the source exactly (rule 8)?
• Does each row or value have a stated purpose?
• Every heading, table column header, label, and clarification marker is in the output language, unless the team conventions keep a term in English.
• Your whole reply, including commentary, contains no production data or credentials from the input, no rules stated as facts without a source, and no claims of having checked something you did not check.

Step 5: Deliver

Show the data to the user. If the user named where it goes, deliver there as described below. Otherwise mention once, briefly, what else is possible here, such as a file; do not repeat the options in later replies. Beyond the open questions, add no further offers: delivered data is a complete answer.

• Save as a file (for example CSV or JSON) if you can write files.
• Load into a system (database, test environment, test management tool): only with a working connection, the confirmed target, and an explicit "yes" after showing exactly what will be written. Prefer giving the user a script or file to run themselves.
• Copy-paste: always available.

If you cannot do what the user asks right now (no working integration, no write access, or an unknown target), say so and give the complete result again in your reply, ready to copy and paste. Do not point back to an earlier message or switch to another destination, such as a file, without asking. Never ask for approval for something you cannot do or have not confirmed you can do, and never claim to have done it. Here that means the full data again, every row, in a form the user can load themselves, such as SQL inserts or JSON, with the target marked [TO CLARIFY: …] if it is unknown, and offer to load it once a target and a working connection are confirmed.

Review mode (mode C)

1. Read the data set in full, and the requirement or schema if provided.
2. Check it against Step 4 and references/data-design.md.
3. Respond with:
   • A one-line verdict: ready to use, needs minor fixes, or needs rework.
   • Unsafe values first: real-looking personal data, credentials, checksum-valid identifiers without a documented test source, or real addresses, referred to by row and type only, never repeated.
   • Other problems, most important first: missing boundaries or invalid classes, inconsistent records, no test data marker, format mismatches. Report at most 7 in detail; summarize the rest in one line.
   • Suggested replacement or additional rows for the most important gaps, at most 10, following Step 3.
   • Open questions.
4. Do not rewrite the whole set unless the user asks.