Skip to content

Data Driven Testing

Data Driven Testing

What is Data Driven Testing?

Data Driven Testing (DDT) is a test method in which test cases are executed with different test data. Instead of creating a separate test case for each data combination, DDT uses generic test logic. This runs through identical test steps with different values.

The specific values for inputs and expected results are stored in a data table. Each row in the table corresponds to a test characteristic. This allows tests to be scaled efficiently, test coverage to be increased and redundancies to be avoided. New data combinations are quickly added or updated. Especially in test automation, DDT enables simple and flexible mapping of different scenarios.

Challenges in managing and using test data

Working with test data is associated with various problems, including data management, availability and quality.

Test data management and maintenance

Creating and updating test data is complex. To ensure reliable tests, data must always be up-to-date and representative of real use cases.

Dependencies between data

Some tests require specific combinations of data to generate certain states. If these dependencies are not carefully managed, inconsistent data can lead to delays or instability.

Data quality

Only high-quality test data provides meaningful test results. Incomplete or incorrect data can lead to real errors being overlooked or false error messages being generated.

Specifications for test automation

Test data should be defined independently of the test code so that changes can be made flexibly. Temporary test data that is only required for one test case must also be managed properly.

Let’s find a solution together!

The advantages of Data Driven Testing

If the behaviour of a system varies with the same processes when using different data, then Data Driven Testing has a number of advantages:

  • Higher test coverage – Separating test logic and test data allows many input values to be tested with the same test sequence. This allows different scenarios to be covered, including limit values and special cases.
  • Less maintenance – Changes to the test data do not require any adjustments to the test procedure. New data sets can be easily added or updated without changing the test automation.
  • Better error analysis – As each test run is logged with different data, error-prone values can be quickly identified. This makes it easier to analyse the cause and rectify errors in a targeted manner.
  • Avoidance of redundant tests – A targeted selection of data combinations (e.g. via equivalence classes) avoids unnecessary repetitions. This saves time and reduces unnecessary complexity.
  • More efficient test design – Centralised management of test data facilitates its reuse. Instead of defining values multiple times, structured data records can be used specifically for tests.

Data Driven Testing is particularly effective when many data combinations need to be tested or test cases are reused. For data driven applications in particular, DDT reduces manual effort, improves test coverage and increases efficiency.

If test cases are heavily dependent on external test data, DDT enables simple management and scaling. The preparation of test data for inputs or special compilations, such as waybills or insurance forms, simplifies both specification and test execution.

Data Driven Testing is particularly powerful in combination with Keyword Driven Testing.

How does Data Driven Testing work with TestBench?

TestBench manages test data in a structured and contextualised way. To make this possible, data is stored in separate data types. This structure improves management and makes it easier to access the required values.

Step 1

Tests in TestBench enthalten standardmäßig eine Datentabelle, in der die zugehörigen Werte der Testfälle abgelegt sind. In der Testdefinition legt einen Parametertabelle fest, welche Datentypen in der Datentabelle benötigt werden.

TestBench parameter mapping table displaying four data types linked to parameter names: vehicle name (vehicle), special model name (special model), add-on name (add-on list), and price (total price). Icons represent the data structure or parameter usage type.
Step 2

The data table contains the specific values of the data types that were defined in the parameter table. Each row contains the data for a test case that is used during test execution.

TestBench data table showing combinations of vehicles, special models, add-ons, and total prices. Entries include vehicles like Rolo, Rassant, Rassant Family, and I5 with associated special models such as Jazz, Gomera, and Luxus, and detailed add-on lists. Prices range from 12,300.0 to 29,000.0.
Step 3

The values from the defined steps are used in the definition of the test case (see Keyword Driven Testing).

How is the test data managed?

TestBench table showing a list of representative values for a parameter, including vehicle names: Rolo, Minigolf, Rassant, Rassant Family, and I5.

The data types manage values as representatives of the same functional type, e.g. vehicle names or special model names in the example above.

When managing the values, groups of values can be created that belong to the same context. For example, the list of valid vehicles and the list of invalid vehicles for e.g. negative tests. The underlying method is called equivalence class decomposition.

Data Driven Testing and Keyword Driven Testing are integrated in TestBench, as also provided for in ISO 29119-5. Details on Keyword Driven Testing can be found here.

TestBench interface showing equivalence classes and representative values. Two classes are defined: '<valid>' for valid vehicles and '<invalid>' for invalid vehicles. The valid class includes representative values such as Rolo, Minigolf, Rassant, Rassant Family, and I5.

How is the test data managed?

