Dynamic Data in Test Automation: Guide to Best Practices

Hari Mahesh

Automated Testing

Test automation is a crucial part of modern software development, allowing faster feedback loops, increased test coverage, and improved software quality. Though test automation brings these values, one of the biggest challenges in test automation is handling dynamic data.

Dynamic data includes test inputs, responses, environmental variables, etc, that frequently change, making it difficult to execute test cases continuously. Dynamic test data also creates more flaky tests.

In this article, we will review the best practices for handling dynamic data in test automation, thereby increasing its accuracy, reliability, and efficiency.

What is Dynamic Data?

Dynamic data changes frequently due to various factors, such as user interactions, database updates, API responses, third-party services, and environment-specific conditions. Unlike static data, which remains constant throughout test executions, dynamic data can create variability and unpredictability, thereby making test automation more challenging.

Types of Dynamic Data

Dynamic data is generated from multiple sources. Let’s look into different sources that generate dynamic data.

User-generated Data

It includes values that change based on user interactions, such as usernames, timestamps, and session IDs. These data points can vary across test executions, making direct assertions difficult. For example:

A user signs up with the username test_user_20250304, but in the next test execution, the timestamp changes.
A session ID like sess_abc123xyz changes every time a user logs in.

Database-driven Data

This comes from backend records that change due to CRUD (Create, Read, Update, Delete) operations. Since database updates occur frequently, relying on fixed data in automation scripts can lead to inconsistencies. For example, we can consider:

An e-commerce order table has an order_id that changes with every purchase (ORD1234, ORD5678).
A user’s profile information may be updated, leading to different test outputs.

API Responses

Data from APIs, such as RESTful and GraphQL responses, frequently change due to external updates or live data fluctuations. This makes direct assertions on API responses unreliable. Consider a weather app. It will return different temperatures each time. Another example would be a stock price API, where the stock price changes value for every API call.

Third-party Dependencies

This originates from external services such as payment gateways, OAuth logins, or analytics platforms. These integrations are outside of your control and may introduce unexpected variations. For example:

A payment gateway (Stripe/PayPal) generates unique transaction_ids for each purchase: txn_123abc, txn_456def.
Google OAuth login returns different session tokens.

Environment-based Data

Data may change based on environmental factors such as time zones, localization settings, or deployment environments. These variations can affect date/time values, language formats, and infrastructure settings.

A timestamp in UTC vs. IST (2025-03-04T12:00:00Z vs. 2025-03-04T17:30:00+05:30)
A website displaying Price: $10.00 in the US but Precio: 10,00€ in Spain.

Auto-generated Values

They include GUIDs, UUIDs, OTPs, and security tokens that are randomly created during test execution. These values change with every run, making direct comparisons unreliable. For example:

A UUID for a new user session: 550e8400-e29b-41d4-a716-446655440000
An OTP generated for authentication: 123456, 987654

Challenges in Handling Dynamic Data

Dynamic data presents various challenges that can impact the reliability, maintainability, and performance of automated tests. Understanding these challenges helps in implementing effective strategies to mitigate their effects.

Flaky Tests: Tests often fail intermittently due to changing data, leading to false positives or negatives.
Data Dependency: Some tests rely on specific test data, making them fragile when that data changes.
Test Maintenance Overhead: Frequent updates to test scripts are needed to accommodate dynamic data changes.
Synchronization Issues: Dynamic data, such as real-time updates in web applications, may cause test failures due to timing mismatches.
Security and Privacy Concerns: Sensitive dynamic data (e.g., personally identifiable information) requires careful handling.
Performance Bottlenecks: Poorly managed dynamic data can slow down test execution due to unnecessary API calls or database queries.

Dynamic Data Strategies

testRigor handles dynamic data strategically in different ways. Let’s understand how testRigor handles dynamic data.

Storing Dynamic Data

One of the most fundamental techniques for handling dynamic data is storing and reusing variables instead of hardcoding values. In testRigor, we can store dynamic data as a stored value with a name, which can be used in any test script.

For example, we can store the current date as today’s date and then use that in test scripts. So, we can execute the test script at any time, and it will fetch that particular date. This can be done by:

save stored value "nowDateIso" as "fetchednowDateIso"
enter stored value "fetchednowDateIso" into "Time"

