Test Data Management in Katalon Studio and TestOps

What Katalon does and doesn't do with test data

Katalon is a test automation and test management platform, not a test data management (TDM) platform. Katalon Studio consumes test data inside tests: it reads data files, binds them to test cases, and switches values per environment. Katalon TestOps has a Test Data field on each manual step and a store of secrets and variables for test runs.

Katalon doesn't mask, subset, or virtualize production databases. If you need that, pair Katalon with a TDM tool or your own scripts, then feed the safe output into Katalon as data files. The what is test data management guide linked above compares the tools that do this, and the test data management challenges post covers the problems teams run into.

Create test data files in Katalon Studio

In Katalon Studio, test data is a project artifact. You create it from File > New > Test Data and pick one of 4 sources (docs):

• Excel file: point to a workbook and sheet.
• CSV file: point to a file and choose the separator.
• Database: run a query against a database and use the result set as rows.
• Internal data: type the values straight into a table inside Studio, which suits small sets that change with the test.

Connect to a database

Database test data uses a project-level connection under Project > Settings > Database, and a single data file can override it with its own connection. Katalon Studio ships built-in JDBC drivers for SQL Server, Oracle, and PostgreSQL, and accepts other JDBC drivers by class name (docs).

A query-based data file works well when your TDM process already loads a masked or synthetic data set into a test database.

Keep data types when you need them

By default, Studio binds data values as strings. If a test needs numbers or booleans as their own types, turn off Bind to test case as string on the data file.

Bind data and run data-driven tests

Data-driven testing replaces hard-coded values with data sets, so one test case runs once for each row, or set of rows, it's bound to. Katalon Studio supports it at 3 levels (docs):

See the docs for the test case level, the test suite level, and dynamic test suites. For a longer walkthrough, read our guide to data-driven testing in Katalon Studio and the comparison of a data-driven testing framework with Selenium and Katalon.

Map columns to variables

Data binding maps test case variables to data columns (docs):

• By column name or column index: each variable reads one column.
• Default or script value: a variable can take a fixed value or an expression instead of a column.
• Map All: binds every variable whose name matches a column name, which is why it pays to name columns and variables the same way.
• Row selection: run all rows, a range, or specific rows, such as 1-5,9.
• Several data files: "One" pairs rows by position, and "Many" runs every combination of rows.

Each resulting row set runs as one iteration.

Read the results

Each data iteration appears in the Log Viewer and in the suite report, and the report counts each iteration as an executed test case. Give iterations descriptive names with Set Test Name, so a failed row reads "Login: locked account" instead of an index (docs). That makes the numbers easier to explain in a test report.

Keep environment data and credentials in execution profiles

Katalon Studio has 3 kinds of variables (docs):

• Global variables: defined in execution profiles and shared across the project.
• Test case variables: pass dynamic data into a single test case, which is what data binding fills.
• Groovy variables: live inside a script.

Web, mobile, web service, and Windows test objects can be parameterized too, so a locator or endpoint can take a variable instead of a fixed value.

One execution profile per environment

Global variables live in execution profiles, and you can use them in test cases, test objects, web service objects, and email settings (docs). Teams usually keep one profile per environment, such as QA and staging. Other profiles inherit from the default profile and override only the values that differ, so the base URL changes per environment while shared values stay in one place.

Pick the profile when you run a test or suite, and the same tests run against a different test environment without edits.

Protect credentials with protected variables

A protected global variable masks a sensitive value, such as a password or API key, in execution logs and in HTML, PDF, and CSV reports. The value is stored on the local machine, not in the project files, so it doesn't end up in version control.

The trade-off: a teammate who clones the project has to enter the protected value again on their own machine. Note it in your project's setup steps so new team members know which values to request.

Worked example: a data-driven login test

Here's how the pieces fit together for an online store's login page, tested on QA and staging.

