Skip to main content
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 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 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.

​
Pick the config type

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. 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.
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.

​
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 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.
  • Environment URL and custom headers say where the test runs and which headers to send (for example a preview bypass). See Applications and environments.
  • Output from an earlier test is how one test hands a generated value to the next. That is a dependency, 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.