So, any time we execute the script, it will take the current date, making the test case pass.

Another example we can consider is generating a random email in a specific format and saving it to a stored value, which can be used in the test script.

generate from template "$******************************@testrigor-mail.com" and save as "newEmail"
enter stored value "newEmail" into "user email"

Every test execution will use a new email to avoid conflicts.

To know more about using variables, please read: How to use variables in testRigor?

Handling Dynamic UI Elements with AI-Powered Locators

Traditional automation tools rely on XPath and CSS selectors, which are often brittle when dealing with dynamic UI elements. testRigor simplifies this with natural language-based test automation.

For example, traditional automation tools identify elements like:

click //*[@id='order-123']

Using testRigor, we can identify elements using different options. For example:

Clicking an element by its display name:
```
click "cart"
```
Clicking the element based on its occurrence:
```
double click on the 3rd "hello"
```
Clicking the element based on its screen position:
```
click on "Delete" with offset "20,10"
```
You can also save the image of the element as a stored value and then click it:
```
click on image from stored value "Logo"
```

Read more about element references used in testRigor: How to reference elements by UI position using testRigor?

Generating Randomized Data for Unique Test Inputs

Many test scenarios require unique values (e.g., unique usernames, email addresses, order numbers). testRigor provides built-in methods to generate them dynamically. For example:

generate from template "###-###-####", then enter into "Phone"

The above test script will generate a random telephone number in the above-mentioned format and enter that data into the Phone field.

Similarly, the below example will generate a name based on the regex provided and enter the data into the Name field.

generate from regex "[A-Z][a-z]{30}", and save as "generatedName"

To know more about generating unique test data, read the article: How to generate unique test data in testRigor?

Extracting and Reusing Dynamic Data from UI Elements

In many cases, applications display dynamic values such as prices, user IDs, or confirmation messages. testRigor allows extracting and using them in subsequent steps. To do that, testRigor uses the grab value method.

For getting the telephone number and reusing it on the page, we can write the test script as follows:

grab value by template "(###) ###-####" from element below "Phone" and enter into "Phone"

Similarly, we can use AI also to grab value, for example:

grab value by description "10-digit phone number" from "Contact form" using AI and save it as "phoneNumber"

You can also extract the value of an attribute of the element like:

grab value of attribute "href" from "element" and save it as "variableName"

To learn more about the grab value method in testRigor: Use grab value in testRigor.

Handling Dynamic Tables and Lists

Web applications often use dynamic tables to display data. testRigor allows easy interaction with them.

For example, If you want to specify a row that contains a certain value, we can write the test script as:

click on table "actions" at row containing "spk2" and column "Actions"

This will check all values of every row to find the one that matches.

Read more about testing the tables with testRigor here: How to work with tables using testRigor?

Synchronizing Tests with Asynchronous UI Updates

Many modern applications use AJAX, animations, or background processes, making elements appear dynamically. testRigor supports implicit waiting to handle such scenarios.

wait until "Success Message" is visible

Instead of using fixed delays (e.g., sleep 10s), testRigor waits for elements intelligently.

Utilizing Self-Healing Tests for Flaky Dynamic Elements

One of the most powerful features of testRigor is self-healing, which adapts to UI changes dynamically. Even if there is a change in the UI elements’ attributes or the app’s requirements, testRigor’s AI capabilities will identify the change and update the test script so that the tests do not break. Read more about AI-based self-healing in testRigor: Self-healing Tests.

Conclusion

Effectively handling dynamic data requires mitigating flaky tests, reducing data dependencies, minimizing maintenance overhead, addressing synchronization issues, securing sensitive data, and optimizing performance. Implementing strategies like parameterization and explicit/automatic waits helps to have robust and maintainable test automation.

You're 15 Minutes Away From Automated Test Maintenance and Fewer Bugs in Production

Simply fill out your information and create your first test suite in seconds, with AI to help you do it easily and quickly.

	Achieve More Than 90% Test Automation
	Step by Step Walkthroughs and Help
	14 Day Free Trial, Cancel Anytime

“We spent so much time on maintenance when using Selenium, and we spend nearly zero time with maintenance using testRigor.”

Keith Powe VP Of Engineering - IDT

Request a Demo

Start testRigor Free