Test data management (TDM) is the planned work on test data across the whole test process: clarify the need, specify the data, obtain it, provide it, protect it, and finally archive or delete it. The German Testing Board (GTB) syllabus “Test Data Specialist” splits this into 7 activities and 3 roles (GTB syllabus Test Data Specialist V1.1, 2021). Automated tests add a hard condition: the data has to be ready when the run starts, often at night with nobody watching. In banks and other regulated companies, the law decides which production data may sit in test environments.

TL;DR: Test data management plans, obtains, protects and maintains the data that tests need. The GTB Test Data Specialist syllabus (V1.1) describes 7 activities, from planning to archiving. Automated tests need data on demand and isolated per test. EU financial entities may store only anonymized, pseudonymized or randomized production data in non-production environments (EU DORA RTS Art. 16(5)).

Figure 1: Input, state, output and expected data in a test run

What is test data?

Test data is the data a test needs to run: inputs, records that already exist in the system, and the expected results. The official ISTQB glossary defines it in five words: “Data needed for test execution.” (ISTQB Glossary, 2026). The GTB syllabus is more precise: test data is the concrete values of data objects needed to execute a test object (translated; GTB syllabus TDS V1.1, 2021).

Abstract and concrete test cases differ in exactly these values. An abstract test case works with parameters as placeholders, such as “amount” or “account type”. Concrete values make it executable. Insert different values from the allowed range and, per the syllabus, one concrete test case turns into a series of test case variants. Data-driven testing is built on this idea.

The syllabus describes test data as realistic data that is not real data, and as inseparably tied to the test environments. A customer who exists in the integration environment may be missing from the acceptance environment. If you plan test data, you plan the environment with it.

What is test data management?

Test data management is, in the wording iSQI uses for the GTB exam, “the set of all methodological, conceptual, organizational and technical measures” for handling the resource test data (iSQI, 2026). The syllabus definition goes on to name the goal: bring test data into the test process with its maximum potential for use.

The ISTQB glossary V3.1 defines TDM more narrowly, as a process: “The process of analyzing test data requirements, designing test data structures, creating and maintaining test data.” The GTB syllabus quotes this version itself. The ISTQB version lists the tasks, and the GTB version adds organization and data protection.

What goes wrong without TDM? The syllabus calls “bad” test data missing, inaccurate, wrong, insufficiently encrypted, duplicated or late data, plus sensitive information copied unchanged from production. A 2025 GTB press release puts it in one line: without high-quality test data, even the best test case stays patchwork (translated; GTB press release, 2025).

What types of test data are there?

The GTB syllabus sorts test data along two axes: by how it is used in the test and by where it comes from. By use, it separates input data, state data, output data and expected data. By origin, it separates synthetic test data, production data, anonymized data, pseudonymized data and mixed forms (GTB syllabus TDS V1.1, 2021).

Figure 2: The four origins of test data plus the mixed form

Test data by use

Expected data is easy to forget. Without it, an automated test runs to the end and checks nothing. The GTB press release puts test data in three words: input, state, oracle (GTB press release, 2025).

Test data by origin

Used correctly, synthetic test data faces no regulatory obstacles, per the syllabus (translated). A vendor survey gives a rough idea of how common it is: in the World Quality Report 2025-26 by Capgemini, Sogeti and OpenText (2025 survey, more than 2,000 senior executives in 22 countries), the surveyed organizations generate an average of 25% of their test data synthetically (Sogeti, 2026).

How does the test data management process work?

The TDM process consists of 7 activities in the GTB syllabus, running from planning to archiving the test data (GTB syllabus TDS V1.1, 2021). It runs alongside the test process and feeds it data:

Figure 3: The 7 test data management activities in the GTB syllabus

1. Planning (TDM): set needs, effort, dates and owners. The output is the test data concept.

2. Control (TDM): track progress and step in when data is missing or late.

3. Specify test data: derive from the test cases which data is needed in which combination.

