> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qa.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# Test Data

> How to give tests credentials, emails, and other values without hardcoding them into the steps.

Tests need data that changes between accounts, environments, and runs: a login, an inbox, an API token, a file, a phone number. In QA.tech that data lives in **configs**. You attach a config to a test. The agent reads it at run time. The test steps describe what to do, not the secret itself.

## Write the step, not the secret

A goal such as "Log in as [admin@company.com](mailto:admin@company.com) with password Winter2024" bakes one account into every run and sends that password through the model on every execution. Write the intent instead:

> Log in with the configured admin credentials.

Then attach the config that holds those credentials. The same test can run against staging and production with different accounts, and you can rotate a password in one place.

There is no `{{variable}}` syntax. A config is a named set of values plus an optional description. At run time the agent receives the name, the description, and the values, and uses them where the steps ask for that kind of data. A clear name and description matter when a project has more than one login: they tell the agent which config is the admin, which is the patient, and which must not be used for a given flow.

## Attach data to a test

1. Create the config under **Settings → Configs**.
2. Open the test and go to the **Settings** tab.
3. Under **Configs**, select the configs this test needs.

Only attached configs are passed to that test. A project can hold many configs. A checkout test should not receive every login in the project.

You can also pick configs when you add a test from the Test Cases page, or ask the [AI Chat Assistant](/core-concepts/ai-chat-assistant) to use a named config. The assistant reads config names and descriptions when it generates or edits tests.

Field-by-field reference for each config type is on [Configs](/core-concepts/configs).

## Pick the config type

| You need | Config |
| :- | :- |
| A login form | Username + password. Leave **Use for Basic Auth** off. |
| A browser popup that asks for a username before the page loads | Username + password with **Use for Basic Auth** on. That is HTTP Basic Authentication, not your app's login form. |
| A one-time code from an authenticator app | Username + password with two-factor authentication. |
| A new user that must receive email | A generated email + password, or a single-use test email. |
| A stable inbox for the whole project | The project email address (`prj-…@qatech.email`). |
| A magic-link login | Email for magic link login. |
| A token sent as a header, query param, or form field | API key. The dashboard and chat mask it. The test agent receives the full value. |
| A name, address, member ID, or other non-secret | Custom fields. One key and value per field. |
| A PDF, image, or other file the test uploads | File upload. Maximum size is 250MB. |
| An SMS one-time code | SMS phone number. See [SMS Inbox](/test-features/sms-inbox). |

QA.tech also creates a few email configs for you: a single-use address per session, a magic-link address, and one permanent project address. Each of those can open the [Email Inbox](/test-features/email-inbox). Use them when the test must read a message. Use your own username/password config when the account already exists in the system under test.

<Warning>
  Config data is stored unencrypted and is passed to the model during a run. Use
  dedicated test accounts with limited permissions. Do not put production
  passwords or real customer data in a config.
</Warning>

## One config, different values per environment

The same login config can hold a staging user and a production user. Open the config, add an **Environment Override**, pick the application and environment, and set the values for that environment. A run against that environment uses the override. A run against any other environment uses the base values.

[Config environment overrides](/core-concepts/config-environment-overrides) covers how overrides merge when a test plan or a `POST /v1/run` request also passes config values. For day-to-day use, set the override on the config. Reach for a plan or API override when one pipeline must point the same config at a value that is not stored on the environment.

## What is not a config

* **Device presets** change viewport, user agent, and headers for a browser run. They do not hold credentials. See [Device Presets](/test-features/device-presets).
* **Environment URL and custom headers** say where the test runs and which headers to send (for example a preview bypass). See [Applications and environments](/core-concepts/applications-and-environments).
* **Output from an earlier test** is how one test hands a generated value to the next. That is a [dependency](/core-concepts/dependencies), not a config. Use a dependency when the value only exists after another test creates it. Use a config when the value is known before the run starts.