1. Create the data file. Add a CSV file, login_failures.csv, with the columns username, password, and expectedMessage. Fill it with failed-login cases only: a wrong password, a locked account, an unknown email, and an empty username. These rows hold no real passwords, so they're safe to keep in the project. The wrong-password and locked-account rows still need usernames that exist in the environment, so seed a locked test account in QA and staging, or keep their usernames in the profile instead of the CSV.
2. Create the test case. Write a test case, Login: failed attempts, with the test case variables username, password, and expectedMessage. It enters the username and password, submits the form, and checks that the page shows expectedMessage.
3. Bind the data. Bind login_failures.csv at test case level and use Map All, since the column names match the variable names. Use Set Test Name so each iteration is named after its case.
4. Create the profiles. In the default profile, add baseUrl and validUser. Create QA and Staging profiles that override baseUrl, and validUser if each environment has its own test account.
5. Protect the password. Add validPassword as a protected global variable in the default profile, and override it in a profile only where that environment uses a different test account. A second test case, Login: success, uses validUser and validPassword, so the real test account password stays out of the CSV.
6. Run it. Add both test cases to a regression suite and run it with the QA profile, then with the Staging profile. The report shows one executed test case per CSV row, plus the success case, and validPassword stays masked in the logs.

If you plan releases with a written test plan, list these data files and profiles in the test data section of your test plan template so reviewers can see where each value comes from.

Test data in Katalon TestOps

Katalon TestOps has 2 places for test data: the Test Data field on manual test steps, and project secrets and variables for test runs.

Test data on manual test steps

Every manual test case step in TestOps has 3 fields: Description, Expected Results, and Test Data, which holds any data needed for the step. You can also attach files to a step (docs).

A manual test case can call another test case for shared flows such as login, test data creation, or logout, so each flow is maintained in one place (docs). In the store example, a shared "Create test customer" case can be called at the start of each manual case that needs a fresh account.

Secrets and variables

TestOps has a project-level store of key-value pairs for values such as base URLs, usernames, passwords, API keys, and tokens (docs):

• Variables are plain text.
• Secrets are encrypted, masked with asterisks, and can't be viewed again after you save them.
• You can add them in project settings or while you create an automated or manual test run.

When a run starts, TestOps passes the project's secrets and variables to it as global variable overrides, matched by key name to the variables in your Katalon Studio execution profiles. Secret values stay masked in logs and reports. If a required value is missing, the run stops instead of running without credentials.

Manual runs and Run with AI can use saved values too, for example a step written as "Enter {validPassword} in the Password field."

One limit to plan for: secrets and variables only support test runs in cloud-hosted environments.

Run the same suite against each environment

An automated test run in TestOps can use a Katalon Studio execution profile to parameterize test data and environments, so the same suite runs against Dev, QA, staging, or production-like setups (docs).

Back to the login example: create a TestOps secret with the key validPassword. For a cloud-hosted run with the Staging profile, TestOps passes the secret in as the override for validPassword, so nobody has to enter the protected value on a local machine first.

Create test data with Katalon AI Assistant

In Katalon Studio 11.6.0 and later, Katalon AI Assistant Agent mode can use the built-in Studio MCP tools to create internal test data, add a test case to a suite, and bind the data to it. You review the data and the binding before you run the suite, as the docs for data-driven testing at the test suite level describe.

Katalon AI Assistant can also generate a script that writes test rows to a CSV file. You then register that file as test data and bind it like any other data file.

Either way, treat generated rows like any other test data: check that they cover the cases you need, including boundaries and invalid inputs, before they go into a suite.

Best practices for test data in Katalon

• One data file per business scenario. Keep failed logins, checkout payments, and address formats in separate files, so a change to one scenario doesn't break another.
• Name columns after variables. Matching names let Map All do the binding and make the file readable without the test open.
• Keep data files in version control with the project. Reviews then cover data changes as well as script changes.
• Keep credentials out of data files. Use protected global variables in Katalon Studio and secrets in Katalon TestOps.
• Use one execution profile per environment. Put shared values in the default profile and override only what differs.
• Create unique values at run time for create-account flows. Fixed emails and usernames collide on the second run. See how to generate test data at runtime.
• Reset data after a suite. Delete or restore the records a suite creates, so the next run starts from the same state.
• Get safe data upstream. If your data comes from production, mask or subset it before it reaches Katalon, then point a data file at the result. The broader process is covered in what is test data management.

Want to try data files and data binding yourself? Here's a quick tour of Katalon Studio.