4. Design test data creation: choose the origin per data area: synthetic, production extract, anonymized, pseudonymized or mixed.

5. Provide test data: make the data available in the right environment at the right time.

6. Write the test data completion report: record which data was used and what stayed open.

7. Archive test data: keep the sets needed for retests or audit evidence.

The main output of planning is the test data concept (Testdatenkonzept), which the syllabus treats as a supplement or annex to the test plan (Testkonzept). The syllabus adds further work products, such as a test data policy and a provisioning plan.

Who is responsible for test data?

The GTB syllabus splits responsibility for test data across 3 roles: test data manager, test data modeler and test data implementer (GTB syllabus TDS V1.1, 2021).

• Test data manager (Testdatenmanager): plans and controls TDM in the project.

• Test data modeler (Testdatenmodellierer): analyzes test data requirements and specifies the data.

• Test data implementer (Testdatenrealisierer): works on the technical side and creates or provides the concrete test data.

The syllabus allows one person to hold all three roles (translated). Where no dedicated TDM roles exist, test managers and testers or developers take on these tasks. Each task still needs a named owner.

Next to the test team, the syllabus recommends involving data protection, legal and compliance. In a bank or insurer, the data protection office joins planning: whoever picks the data origin picks the data protection risk.

What do automated tests need from test data?

Automated tests need test data that is complete when the run starts, available without manual requests, and not changed by any other test. The GTB syllabus names stability as a core requirement for automated test runs and gives the reason: they often run unattended and/or at night (translated). At 2 a.m., nobody refills a used-up record.

Figure 4: Three principles for test data in test automation (based on dora.dev)

Scripts that create and provide data must match the test automation scripts in timing and content, and data sets no longer needed get deleted (GTB syllabus TDS V1.1, 2021).

Google's DORA research program (dora.dev) treats TDM as a capability of its own and sets 3 principles for it (dora.dev, 2026). This program has nothing to do with the EU DORA regulation.

• “Adequate test data is available to run full automated test suites.”

• “Test data for automated test suites can be acquired on demand.”

• “Test data does not limit or constrain the automated tests that teams can run.”

dora.dev recommends that tests create their own starting state through the application's APIs wherever possible. It calls isolated test data “a prerequisite for tests to run in parallel”. As common mistakes, it lists a full copy of the production database, no masking of sensitive data, and outdated data.

Deeper guides for each requirement:

• separate parameters from data rows so one test case covers many variants: data-driven testing step by step

• generate data with rules or statistics, and know when a masked copy fits better: how to generate test data and pick the right method

• disguise sensitive values without losing testability: data masking for test data

• give every test its own data so parallel runs don't collide: test data isolation checklist

• build data provisioning into the pipeline as a fixed step: test automation in the CI/CD pipeline

Which rules apply to test data in regulated industries?

Under Art. 16(5) of Delegated Regulation (EU) 2024/1774, EU financial entities must make sure that “non-production environments only store anonymised, pseudonymised, or randomised production data” (EUR-Lex, 2024). These regulatory technical standards specify the Digital Operational Resilience Act, Regulation (EU) 2022/2554, which applies from 17 January 2025. This is the EU regulation, not the dora.dev research program.

Art. 16(6) allows an exception: production data may sit in test environments only for specific testing occasions and for limited periods, with approval by the relevant function and reporting to the ICT risk management function. For a test team, the default is disguised production data. The exception needs an approval with an expiry date.

Rules and daily practice can drift apart. In a vendor survey by Perforce (2026, more than 500 enterprise leaders), 99% said they have data masking mandates, and 84% allow compliance exceptions to them (Perforce, 2026).

The GDPR applies across industries. Under Recital 26, pseudonymized data that can be linked back to a person with additional information “should be considered to be information on an identifiable natural person” (EUR-Lex, 2016). What that means for production data in testing is covered in our guide to GDPR-compliant test data.

