> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/web-testing/data-driven-testing-tutorial.md).

# Tutorial: Data-Driven Testing

{% hint style="info" %}
**Who is this for?** Testers and SDETs who want one ContextQA test to cover several approved data rows without copying the workflow.
{% endhint %}

Data-driven testing separates the workflow from its input values. The test case contains the actions; a test data profile contains reusable columns and environment-specific rows. ContextQA repeats the selected steps across the row range you choose.

[Watch the environments-and-data-profiles walkthrough](https://drive.google.com/file/d/1UbcQCoDLHLrjbau3Jfb9HqGF3lnsGR-m/preview).

**Business use case:** Validate the same registration flow for several user records in staging, then reuse the shared profile structure with different values in another environment.

## Prerequisites

* A test case containing the input and verification steps you want to repeat.
* An environment for the target application.
* Safe, fictional or approved non-production data.
* Permission to edit environment data and the test case.

## Step 1: Create the environment

1. Open **Environment & Data → Environments**.
2. Select **New environment** and enter a purpose-based name, such as `Stage Environment`.
3. Save and open the environment.
4. On **Environment variables**, select **Add variable**.
5. Create a String variable named `baseURL` with a non-production URL.
6. Save the variable.

Use the test editor's data picker to insert this value. ContextQA displays it as `*|baseURL|*`.

## Step 2: Create the test data profile

1. Return to **Environment & Data** and open **Test Data Profiles**.
2. Select **New test data profile** and enter `Login Scenarios`.
3. Assign it to **Stage Environment** and save.
4. Open the profile and select **Manage columns**.
5. Add these example columns:

   | Column          | Type     | Purpose                           |
   | --------------- | -------- | --------------------------------- |
   | `username`      | String   | Test account name                 |
   | `password`      | Password | Masked test-only password         |
   | `expectedTitle` | String   | Expected page heading after login |
6. Apply the column changes.
7. On the **Stage Environment** tab, add one row for each approved scenario. Give each row a clear name such as `admin_user` or `viewer_user`.

The column structure can be shared with other assigned environments, while each environment keeps its own row values.

## Step 3: Bind the profile to the test case

1. Open the login test case and edit its configuration.
2. Select **Stage Environment** as the execution environment.
3. Enable data-driven execution.
4. Select **Login Scenarios** as the test data profile.
5. Choose the start and end row that should participate in the run.
6. Save the test case.

If the profile is missing, confirm that it is assigned to the selected environment.

## Step 4: Create the profile loop

1. In the step editor, select the input and verification steps that should repeat for each data row.
2. Choose **Loop**, then select **Test data profile** as the source.
3. Confirm the environment, profile, and row range.
4. Select **Create steps**.
5. Edit each relevant step and use the **Parameter** picker to map the correct profile column:
   * Email or username input → `username`
   * Password input → `password`
   * Heading verification → `expectedTitle`
6. Save the steps and review their order before running.

Use the picker instead of typing variable syntax manually. This prevents spelling, case, and source-selection mistakes.

## Step 5: Run and review

Run the test directly for a focused check, or include it in a suite and plan when you need scheduling, notifications, or a device/browser matrix.

For each selected row, confirm:

* The expected row supplied the input values.
* Password values remain masked in the interface and evidence.
* The repeated steps ran in the intended order.
* The expected title or business outcome was verified.
* A failing row can be identified without exposing its secret values.

## When to use each data type

| Need                                                | Use                  |
| --------------------------------------------------- | -------------------- |
| One intermediate value used only by this test       | Local variable       |
| One approved value shared by many tests             | Global data          |
| A value that changes between staging and production | Environment variable |
| Several related input rows that repeat one workflow | Test data profile    |

## Related pages

* [Environment Data Management](/web-testing/environment-data-management.md)
* [Test Data Management](/web-testing/test-data-management.md)
* [Test Steps Editor](/web-testing/test-steps-editor.md)
* [Test Plans](/web-testing/test-plans.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://learning.contextqa.com/web-testing/data-driven-testing-tutorial.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.