The data types manage values as representatives of the same functional type, e.g. vehicle names or special model names in the example above.

TestBench table showing a list of representative values for a parameter, including vehicle names: Rolo, Minigolf, Rassant, Rassant Family, and I5.

When managing the values, groups of values can be created that belong to the same context. For example, the list of valid vehicles and the list of invalid vehicles for e.g. negative tests. The underlying method is called equivalence class decomposition.

Data Driven Testing and Keyword Driven Testing are integrated in TestBench, as also provided for in ISO 29119-5. Details on Keyword Driven Testing can be found here.

TestBench interface showing equivalence classes and representative values. Two classes are defined: '<valid>' for valid vehicles and '<invalid>' for invalid vehicles. The valid class includes representative values such as Rolo, Minigolf, Rassant, Rassant Family, and I5.

How can tests become even easier to understand?

TestBench interface showing the hierarchical structure of a data type named 'configuration'. It includes nested elements: 'vehicle' with vehicle name and price, 'add-on list' with add-on name and price, and 'special model' with model name, model price, dealer discount, and required price.

If a lot of data is required in test cases, tables can quickly become confusing. TestBench solves this problem with hierarchical data structures. These make it possible to display related values in a compact format.

This makes the associated values clearer
and easier to understand.

TestBench interface showing equivalence classes and representative values related to extra charges in special models. Three classes are defined: '<extra charge all in special model>', '<extra charge partially in special model>', and '<extra charge not in special model>'. The table includes configurations such as 'Rolo Gomera' and 'Minigolf Jazz' with corresponding add-on lists, no dealer discounts, and required prices of 14,703.0 and 16,409.0 respectively.
TestBench interface showing a composed test case structure. The 'Actions and Expected Reactions' section includes four steps: start Car Configurator, configure vehicles, check price, and close Car Configurator. Parameters include nested data from a 'vehicle configuration' structure. The 'List of Parameters' section defines the data type as 'configuration', and the 'Test Cases' section lists three configurations: simple, Rassant Jazz, and Luxury Class.

The presentation of the data is also clearer and easier to understand in the test definitions and test cases.

If necessary, the inner values of the data type structure can be accessed via their path in the structure, e.g. the vehicle name via ‘VehicleConfiguration.Vehicle.VehicleName’, as shown in the illustration.

How can tests become even easier to understand?

If a lot of data is required in test cases, tables can quickly become confusing. TestBench solves this problem with hierarchical data structures. These make it possible to display related values in a compact format.

TestBench interface showing the hierarchical structure of a data type named 'configuration'. It includes nested elements: 'vehicle' with vehicle name and price, 'add-on list' with add-on name and price, and 'special model' with model name, model price, dealer discount, and required price.

This makes the associated values clearer
and easier to understand.

TestBench interface showing equivalence classes and representative values related to extra charges in special models. Three classes are defined: '<extra charge all in special model>', '<extra charge partially in special model>', and '<extra charge not in special model>'. The table includes configurations such as 'Rolo Gomera' and 'Minigolf Jazz' with corresponding add-on lists, no dealer discounts, and required prices of 14,703.0 and 16,409.0 respectively.

The presentation of the data is also clearer and easier to understand in the test definitions and test cases.

If necessary, the inner values of the data type structure can be accessed via their path in the structure, e.g. the vehicle name via ‘VehicleConfiguration.Vehicle.VehicleName’, as shown in the illustration.

TestBench interface showing a composed test case structure. The 'Actions and Expected Reactions' section includes four steps: start Car Configurator, configure vehicles, check price, and close Car Configurator. Parameters include nested data from a 'vehicle configuration' structure. The 'List of Parameters' section defines the data type as 'configuration', and the 'Test Cases' section lists three configurations: simple, Rassant Jazz, and Luxury Class.

Advantages of Data Driven Testing in Manual Testing

Data-driven testing not only increases the efficiency of test automation, but also improves manual tests.

Faster test execution

Repeated test sequences can be executed more quickly as they do not have to be re-read each time.

Reduced susceptibility to errors

Instead of typing in values manually, existing data records can simply be run through. In the TestBench, data can also be pasted directly from the clipboard.

Increased test efficiency

More scenarios can be covered by a targeted variation of test data – without additional manual effort.


Details on test execution can be found here and in the blog post ‘Less effort, more efficiency: the iTORX assistant’.

Your questions – our answers

Do you have questions about Data Driven Testing or are you looking for support in optimizing your testing processes? Our experts will be happy to help you. Contact us and we will help you to design your test strategies efficiently and successfully.

How can we help?