In Switzerland, FINMA Circular 2023/1 requires banks and securities firms to separate development and test environments from the ICT production environment (FINMA Circular 2023/1, PDF in German, 2022). This circular does not cover insurers. The revised Federal Act on Data Protection has been in force since 1 September 2023 (Fedlex, 2023). Have your data protection office check which data is allowed in your test environment.

For banks, test automation for regulated banks covers the setup under these rules, and the test environment guide explains how to separate test, acceptance and production.

How do you measure test data management?

You can measure test data management with 4 metrics: time spent on test data, share of key data sets available, number of tests that run without extra data requests, and the test data coefficient. The first three come from Google's DORA research program (dora.dev, 2026), and the fourth from the GTB syllabus.

The syllabus treats the test data coefficient as a measure of data minimization. A low value points to data sets that cost storage and carry risk without serving any test. dora.dev points the same way and advises keeping the amount of data automated tests need small.

Where do you start?

1. Take stock: which environments hold which data, and where does it come from?

2. Specify the need: input, state and expected data for the most important test cases.

3. Choose the origin per data area and write it into the test data concept.

4. Automate provisioning in step with the test scripts.

5. Measure and clean up: track the four metrics, delete unused data sets.

Where does Autemos help with test data management, and where not?

Autemos is AI-assisted software for functional test automation across web, mobile, API and desktop. Autemos is not a data masking or test data generation tool. In the TDM process, Autemos supports the activity “provide test data” for automated test runs. It does not anonymize or pseudonymize production data, does not subset production databases, and does not give legal advice.

In Autemos, you create, edit or import datasets (CSV, XLSX, JSON) and reuse them across test workflows, for login users, product lists or test orders. You can connect external sources: REST APIs, JSON files, Excel, databases or the iSynth data source. Runtime bindings load the data only at runtime and pass it to the test as variables.

For parallel runs, the One-Time Use option flags used vouchers, registrations, tokens or test users so they are not handed out twice. Scopes at RUN, PROJECT or TENANT level set how widely a data set applies, and bindings can differ per environment (DEV, TEST, STAGING, PROD).

The Autemos test data handling page names the problem: used vouchers, duplicate users, expired tokens or empty datasets cause failures that have nothing to do with the application.

Frequently asked questions

What is the difference between test data and test data management?

Test data is the concrete values a test needs; TDM is the planning, sourcing, provisioning and maintenance of those values. The ISTQB glossary defines test data as “Data needed for test execution.”

Can you use production data for testing?

Production data in testing is possible only under conditions. The GTB syllabus calls a production extract problematic under data protection law, but not automatically prohibited. EU financial entities may keep only anonymized, pseudonymized or randomized production data in non-production environments (DORA RTS Art. 16(5)), with time-limited, approved exceptions under Art. 16(6).

Is pseudonymized test data still personal data?

Yes, pseudonymized test data stays personal data under GDPR Recital 26 as long as it can be linked back to a person with additional information. Only anonymous information falls outside data protection law. GDPR obligations keep applying, in the test environment too.

What is a test data concept?

A test data concept is the planning document of TDM, which the GTB syllabus treats as a supplement or annex to the test plan. It sets which data each test level needs, how the data is obtained and provided, who owns it, and how it is protected, archived or deleted.

Does a small team need dedicated TDM roles?

No, the GTB syllabus allows one person to hold all three TDM roles. Without dedicated roles, test managers and testers or developers take on the work. Each task still needs a named owner.

Conclusion

Test data management needs a plan before the first test runs. The GTB Test Data Specialist syllabus gives you the structure: 4 types by use, 4 origins plus a mixed form, 7 activities and 3 roles, written down in a test data concept. For automated tests, Google's DORA research program (dora.dev) adds 3 principles: enough data, on demand, without limits on the tests. EU financial entities must follow Art. 16(5) of the EU DORA RTS 2024/1774, and Swiss banks the environment separation in FINMA Circular 2023/1. Start with an inventory: which data sits where, where it came from, and which test uses it. If you want to see how datasets, runtime bindings and One-Time Use look in your own test runs, book a conversation with our team.